N-able patched an authentication bypass in N-central, tracked as CVE-2026-18556, in version 2026.2. That should have been the end of it. Instead, according to The Hacker News's reporting, N-able's own follow-up analysis of the first flaw turned up a second route to the same outcome - an alternate path through the authentication logic that the initial fix never touched. That second flaw, CVE-2026-18577, also rates 8.2 on CVSS 4.0, and unlike its predecessor it didn't stay theoretical. Help Net Security confirmed N-able has already identified and contacted customers affected by real-world exploitation, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on 3 August.
Why an RMM platform is a worse thing to lose than it sounds
N-central isn't a system MSPs use for their own IT. It's the console they use to run everyone else's - remote monitoring, patching, scripting and, critically, a feature called Take Control that opens a live remote-control session into any managed endpoint, including domain controllers. Huntress's incident writeup describes exactly what that means once an attacker has admin access to the N-central server itself: they used Take Control to reach downstream endpoints, then registered a new Windows service wired to a Cloudflare tunnel on each one - a route out to Cloudflare's edge network that survives a reboot and keeps working even after the compromised N-central account gets revoked. Huntress traced one exploitation case to a single N-able partner account managing nine separate customer organisations, all reachable from the one compromised console. That ratio is the entire reason RMM platforms sit near the top of any attacker's target list: compromise one, and the blast radius is measured in how many other companies trusted that one vendor.
The patch adoption gap is the real story this week
N-able's hosted, cloud-managed N-central instances were updated automatically. On-premises deployments - which is a meaningful share of the installed base, given how many MSPs run N-central themselves rather than renting it - needed to apply hotfix 2026.3.1.7 manually. BleepingComputer's coverage of Huntress's telemetry puts a number on how that's gone: as of Huntress's update, 55.6% of the reachable, self-hosted N-central servers in its visibility were still unpatched. That's not a slow trickle of stragglers - that's most of the exposed population, days into active, confirmed exploitation, with detailed indicators of compromise already public. Finland's national cyber security centre issued its own advisory on 2 August flagging the same gap.
A KEV addition landing in the gap between two CISA regimes
For years, a KEV catalog addition meant a flat, well-understood clock: federal civilian agencies had 21 days to remediate, sometimes shortened to three for the worst cases. That's changing. Under Binding Operational Directive 26-04, which Cybersecurity Dive reported replaces the uniform window with four risk-based tiers - weighing internet exposure, active exploitation, whether an exploit is automatable, and how much control it grants - CISA argued plainly that "defenders cannot afford to take weeks to patch systems that can be autonomously exploited en masse." The catch for a CVE landing right now is timing: agencies have until 9 August to finish updating their processes under the new directive, and the actual risk-tiered remediation deadlines don't start binding until 7 December. CVE-2026-18577 lands in that gap - assessed under a framework that exists on paper but isn't yet the operative clock. For anyone outside the federal directive entirely, which is most of N-central's customer base, the honest takeaway is simpler than either regime: this is confirmed active exploitation of an internet-facing management platform with a public patch already available, and no clock - old, new or in between - changes what the right response speed is.
We've written about this shape of story three times in the past two weeks - Cisco's hardcoded FMC credential, Arista's perfect-10 VeloCloud flaw, and now a remote management platform that reaches into other companies' networks by design. The common thread isn't carelessness at any one vendor. It's that management-plane software is graded on the access it grants, and an incomplete first patch is a specific, recurring failure mode of that category: fixing the path an attacker used without fully closing the underlying flaw that made the path possible.
- If you run N-central on-premises, apply hotfix 2026.3.1.7 now - Huntress's own data shows most exposed servers hadn't, days after active exploitation was confirmed.
- Check managed endpoints for the indicators Huntress published: a file named svchost.exe sitting in the Documents folder, and a registered service named Cloudflared that shouldn't be there.
- If you're an MSP client rather than the MSP itself, ask your provider directly and in writing whether their N-central instance was exposed and what they found when they checked.
- Don't wait for a federal deadline to tell you the priority - BOD 26-04's risk-tiered clock isn't fully binding until December, and confirmed active exploitation doesn't need a directive to justify patching today.
- Extend the review to every RMM, remote-access or fleet-management tool with reach into systems beyond the one it's installed on - the access model, not the vendor, is what makes this category worth auditing on its own.
An RMM platform's entire value proposition is the reach it has into other people's infrastructure - and that's precisely what makes an incomplete patch on one so much more expensive than the same mistake almost anywhere else. If you'd like a second pair of eyes on how exposed your own management-plane tooling is, email sales@halfteck.com.