Back to Blog

N-able Released Two Emergency Patches Last Week. Here’s What Attackers Planted on Client Computers Before Either One Landed.

N-able patched a critical security flaw in their N-central platform last week. Then they patched it again, because the first fix didn’t hold.

The timeline: suspicious activity noticed July 31. Emergency hotfix August 2. Attackers found a way around it. Second hotfix August 6. CISA issued an alert. Two patches in six days. The current safe version is 2026.3.1.10, and providers running anything older are still exposed.[1]

The patch race is worth knowing about. But the part worth paying closer attention to is what attackers installed on managed client computers during the window, and why patching the server doesn’t clean that up.

A Quick Word on What N-central Is

N-central is a remote monitoring and management platform, or RMM. If you’ve hired an IT company to manage your computers, there’s a decent chance they’re running something like this on your machines. When your IT provider needs to push an update, install software, or fix a problem without coming onsite, they do it through a tool like N-central. It has deep, persistent access to every endpoint it manages.

That’s also what makes it an attractive target. One compromised RMM server doesn’t give attackers access to one company. It gives them access to every client the MSP manages. We covered the same dynamic with a different RMM tool last month.[2] This pattern keeps showing up because the math keeps working out for attackers.

The Flaw Itself

N-able had already patched an earlier authentication bypass vulnerability, CVE-2026-18556, affecting N-central versions through 2026.1. That fix was incomplete. Attackers found an alternate path around it, tracked as CVE-2026-18577, which carries a CVSS score of 8.2.[3] Same category of problem, different route in: an unauthenticated attacker could bypass the login screen entirely and land directly inside the N-central management console with administrative access.

N-able noticed something was wrong when customers started reporting unusual licensing anomalies on July 31. Engineers investigated and found active exploitation already underway. CISA added CVE-2026-18577 to its Known Exploited Vulnerabilities catalog on August 3.[4]

What Attackers Did Once They Were In

N-central has a feature called Take Control. It’s legitimate functionality, used by IT technicians every day to connect to a managed endpoint and fix something remotely. Attackers, now sitting inside the N-central console with full admin rights, used Take Control to do exactly what it’s designed to do: connect to managed client computers.

On those client endpoints, they registered a Windows service. The service runs Cloudflared, which is Cloudflare’s own open-source tunneling utility. Developers use it to expose local servers to the internet without opening inbound firewall ports. Attackers used it the same way.[1]

Why Patching the Server Doesn’t Remove the Backdoor

Here’s what makes a Cloudflare tunnel a particularly durable persistence mechanism. It doesn’t need an open inbound port on your network. The compromised computer reaches outbound to Cloudflare’s infrastructure, establishes a connection, and Cloudflare relays traffic back to the attacker. From your firewall’s perspective, this looks like normal HTTPS traffic to a well-known CDN. Nothing triggers an alert.

Running as a registered Windows service means the tunnel comes back every time the machine reboots. And because it lives on the endpoint itself, not on the N-central server, revoking the attacker’s access to N-central doesn’t remove it. The server gets patched. The backdoor stays. The attacker has persistent access to your computers independent of how the entry point was secured.

N-able confirmed this specifically: “The tunnels preserved access after the route through the N-central server was revoked.”[1]

What to Check and What to Ask

N-able released an automated detection template that runs against managed endpoints and checks for known indicators of compromise.[5] The signs include a Windows service named “Cloudflared” (which most business computers have no reason to run), a suspicious svchost.exe file found in a user’s Documents folder rather than the expected system directory, and anomalous entries in N-central’s own ui_access_control.log.

If your IT provider uses N-central, ask two things. First: are they running version 2026.3.1.10 or later? That’s the current fixed version. Second: have they run the endpoint detection scan against machines they manage for you? If they haven’t, that’s the more important gap. Patching the server closes the door. Checking the endpoints finds out whether anyone already walked through it.

If they’re unsure, or haven’t heard about this at all, that’s worth a follow-up conversation. CISA added this to their KEV catalog on August 3rd. Any MSP staying current on security news would have been aware of it within hours.