The Incomplete Patch

A vendor shipped a fix. Attackers bypassed it. A second CVE had to be issued, an emergency hotfix released, and within twenty-four hours the flaw was in CISA’s Known Exploited Vulnerabilities catalogue. Every organisation that applied the first patch in good faith remained exploitable throughout. That is the story, and it is not really a story about N-able.

What happened

N-able N-central is a remote monitoring and management platform. It is the control plane thousands of managed service providers use to administer their clients’ IT estates: deploy software, apply patches, take remote control of endpoints. It is, by design, one of the most privileged systems in any environment it touches.

In late July, N-able disclosed CVE-2026-18556, an authentication bypass carrying a CVSS score of 8.2, which allows an unauthenticated attacker to obtain administrative access to an N-central server. A fix was issued. Researchers subsequently established that the fix could be circumvented. A second identifier, CVE-2026-18577, was assigned to the bypass, also scored 8.2, and an emergency hotfix followed.

The exploitation activity is what elevates this above routine patch management. Huntress reported attackers using the compromised console’s own Take Control feature, a legitimate built-in remote access capability, to pivot from the management server into managed endpoints, including domain controllers. Cloudflare-based tunnels were then deployed to maintain access. N-able has confirmed that a limited number of customers were compromised through the second vulnerability.

Update, 10 August: attribution

On 10 August, Microsoft Threat Intelligence published its assessment of the activity. From 2 August it observed Storm-1175, a China-based financially motivated actor previously associated with Medusa ransomware, deploying a new ransomware strain it calls StormEncryptor. Microsoft separately reports LSASS credential dumping within the same activity, so any organisation in scope should treat privileged credentials as potentially exposed rather than merely at risk.

The confidence distinction matters here and is easy to invert. Microsoft attributes the StormEncryptor deployments to Storm-1175 as a finding. What it qualifies is the initial access vector: it states that the exact vulnerability exploited is unclear and that CVE-2026-18577 is the likely route. The ransomware and the actor are established. The link to this specific CVE is an assessment, not a confirmed fact.

That distinction does not soften the operational conclusion. The interval from silent zero-day on 31 July to observed ransomware deployment on 2 August was roughly two days. No patch cycle absorbs that, which is why the response has to be detection and hunting rather than remediation alone.

Why this one is different

Most vulnerability news is noise. This one carries two features that make it materially more serious than its CVSS score suggests.

The patch was not a patch

Vulnerability management, as practised in most organisations, is a binary process. A patch is released, it is applied, the ticket is closed and the risk register is updated. That model assumes the fix works.

Here it did not. Organisations that responded promptly, applied the vendor’s remediation and recorded the control as satisfied were still exploitable. Their vulnerability scanners would have reported compliance. Their patch dashboards would have shown green. They were wrong, and nothing in their process was capable of telling them so.

Applying a patch is a task. Confirming it holds is a control. Most organisations fund the first and assume the second.

The blast radius is one-to-many

A compromised RMM console is not a single-organisation incident. It is a distribution channel. Access is inherited across every managed estate, and it arrives through a trusted, whitelisted mechanism that endpoint controls are specifically configured not to obstruct.

This is the pattern established by Kaseya in 2021 and reinforced by every major supply chain compromise since. The attacker does not need to breach the target. They breach the entity the target has already decided to trust.

The commercial exposure

For a board, the operative question is not whether N-central is patched. It is what this class of event costs when it lands, and who carries it.

Regulatory. Under UK GDPR, the ICO assesses whether an organisation had “appropriate” technical and organisational measures in place. Recent ICO enforcement decisions have leaned heavily on NCSC guidance to define that standard, and the regulator has been explicit that supplier oversight forms part of it. The Cyber Security and Resilience Bill will extend statutory duties to managed service providers directly. Organisations inside NIS2 or DORA already carry formal, auditable third-party risk obligations. In none of these regimes is “our provider handled it” a recognised position.

Contractual. Most MSP agreements in the mid-market specify availability, not security posture. They rarely contain a patch application SLA, a right to audit, or a notification obligation on vendor advisories. When an incident originates upstream, the client discovers that the contract allocates the operational work to the provider and the legal liability to themselves.

Insurance. Cyber policies increasingly underwrite on demonstrated control operation rather than stated policy. An insurer examining this incident will ask when the hotfix was applied and what evidence exists. A gap in that record is a coverage argument.

Reputational and commercial. Enterprise security questionnaires now routinely ask how supplier patch compliance is verified. A firm that cannot answer does not fail loudly. It fails quietly, at the procurement stage, months before anyone in the commercial function connects the two.

What to do this week

The technical response is straightforward and should already be complete. Confirm N-central is running version 2026.3 HF1 or later. Review Take Control session logs and administrative account creation from 1 August onwards. Hunt for unauthorised Cloudflare tunnel activity and anomalous outbound connections from the management server.

The governance response is the part most organisations will skip. If your IT is outsourced, the version number is not yours to check. It has to be requested, in writing, from the provider.

Three questions for leadership

1. For every supplier with privileged or administrative access to our environment, do we know what they run, what version it is on, and how quickly they apply critical patches? If not, what is that gap worth in a claim or an enforcement action?

2. When we mark a vulnerability as remediated, what evidence supports that judgement beyond the fact that a patch was installed? Who is accountable for confirming the fix actually holds?

3. If our provider were compromised tomorrow, what in our contract obliges them to tell us, how quickly, and what are we entitled to see?

If those three cannot be answered in a single meeting, the exposure is not in the patch cycle. It is in the operating model.

The strategic takeaway

Outsourcing IT transfers the work. It does not transfer the risk, the regulatory duty or the commercial consequence. Those stay exactly where they were.

What this incident makes plain is that the assurance layer most organisations rely on, an annual questionnaire and a trusted relationship, cannot detect a vendor fix that does not work. Nothing in that process would have surfaced the gap between 2 and 6 August. Something else has to.

Supplier assurance is not a procurement formality. It is the control that determines whether someone else’s patch cycle becomes your breach.

Garzon Cyber Solutions delivers cybersecurity advisory, compliance certification, and specialist technology recruitment as one integrated capability. We are a young firm, the founder personally runs the work, and our perspective comes from a career spent inside cybersecurity and compliance across the sales, marketing and technical sides of the industry.