N-able's N-central Authentication Bypass Gets Patched Twice After First Fix Left Door Open

N-able has confirmed that attackers exploited an authentication bypass vulnerability in N-central, its remote monitoring and management platform, to gain full administrative access to customer-facing servers. The initial patch didn't hold. A second CVE had to be issued.

The original flaw, CVE-2026-18556, was described in N-able's own documentation as an "unauthenticated administrative account takeover" — about as bad as it sounds. N-able pushed a fix in version 2026.2, but subsequently discovered a separate exploitation path targeting the same weakness. That became CVE-2026-18577, and meant the affected range stretched all the way forward to builds prior to 2026.3.1.7. Both CVEs scored 8.2 on CVSS 4.0. Neither disclosure identifies the vulnerable endpoint or explains the underlying mechanics at a code level.

The fully patched version, 2026.3.1.7, shipped on August 2. Anyone who followed N-able's earlier guidance to upgrade to 2026.3 is still exposed. That matters a lot when N-central is the thing sitting between an MSP and every device it manages.

N-able started looking into things on July 31 after noticing an abnormal spike in licensing errors from on-premises customers. It traced the source to attackers who had remotely acquired administrative access to servers running 2026.1 and earlier. A "limited number" of customers were affected, according to N-able, though the company hasn't put a figure on that.

Once inside an N-central server, the attackers used the platform's own Take Control feature to reach managed endpoints. They then installed Cloudflare tunnels as persistent services on those devices. Cloudflare tunnels connect outbound through Cloudflare's edge infrastructure, which means no open listening ports and no inbound firewall rules to flag. Running them as services keeps them alive across reboots. So even after access through the compromised N-central server was cut off, the tunnels remained. Cloudflare itself wasn't compromised here — its tunneling product was simply abused.

Finnish cyber security authority NCSC-FI issued an advisory the same day the patch landed, noting that all previously available versions were vulnerable.

For customers running hosted NCOD instances, N-able says upgrades will be applied automatically. Self-hosted deployments are the customer's problem. And critically, patching N-central does nothing to remove persistence already installed on managed endpoints. Any organisation that finds signs of compromise needs to actively hunt for and remove malicious tunnel services on affected machines.

N-able has published six IP addresses associated with the attacks: 173[.]249[.]252[.]200, 87[.]249[.]138[.]34, 37[.]19[.]210[.]32, 37[.]153[.]90[.]88, 92[.]118[.]112[.]181, and 68[.]235[.]46[.]214. Huntress identified at least four of those as Mullvad or NordVPN exit nodes, which limits their usefulness as indicators — they'll show up in legitimate VPN traffic too. Huntress advised correlating any IP matches against N-central UI logs, network traffic, and endpoint logs rather than treating the addresses as definitive proof of anything.

Huntress published its own rapid response on August 3, initially reporting exploitation at one organisation in its customer base. It later clarified that the affected account was a single partner running a self-hosted N-central instance, under which nine organisations were accessed — one endpoint each. Based on what Huntress has reviewed so far, post-compromise activity appeared limited to enumerating running processes before the attackers disconnected. The Cloudflare persistence behaviour N-able described in its original notification was not observed by Huntress in this case.

Huntress flagged three attacker-associated domains: mousears.synology[.]me, wagoosh.direct.quickconnect[.]to, and who-ripped-one.direct.quickconnect[.]to.

For defenders looking at Windows endpoints, Huntress recommends reviewing ui_access_control.log alongside C:\ProgramData\GetSupportService_N-Central\Logs\BASupSrvc_*.log.gz. Those logs appear during normal Take Control activity too, so their presence isn't proof of intrusion on its own. Sessions associated with identities like [email protected] are also worth scrutinising.

N-able has not disclosed how many customers or downstream devices were affected, when exploitation started, who is responsible, or whether any data was exfiltrated. Given that N-central is precisely the kind of platform attackers target when they want broad access to many organisations through a single compromise, the absence of that detail is frustrating.