If you are an MSP running N-central on premises, or a company whose MSP does, this is the most consequential item of the week. N-able has stated in its own words that attackers who got into N-central servers used the product’s Take Control feature to reach managed devices and registered Cloudflare tunnels on those devices for persistence that survives losing access to N-central itself. Two CVEs are involved, one of them created by an incomplete fix for the other, and there have been two rounds of insufficient patching.
What happened
There are two CVEs, and any account naming only one will mislead you.
CVE-2026-18556 is the original: “Authentication bypass using an alternate path or channel vulnerability in N-able N-central allows Authentication Bypass. This issue affects N-central: through 2026.1.” CVSS 7.4, CWE-288, published 1 August 2026.
CVE-2026-18577 is what the fix for the first one produced: “An incomplete patch for CVE-2026-18556 allows for authentication bypass and account takeover in N-central Versions through 2026.3.1.” CVSS 8.1, same CWE, published 2 August 2026.
Both are in CISA’s Known Exploited Vulnerabilities catalog, with deadlines that are worth reading twice. CVE-2026-18577 was added 3 August with a due date of 6 August. CVE-2026-18556 was added 4 August, due 7 August. Three-day windows, citing BOD 26-04 and its forensics triage requirements rather than the familiar 21-day BOD 22-01 clock. Note the ordering: the incomplete-patch CVE entered the catalog a day before the original.
Two rounds of incomplete fixes
The version history is the part that catches people out, because “we patched it” has been true and insufficient twice.
Round one is the one that got a CVE. The fix for CVE-2026-18556, shipped in the 2026.3.1 line following the 2026.3.0 release on 30 July, was incomplete — and that incompleteness became CVE-2026-18577.
Round two did not get a CVE. Hotfix 1, build 2026.3.1.7, released 2 August, “addressed the original access point.” On 6 August N-able released Hotfix 2, build 2026.3.1.10, described as “additional hardening measures that build on and supersede Hotfix 1.” The Hotfix 2 release notes are unusually direct about the risk of being ignored: “This is not a duplicate of our previous communication — Hotfix 2 is required, even if you already applied the earlier hotfix.”
2026.3.1.10 is the complete fix. Self-hosted deployments on 2025.4, 2026.1, 2026.2, 2026.3, or 2026.3.1 with Hotfix 1 upgrade directly to it.
Hosted customers are in a different position. Per the Hotfix 2 notes: “If you are on an N-central hosted instance (NCOD), mitigations have already been applied to your environment. You do not need to do anything at this time.” N-able’s timeline records mitigation deployed to hosted environments on both hotfix dates. On-premises customers download and apply manually, which is where the exposure sits.
The vendor’s own account of what attackers did
Exploitation here is confirmed by N-able itself, not merely alleged by a third party. The company’s account: “On July 31, our Adlumin MDR solution detected unusual activity inside a customer environment,” and “A threat actor exploited a vulnerability in N-central that allowed remote administrative access without authentication.” Scope, in N-able’s words: “A limited number of customers have been identified as impacted, and our team has directly engaged with each of them.” No threat actor has been named.
Then the sentence that makes this an estate-wide problem rather than a server problem:
“Once inside, they used N-central’s Take Control feature to connect to managed devices, and registered Cloudflare tunnel services on those devices to maintain persistence even after their access to N-central was revoked.”
Read that carefully. The attackers did not merely compromise a management server. They used the management server’s legitimate remote control capability to reach the endpoints it manages, and then established independent persistence on those endpoints through a service that looks like ordinary outbound traffic. Revoking their access to N-central does not touch it.
N-able says as much: “Applying Hotfix 2 closes the vulnerability that allowed attackers in, but it does not remove a threat actor who may already be present.” An update published 10 August includes indicators of compromise: nine IP addresses plus suspicious files, services, and account activity.
Why it matters
RMM platforms are the highest-leverage target in the managed services model, and everyone in the industry knows it. What makes this case instructive is not that N-central was attacked. It is the shape of the failure: a patch that was incomplete, a hotfix that needed a second hotfix, and a compromise whose reach extends into every device the platform manages by using the platform exactly as designed.
If you are an MSP, your remediation scope is not one server. It is every endpoint that server could reach during the exposure window, and the hunt is for outbound tunnel services that will not look anomalous to anything watching for malware.
If you are a customer of an MSP, the question to ask this week is specific: were they self-hosted or on NCOD, when did they apply build 2026.3.1.10, and what did their endpoint hunt find? “We’re patched” is not a sufficient answer to a compromise the vendor says patching does not remove.
The three-day KEV deadlines are also worth noting for what they signal. CISA does not issue those casually, and the forensics triage requirement attached to BOD 26-04 implies an expectation that agencies look for evidence of compromise rather than simply install and move on.
One correction to the coverage
Reporting has framed this as attackers repeatedly defeating N-able’s fixes, with headlines suggesting exploitation continued through Hotfix 1. N-able does not say that. The vendor-documented incompleteness is the 2026.3.1 fix for CVE-2026-18556, which produced CVE-2026-18577. The Hotfix 1 to Hotfix 2 sequence is described by N-able only as a “related attack path” found through “continued monitoring on August 6” — it does not claim attackers exploited a Hotfix 1 bypass in the wild. Anyone stating that attackers defeated Hotfix 1 should attribute it to whoever is claiming it.
One more piece of language worth flagging: The Register’s characterization of the access as “God mode” is a reporter’s coinage, not vendor wording. In this case the vendor’s own plain description is the more alarming version.
What to do
- Self-hosted: upgrade to 2026.3.1.10. If you applied Hotfix 1 (2026.3.1.7), you are not done — the vendor says so explicitly.
- Hosted (NCOD): no action required, per N-able.
- Hunt the endpoints, not just the server. Look for Cloudflare tunnel services registered on managed devices, unexpected outbound tunnel traffic, and Take Control sessions in the exposure window that nobody can account for.
- Pull N-able’s 10 August indicators — nine IPs plus file, service, and account artifacts — and run them against your estate.
- Treat patching as step one. The vendor states the fix does not evict an actor already present.
- If you buy managed services, ask your provider the three questions above in writing.
Sourcing note
CVE descriptions and CVSS scores are NVD’s, both records in Analyzed status. KEV add and due dates were confirmed through the KEV catalog JSON and NVD’s mirrored CISA fields, which agree; cisa.gov itself is not retrievable from here. All quoted material is from N-able’s own advisories, status posts, and release notes. Exploitation is vendor-confirmed, which is the strongest category of sourcing available and distinguishes this from several other stories running this week. We could not find an authoritative vendor statement listing every affected version — N-able never publishes a clean “versions X through Y” line, so the anchors above are NVD’s ranges and the Hotfix 2 upgrade path. The total number of victims is not public beyond “a limited number,” and no attribution exists.