On 31 July 2026, N-able detected unusual activity inside a customer's environment. The investigation found threat actors exploiting a then-unknown flaw in N-central — CVE-2026-18577, CVSS 8.2.
The uncomfortable detail is what that CVE turned out to be. It is an incomplete fix for CVE-2026-18556, a previously patched authentication bypass carrying the same 8.2 score. Customers who applied the earlier patch had done the right thing and were still exposed, because the patch did not close the whole hole.
CISA added it to the Known Exploited Vulnerabilities catalogue in August.
Incomplete patches are a distinct failure mode
Most vulnerability management assumes patching is binary. A CVE is open or closed; you applied the update or you did not. Incomplete fixes break that model, and they are common enough to warrant their own handling.
The pattern repeats across the industry. Apache Tomcat carries CVE-2021-25329, explicitly an incomplete fix of the earlier PersistenceManager deserialization flaw. The mechanism is always the same: a vendor patches the specific input or path that the reporter demonstrated, rather than the underlying weakness, and a researcher — or an attacker — finds the adjacent path.
Why it keeps happening is not mysterious:
- Patches ship under time pressure, scoped to the reported reproduction.
- The reporter demonstrated one route; the root cause enabled several.
- Regression tests get written against the specific PoC, so the fix looks verified.
- Nobody re-audits the surrounding code, because the ticket is closed.
The defensive consequence is that "we patched that" is a weaker statement than it sounds, particularly for authentication bypasses, deserialization flaws, and path traversal — bug classes where the same root cause typically has multiple reachable paths.
Why an RMM platform is the worst place for this
N-central is remote monitoring and management software. Its function is privileged administrative access to every endpoint it manages, which for an MSP means every endpoint across every client.
That inverts the usual blast radius calculation. Compromising one N-central server is not compromising one server; it is acquiring the administrative channel to everything downstream — with legitimate credentials, through a tool that is expected to run scripts on endpoints, generating telemetry that looks exactly like normal operation.
The observed activity matched that. Per The Hacker News reporting, the actors used captured data to establish session persistence, then deployed automated Python and PowerShell scripts to exfiltrate data from enterprise cloud environments and SaaS applications — specifically including Microsoft 365 and Okta.
Read that chain again. The entry point was an on-premises management appliance. The loss was SaaS and identity-provider data. The pivot worked because the appliance held or could mint the credentials that reached those services.
Session persistence defeats the obvious response
Note the sequence: authentication bypass, then session persistence, then exfiltration. That ordering matters for anyone responding to this.
Once an attacker holds a valid session token, rotating the password does nothing. Sessions minted before the rotation typically survive it. Teams routinely declare an account-takeover incident closed after a credential reset, while the adversary continues operating on a session established during the exposure window.
For this incident specifically, remediation has to include invalidating all active sessions, not only resetting credentials. And because the pivot reached Okta, the session invalidation has to extend to the identity provider — where a stolen session can be used to mint further access that outlives every fix applied to N-central itself.
What to do
Patch to the fixed version. Necessary, insufficient, and the first step regardless.
Invalidate every session on the platform and on downstream identity providers. Passwords and API tokens are not the whole credential surface.
Treat CVE-2026-18556 remediation as unverified. If you patched the earlier CVE and considered the matter closed, that conclusion no longer holds. This is the practical lesson: when a CVE is described as an incomplete fix, every organisation that patched the predecessor needs to re-open the ticket.
Audit what the RMM platform could reach. Enumerate the service accounts, API integrations, and stored credentials it holds — particularly anything with Microsoft 365 or Okta scope. That enumeration is your exposure list.
Hunt for scripted activity in the exposure window. The observed tradecraft was automated Python and PowerShell. On a management platform, script execution is normal, which is precisely why it needs a baseline to be detectable at all.
Segment the management plane. An RMM server with unrestricted egress to the internet and unrestricted reach into SaaS is a single point of total failure. It should reach what it manages, over the ports it needs, and very little else.
The vendor-risk angle
If you are an MSP customer, this incident happened to your data through a supplier's product, exploiting a flaw in a patch that supplier had already issued. Your own patching discipline was not a factor.
That is third-party risk in its most concrete form, and the standard artefacts — a SOC 2 report, an annual questionnaire, a signed attestation — would not have surfaced it. What helps is knowing which suppliers hold privileged access into your environment, what that access can reach, and how fast you can revoke it. The list of vendors with standing administrative credentials in your estate is usually much longer than the security team expects, and it is worth building before you need it.
How Safeguard helps
Third-party access inventory that reflects reach, not paperwork. Safeguard's TPRM module tracks which suppliers hold privileged access into your environment and what that access can actually touch, so an incident at a vendor becomes a scoped question rather than a fire drill. That is the same discipline we applied when contractor access drove the Medtronic and AdaptHealth exposure.
Incomplete-fix tracking. Safeguard links CVEs to their predecessors, so when a vulnerability is published as an incomplete fix for one you have already remediated, the earlier ticket reopens automatically. Without that link, "we patched 18556" reads as closed forever, which is exactly the assumption this campaign monetised.
KEV and exploitation-weighted prioritisation. An 8.2 with confirmed in-the-wild exploitation on a management platform outranks a 9.1 on an internal service nobody can reach. Safeguard prioritises on KEV membership, exploit availability, and real reachability rather than on CVSS alone.
Lion for the pivot path. The damage here was not the appliance — it was Microsoft 365 and Okta data reached from it. Lion enforces just-in-time secret brokering and capability scoping so a management platform holds no standing credentials to your identity provider, plus egress allowlists that break automated exfiltration and signed audit trails that make the exposure window reconstructable.
Eagle for scoping, Griffin for the fix. Eagle establishes which downstream systems were genuinely reachable from the compromised platform, so rotation is proportionate. Griffin drives the remediation and credential-migration changes across affected repositories and configurations.
If you patched CVE-2026-18556 and closed the ticket, that ticket is open again. Go and check the version you are actually running.
Sources: The Hacker News — CISA Adds Exploited N-able N-central Flaw to KEV · CISA Known Exploited Vulnerabilities Catalog · The Hacker News — CISA Flags Langflow, Tomcat, and N-central Flaws
