Three Fixes Shipped in Six Days. None of Them Made the Thing Safe.
- Patrick Duggan
- 1 hour ago
- 5 min read
If you run N-able N-central, stop reading and go patch to build 2026.3.1.7. It is being exploited right now, Huntress has confirmed it in a customer environment, and the version you are probably on was itself the fix for the last one.
That is the useful sentence. The rest of this is about why three different vendors shipped three fixes in six days and not one of them means what the word "fixed" is supposed to mean.
The patch that patched the patch
N-able disclosed CVE-2026-18577 on 2 August. The description is unusually candid about what it is: an incomplete patch for CVE-2026-18556, allowing authentication bypass and account takeover in N-central versions through 2026.3.1. Build 2026.3.1.7 is the first unaffected version.
So the first fix did not hold, and the hole it left is being walked through. Attackers obtain administrative access remotely, then use N-central's own Take Control feature to reach the endpoints the platform manages. For an MSP that is not one compromise, it is every customer at once — the god-mode problem that makes remote monitoring platforms such a rich target in the first place.
Here is the part that will cost people the most, and it is buried in the vendor write-up rather than the headline: once on those endpoints, the attackers registered a new service for a Cloudflare tunnel. That tunnel is persistence into the customer environment that keeps working after access to the N-central server is revoked.
Read that again if you are the person who was planning to respond to this by rotating N-central credentials. Rotating credentials is not eviction. Patching the server is not eviction. If you were exploited, someone may still be inside a managed endpoint through infrastructure that has nothing to do with N-able at all, and you will not find it by looking at N-able.
The fix that cannot reach the damage
On 30 July someone drained 1,196 Bitcoin addresses in 41 minutes — 1,082.65 BTC, roughly $70.2 million. Galaxy Research mapped the sweep and has since found two further waves, taking the observed total to 1,367.05 BTC across 4,585 addresses, about $88.6 million.
The cause is a firmware integration error in Coldcard, the Bitcoin-only hardware wallet, and it was introduced in March 2021. Seed generation was routed to a deterministic software pseudorandom number generator instead of the STM32 hardware RNG the device carries for exactly this purpose. An attacker who can constrain the device UID, timer state, and prior RNG-call history can reproduce candidate output streams offline, derive the addresses, and check them against public blockchain data.
Nothing touched the wallets. There was no phishing email, no malicious firmware update, no supply chain interdiction, no evil maid. The devices did precisely what they were built to do, air-gapped and dutiful, and generated predictable secrets for five years.
Coinkite shipped emergency firmware for every affected model and release track on 31 July, which was the right and fast thing to do. It does not repair an existing seed. It cannot. The entropy was never there; a patch cannot retroactively make a number that was guessable unguessable. New seeds generated on patched firmware are fine. Every seed made since March 2021 remains derivable by anyone who does the work, forever, and the only remediation is to generate a new seed on patched firmware and move the funds.
If you hold Bitcoin on a Coldcard and you have been telling yourself you will get to it this weekend: the attacker has already demonstrated they can do 1,196 addresses in 41 minutes.
The embargo that lost to a same-day PoC
We published this one on 31 July and it belongs in the set.
Rails disclosed CVE-2026-66066 on 29 July — arbitrary file read in Active Storage, CVSS 9.5, no authentication, reachable through any application that accepts an image upload from an untrusted user. Because the file read reaches the Rails process environment, and that environment holds SECRET_KEY_BASE, the read becomes code execution.
The Rails security team did the responsible thing and withheld the technical detail, planning to publish on 28 August to give the ecosystem a month to patch. A working proof of concept was on GitHub the same day the advisory shipped.
The embargo was correct practice and it bought nobody anything. That is worth saying plainly, because "we withheld details" is still widely treated as a control rather than a hope.
What the three have in common
In every case the remediation event and the safety event are not the same event.
This is not a story about lazy vendors. All three moved fast, and N-able and Coinkite both disclosed the awkward part rather than burying it. It is a story about what a version number actually asserts. A patched build is a claim about code. It is not a statement about your exposure. The gap between the two is filled by whatever the attacker established while the hole was open, or by damage the patch is structurally incapable of reaching.
There is a tidy way to sort which kind you are dealing with, and it takes one question: if the fix had shipped before the attack, would the attack have failed?
For Rails, yes — patched applications were safe. For N-able, partly: the patch stops new entry and does nothing about the tunnel already running. For Coldcard, no. The damage was done in 2021 and merely collected in 2026.
What to do tonight
N-able N-central. Patch to 2026.3.1.7. Then hunt your managed endpoints for newly registered services running Cloudflare tunnel clients, and treat any you find as an active intrusion rather than a misconfiguration. Do not assume patching closed it.
Coldcard. Update firmware, then generate a new seed on the patched firmware and move your funds to it. Updating alone leaves you exactly where you were.
Rails. Patch, and rotate SECRET_KEY_BASE. If the read happened, your key is gone and patching does not un-leak it — this is the same shape as the other two, one tier smaller.
Everyone. If your patch process ends when the version number changes, you have automated the part that was already easy.
This keeps happening and we keep writing it down
On 26 July we published that GitLab fixed a flaw in June and filed it under "bug fixes" — no CVE, no security label — and a PoC landed six weeks later. On 31 July, the Rails post above. Today, two more.
That is four in nine days, which is either a bad run or the normal rate finally being counted. We lean toward the second, and it is why the no-CVE, no-security-label patch tier is a standing beat here rather than an occasional story: the label failure is the story, and patching by severity rating means patching the subset somebody remembered to rate.
Confidence
High on the facts, all of which are vendor-stated or from named research: N-able's own advisory language on the incomplete patch, Huntress on active exploitation, Coinkite's firmware notice, Galaxy Research's on-chain mapping, and the Rails advisory. We hold the 95% cap — we have not independently reproduced the Coldcard seed derivation, and our totals for that theft will move as Galaxy finds more waves.
We did not detect any of these. We read the advisories, checked them against our own corpus, and are telling you what to do about them tonight. That distinction matters and we would rather draw it ourselves than have somebody draw it for us.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.