N-able has confirmed that attackers used an authentication-bypass flaw in N-central to grab remote admin control of on-premises servers, then move laterally into the networks those servers manage. For UK MSPs, the first patch wasn't enough — a vulnerability management re-check is now unavoidable.
View the data behind this chart
| Phase | Starts (week) | Duration (weeks) |
|---|---|---|
| Licensing anomalies trigger… | 0 | 1 |
| Initial fix guidance… | 0 | 1 |
| 2026.3 found insufficient | 0 | 1 |
| Build 2026.3.1.7 shipped | 0 | 1 |
| Finland NCSC advisory issued | 0 | 1 |
What N-able has confirmed
According to N-able, intruders abused a flaw allowing them to bypass authentication on N-central, handing them remote admin control of the servers and, from there, a route into the customer environments those servers oversee. Investigators at the company opened a probe on 31 July 2026 after spotting an abnormal spike in licensing errors reported by on-premises customers, work that led them to an attacker who had already secured remote administrative access to servers still on build 2026.1 or older.
N-able released a list of six IP addresses tied to the attack activity: 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. Security firm Huntress subsequently traced four of those addresses back to Mullvad and NordVPN exit nodes — meaning defenders scanning firewall logs for these IPs in isolation risk a false sense of security, since the same nodes serve unrelated traffic too.
Why the first fix wasn't the real fix
This is the part UK buyers most need to absorb: N-able first told customers that upgrading to build 2026.3 would resolve matters, guidance it later walked back as inadequate. The vendor now insists every N-central customer must move to build 2026.3.1.7, which went out on 2 August 2026 and is the earliest release the company regards as clean.
N-able put it plainly: "Every N-central customer should be on 2026.3.1.7." Any MSP that patched to 2026.3 and considered the matter closed is still running vulnerable infrastructure. This is precisely the scenario robust patch management discipline is designed to catch — not just applying a fix, but confirming the vendor hasn't since revised it.
Two CVEs, one pattern
The flaw being actively exploited carries the identifier CVE-2026-18577 and hits every N-central build before 2026.3.1.7. It sits alongside an earlier problem, CVE-2026-18556, which N-able's own advisory labels an "unauthenticated administrative account takeover" and files under authentication bypass through an alternate path or channel (CWE-288), spanning releases up to and including 2026.1.
In an advisory issued on 2 August, Finland's national cyber security centre confirmed that every version released ahead of the emergency hotfix carried the vulnerability, underlining that this is not a narrow edge-case bug but a systemic gap across the pre-2026.3.1.7 release line.
The blast radius so far — and why it could grow
So far, N-able's inquiry has traced the compromised account's reach to nine organisations, with a single endpoint touched at each one. That is a contained figure today, but N-central exists precisely to give MSPs centralised, privileged reach across many client networks at once — which is exactly why an authentication bypass here is disproportionately dangerous compared with a flaw in a single endpoint agent.
This isn't N-able's first brush with this class of problem. On 14 August 2025, CISA flagged active exploitation of two other N-central flaws, CVE-2025-8875 and CVE-2025-8876, both of which N-able had already fixed in build 2025.3.1. Around that same period, BleepingComputer counted close to 2,000 N-central instances visible on Shodan, clustered mainly across the United States, Australia and Germany — a reminder that RMM platforms are routinely internet-facing and routinely scanned.
What UK MSPs and their clients should do now
Any organisation running N-central on-premises should treat this as an immediate operational task, not a routine update cycle.
N-able's guidance on the earlier flaw set was unambiguous: "You must upgrade your on-premises N-central to 2025.3.1." The same urgency now applies to 2026.3.1.7. Given that administrative access was compromised, patching alone doesn't resolve the exposure — credentials, API keys and session tokens tied to the N-central instance should be rotated and audited as though a breach occurred, because for some customers it did.
- •Confirm the exact build number in production — 2026.3 is confirmed insufficient; only 2026.3.1.7 or later closes CVE-2026-18577
- •Rotate all administrative and API credentials associated with N-central, and review access logs back to at least 31 July 2026
- •Check firewall and SIEM logs against the six published IPs, but don't rely on IP blocking alone given the VPN exit-node overlap
- •Restrict internet-facing exposure of the N-central management interface wherever possible
- •Feed this into a tested incident response plan rather than treating it as a one-off patch ticket
View the data behind this chart
| CVE-2026-18556 | CVE-2026-18577 | CVE-2025-8875/76 | |
|---|---|---|---|
| Affected versions | Through 2026.1 | Before 2026.3.1.7 | Before 2025.3.1 |
| Classification | CWE-288 bypass | Auth bypass | CISA zero-day |
| Fix status | Fixed in a later… | Patched Aug 2026 | Patched 2025.3.1 |
| Disclosure date | N-able advisory | Aug 2, 2026 | Aug 14, 2025 |
The bigger lesson for managed infrastructure buyers
RMM platforms sit at the top of the privilege chain for MSPs, which makes them a recurring target — this is the second N-central exploitation event inside a year. Buyers should push providers to demonstrate layered defences around these tools, including managed detection and response tuned to catch anomalous administrative activity, and a zero trust approach that limits what a compromised management console can actually reach.
Because a single RMM compromise can cascade into ransomware across every managed client, pairing patch discipline with ransomware protection and broader cybersecurity solutions is no longer optional for anyone operating on-premises N-central infrastructure.