CVE-2026-18577: N-able's Second Patch for the Same N-central Bug, Now on the KEV List

A patch that doesn’t fully fix the bug it targets is worse than no patch at all, because it tells everyone watching that the vendor is close. CVE-2026-18577 is exactly that story: N-able shipped a fix for an N-central authentication bypass, the fix was incomplete, and the gap that was left over is now being actively exploited against MSP infrastructure. CISA added it to the Known Exploited Vulnerabilities catalog on August 3, two days after N-able disclosed the exploitation publicly.

The bug behind the bug

N-central is remote monitoring and management (RMM) software. MSPs and internal IT teams use it to administer client endpoints from a single console: push patches, run scripts, remote into a machine, monitor health, all without a technician driving to a site. That centralization is the entire value proposition, and it’s also what makes an N-central compromise categorically worse than a typical server breach.

The vulnerability history here matters. N-able had already patched CVE-2026-18576, an authentication bypass using an alternate path or channel, the kind of flaw where a request routed a slightly different way skips the check that would normally block it. CVE-2026-18577 is what’s left when that patch closes one path but not the other one an attacker can still use to reach the same result: administrative access to the N-central server without valid credentials. N-able disclosed on August 1 that it had detected active exploitation and that its investigation into the first patch turned up the additional gap.

What attackers are actually doing with it

Getting into N-central isn’t the objective, it’s the starting point. Researchers tracking active exploitation have observed attackers abusing N-central’s own Take Control feature, the built-in remote-access tool technicians use to jump onto a managed device, to pivot from the compromised server into every endpoint under its management. That’s the mechanism that turns “one vulnerable RMM server” into “every client this MSP manages.”

For persistence after the initial foothold, the observed campaigns deploy Cloudflare-based tunnels. That’s a deliberate choice: Cloudflare tunnel traffic looks like ordinary HTTPS to most egress monitoring, so it survives longer than a raw reverse shell that a decent EDR product would flag immediately. If your detection stack isn’t specifically looking for unexpected outbound tunnel traffic from RMM infrastructure, this kind of persistence can sit for a while.

Who needs to act right now

If you run N-central on-premises and it faces the internet at all, and most N-central deployments do, this needs attention today, not in the next patch cycle. Two facts make the urgency real: CISA’s KEV listing means federal agencies are on a binding remediation clock, and the “active exploitation” disclosure means the same clock applies in practice to everyone else, whether or not it’s contractually binding.

The fix is hotfix 2026.3.1.7, covering all N-central versions before 2026.3. Hosted (SaaS) customers have already received it from N-able directly; no action needed there. On-premises customers have to apply it themselves, which is the gap that matters here. An automatic update on the hosted side doesn’t help an MSP running their own N-central instance who hasn’t opened the admin console this week.

Before you patch, or immediately after, check for signs you were already hit:

• Administrative accounts you don’t recognize, especially ones created recently with no matching change ticket.
• Take Control sessions in the audit log that nobody on your team initiated.
• Outbound connections to Cloudflare tunnel endpoints your infrastructure doesn’t normally use.

Any one of those is grounds to treat this as an active incident rather than a vulnerability to remediate on a normal timeline. The distinction matters because incident response and patch management have different playbooks, and starting the wrong one costs time you don’t have.

The pattern worth remembering

This is the second time in two vulnerability disclosures that the same underlying weakness in N-central’s authentication has surfaced. That’s not unusual for complex software, but it is a reason to treat “we patched it” as a claim to verify rather than a box to check, particularly for RMM and other tools that sit with privileged access across your entire client base. The same logic applies to any vendor supply chain risk in an agency’s stack: a tool that manages other systems needs a shorter trust radius than one that doesn’t, and its patch history is worth tracking as its own signal. If your team hasn’t reviewed which RMM, backup, or remote-access tools in your environment carry that kind of blast radius, that’s a fifteen-minute exercise worth doing this week, not after the next incomplete patch turns into an incident. Our security team can help run that review if you’d rather have a second set of eyes on it.