The N-central Patch That Did Not Actually Patch: CVE-2026-18577 Hands Attackers Every Endpoint an MSP Manages

The thing that made us stop scrolling this week was not that N-able's flagship RMM shipped with an unauthenticated auth bypass, though it did. It was that N-able fixed the bug on August 1, told everyone to install 2026.2, and then on August 2 admitted the fix only closed one door into the same room. A second way in was already in use, and every N-central instance not yet on the 2026.3.1.7 hotfix was back at square one within a day of thinking it was safe. For anyone running an MSP stack, that is the whole day, because N-central manages every customer endpoint you touch and an unauthenticated administrative session on the appliance is not a foothold, it is the whole estate.

Two CVEs, one bug, one incomplete fix

The first advisory landed as CVE-2026-18556, an unauthenticated administrative account takeover in the N-central web interface for every version through 2026.1, catalogued under CWE-288, "Authentication Bypass Using an Alternate Path or Channel." That is the weakness class where the code requiring you to log in is fine, but a parallel entry point into the same authenticated surface never asks. OffSeq's threat radar confirms the same CWE mapping. N-able's initial guidance told operators to move to 2026.2, which closed the path the reporter had disclosed.

On August 2 the vendor published a follow-up saying a second exploitation route into the same weakness had been identified in the wild, one the 2026.2 patch did not block. That became CVE-2026-18577, described as "an incomplete patch for CVE-2026-18556" and carrying CVSS 8.2. The affected range expanded to all builds prior to 2026.3.1.7, which N-able shipped the same day as the emergency hotfix. If you patched on August 1 and closed the ticket, you are still exposed.

What "alternate path or channel" actually means here

N-able has not published a full root-cause writeup, so we are working with the CWE and the behavior N-able and Huntress have described. Modern application servers rarely have one entry point into a controller. There is the browser-facing UI, a REST or SOAP API, an agent-facing endpoint that authenticates managed devices, sometimes a legacy console binding still wired into the servlet container. When a developer's authorization filter is bound to one URI prefix or servlet name and a sibling path routes into the same privileged handler without traversing it, that sibling becomes an unauthenticated route to authenticated behavior.

The reason such a fix can ship broken is that vendors usually close the exact URI the reporter demonstrated. If the underlying handler is reachable through more than one router entry, patching the reported route leaves the others bypassable, which is almost certainly what happened between 2026.2 and 2026.3.1.7.

The RMM is a distribution channel, not a device

What N-central can normally do is the second half of this story, and it is why GBHackers characterised the impact as "god-mode". The console exists to push scripts, install software, and open remote sessions across every managed endpoint checked in to it, without requiring individual credentials for each. An attacker who owns the console does not need to compromise endpoints one by one; they use the compromised console the way an operator would.

The abuse pattern observed in the wild is the built-in Take Control feature, N-central's native remote-support mechanism. Once inside the console, attackers open Take Control sessions to selected managed devices and use them the way a technician would, running commands and dropping payloads under the RMM agent's context. On the endpoint, the observable evidence Huntress documents is a fake svchost.exe written into a user's Documents folder and a Cloudflared service installed for persistence. Cloudflared is Cloudflare's tunnel client, and in an intrusion it becomes a legitimate signed binary holding an outbound TLS connection to Cloudflare's edge that gives the operator a shell with almost no firewall footprint.

Why this chain slides past a normal blue team

The initial compromise leaves nothing on the endpoints your EDR is protecting, because the attacker never touches those hosts until after taking over the RMM itself, which most estates treat as a network device and do not ingest OS-level telemetry from. When the attacker eventually reaches managed endpoints, they arrive as the RMM: the command spawning the malicious binary comes from a signed agent running as SYSTEM that was installed on purpose and executes new payloads all day, so EDR rules keyed on "unusual parent process" or "unsigned binary" will not fire. And the persistence binary is Cloudflared, the same executable Cloudflare customers deploy legitimately, so allowlists and network filters both give it a pass.

In ATT&CK terms, this is T1190 (Exploit Public-Facing Application) against the N-central UI, then T1072 (Software Deployment Tools) as the RMM becomes the lateral-movement primitive, and T1572 (Protocol Tunneling) plus T1219 (Remote Access Software) once the Cloudflared tunnel is up.

Where the actual evidence lives

The forensic surface for this bug sits in two places most SOCs are not looking at. On the N-central appliance, the file to read is ui_access_control.log, along with the web and remote-control logs. Look for administrative sessions from source addresses outside your operations-team allowlist, unexpected access times, and sessions whose activity pattern differs from a real technician's, such as many Take Control invocations against unrelated customers in a short window with no ticketing correlation. On a healthy console the session logs in, does one customer's work, and logs out; on a compromised one the same session pivots from device to device without the friction a real day imposes.

On the managed Windows endpoints, Take Control activity leaves rotated log gzips under C:\ProgramData\GetSupportService_N-Central\Logs\, especially files matching BASupSrvc_*.log.gz. Cross-reference their session times against your ticketing and any session with no matching technician is a candidate. In parallel, hunt for a running service named Cloudflared that your IT team did not install, and for a file named svchost.exe in any user's Documents folder, since the real svchost.exe only ever lives in C:\Windows\System32. If your EDR ingests process telemetry, add a rule for child processes of the N-central agent (BASupSrvcCnfg.exe, BASupSrvc.exe) that write executables into user profile directories or install new services.

Patch to 2026.3.1.7, then close the appliance off, then rotate

The vendor fix is N-central 2026.3.1.7, released August 2, and it is the first build blocking both CVE-2026-18556 and CVE-2026-18577. If your appliance is on 2026.2 because you patched on August 1, you are still vulnerable to the second path and this is the priority upgrade for the day. CISA added the flaw to its KEV catalog with an emergency directive for federal agencies, a reasonable proxy for how quickly civilian MSPs should move.

Take the second and third steps most operators skip after the hotfix. Restrict the N-central web interface so it is not reachable from the general internet or from customer-side networks, so that the next alternate-path bug meets a locked door on the network before it reaches a locked door in the code. Then rotate: because the exploited session was fully authenticated as administrator, cycle N-central admin credentials, API tokens the console holds, integration credentials to PSAs, remote-access shared secrets, and any customer-side accounts stored for automation. Finally, sweep every managed endpoint for a Cloudflared service you did not deploy, the fake svchost.exe in Documents folders, and BASupSrvc log gzips whose session times do not line up with your ticketing, because a compromised console can be patched in an afternoon but the endpoints it touched while it was open have to be found and cleaned individually.

The proof the fix took is not "we applied the hotfix." It is re-running the exact attacker primitive against the patched appliance and confirming the alternate path no longer authenticates, then re-hunting on the endpoints and confirming no new Cloudflared or fake-svchost artifacts appear. This is the loop we automate at BlueTeamAutomation, so that a KEV listing on your management plane becomes an evidenced closure your BAS, EDR, and SIEM all agree on, rather than a hopeful email at the end of a long day.