SURIQ
The fix for the N-able N-central flaw shipped on August 2. That is the least interesting part of this story. N-central is the console a managed service provider uses to run thousands of other companies' machines, and attackers have been inside some of those consoles since late July. Upgrading to build 2026.3.1.7 closes the door they walked through. It does nothing about the ones already in the building.
Two things make this worse than a routine authentication bypass. The first patch did not hold, and the blast radius is every endpoint the compromised server managed. If you run N-central yourself, or your IT provider does, the patch is step one of a longer job.
The patch that had to be patched
The original flaw, CVE-2026-18556, let an unauthenticated attacker reach an administrative account on N-central. N-able shipped a fix in release 2026.2. According to the vendor and to Huntress, that fix was then found to be bypassable through an alternative path, tracked separately as CVE-2026-18577. The complete fix is build 2026.3.1.7, released August 2. Both issues are scored 8.2 on CVSS 4.0, and both affect supported versions through 2026.3.1, on hosted and on-premises deployments alike.
N-able has said the first sign came on July 31, when customers who host N-central themselves started throwing an odd wave of licensing errors. The break-in surfaced as an operational glitch before anyone read it as an attack.
The sequence is the lesson. An authentication bypass under active exploitation should be treated as bypassable until the vendor confirms the root cause is closed, not just the first path to it. A single hotfix on a live auth flaw is rarely the finish line, and the gap between 2026.2 and 2026.3.1.7 is a working example of why.
Why one console is worth a whole fleet
A remote monitoring and management platform, or RMM, exists to run other people's computers at scale. That is its job and its danger. Huntress describes the access an attacker gains as god-mode over the console, and the phrase is fair. Whoever holds the console inherits what it can do: sending code to the machines under management, launching trusted admin tooling for untrusted ends, opening live sessions onto servers and desktops, and loosening security controls on the way through. One N-central server is administrative reach over every customer sitting downstream of it.
This is the same pattern behind other recent intrusions that needed no exotic exploit, only the tools an IT provider already trusts. Attackers keep coming back to management platforms and remote-support appliances because a single foothold there pays out across a whole customer base. N-central itself was under active attack through separate authentication flaws a year ago. A publicly reachable RMM console should be treated as a tier-0 asset, on the same footing as a domain controller, and it has no business being exposed to the open internet.
The part upgrading does not fix
Here is what the coverage of the patch mostly skips. At one victim, the attackers did not stop at the console. They pivoted through Take Control, the product's built-in remote-session feature, onto the managed machines and stood up Cloudflare tunnels there, each installed as a Windows service. A tunnel set up that way keeps running after a reboot, and it keeps running once the intruder's console access is pulled, because it no longer leans on N-central at all. Patching the server and closing the sessions leaves that foothold in place.
The tradecraft is deliberate. Outbound tunnel traffic rides normal port 443, and the observed command-and-control hostnames used consumer dynamic-DNS services such as Synology QuickConnect, so the callback traffic blends into ordinary remote-management noise. A file-scan of the endpoint and a "we revoked the session" response both miss it. Detection has to pivot from the console to the endpoints: new services (Huntress flagged a service named Cloudflared and a stray svchost.exe dropped in users' Documents folders), new or newly promoted administrative accounts, and outbound tunnel connections to the published indicators. This is hunting work on the managed estate, not a patch you apply once.
Concretely, on Windows hosts the Take Control activity logs under C:\ProgramData\GetSupportService_N-Central\Logs\ can be cross-referenced against N-able's published list of attacker IP addresses and the session times, so a remote-control session from an unexpected address to a domain controller or file server stands out.
Patch the console, then treat the fleet as the crime scene
If your N-central, or your provider's, was reachable during the exploitation window from late July through August 2, do both halves. First, upgrade to 2026.3.1.7 now; there is no partial mitigation worth waiting on, and the earlier build is known-bypassable. Second, assume the managed endpoints are the actual target and hunt them: check for the Cloudflared service and rogue svchost.exe, review N-central for admin accounts you did not create, rotate console and privileged credentials, and match Take Control sessions against N-able's indicator list. If you are the customer of an MSP rather than the operator, the one question worth asking today is direct: was your N-central instance exposed in that window, and what did the endpoint hunt find.