decrypted · 5 august 2026 · vulnerabilities and patching · uk policy and law · ai and llm security

The N-central patch that missed its own vulnerability, and the MSPs left exposed twice

N-able patched an authentication bypass in its N-central remote monitoring platform some weeks back, the kind of fix that barely makes a changelog. On 1 August it discovered the patch had missed the actual hole. Attackers were already through it, using N-central's own "Take Control" feature to reach into the networks of the businesses N-central is meant to protect, then planting a Cloudflare Tunnel so they could let themselves back in even after the door was properly shut. N-able's real fix landed on 2 August. The next day the US Cybersecurity and Infrastructure Security Agency added the incomplete-patch flaw to its Known Exploited Vulnerabilities catalogue with a deadline of 6 August for federal agencies; a day after that it added the original flaw too. Two entries, one product, four days. N-central is remote monitoring and management (RMM) software, the tool thousands of managed service providers use to watch over other people's networks. Which means this was never really N-able's problem alone.

A lock changed, a window left open

CVE-2026-18556, the original flaw, let an unauthenticated attacker reach administrator-level control of an N-central server through an alternate path, affecting every version up to 2026.1. N-able fixed it in version 2026.2. What it didn't do, it turned out, was close every route to the same weakness: a second path, catalogued separately as CVE-2026-18577, stayed open in every build up to 2026.3.1.7. N-able hasn't explained why the first fix missed it, only that the discovery followed unusual licensing errors from on-premises deployments, the kind of stray signal that in hindsight was attackers moving around inside the platform. Exploitation of the second path began on 1 August, before the real fix shipped. The security firm Huntress found that among the servers it could see, more than half remained unpatched even after the fix was available: publishing a patch and applying one are different events, and attackers live in the gap between them.

The Secure by Design lesson

The specific bug matters less than the shape of the failure. A patch that closes the named CVE without closing the underlying weakness isn't a fix, it's a delay. That's a testable property: before shipping a security patch, a vendor should ask not "does this stop the reported exploit" but "does this remove the class of weakness", and check it against variant attempts, not just the original proof of concept. For UK organisations, especially the smaller ones that outsource IT to a managed service provider precisely so they don't have to think about this, the lesson sits one level up. An RMM platform is designed to be a single point of access into many customers' networks: that's the product. An incident response plan that doesn't ask "which of our suppliers can reach into our network the way N-central reaches into an MSP's customers" has a blind spot exactly this shape. Worth asking your provider which platform they run, whether it faces the internet, and how fast they apply hotfixes rather than waiting for the next scheduled update.

Also this week

CISA's same batch of updates added a second, unrelated flaw: CVE-2026-9198, a critical (CVSS 9.8) unauthenticated remote code execution bug in Langflow, the open-source tool used to build AI agent workflows. The chain is almost comically simple. One endpoint, /api/v1/auto_login, hands out administrator-level tokens to any caller, a shortcut meant for local development that isn't restricted by default. A second, /api/v1/validate/code, runs whatever Python it's given through Python's own exec(). Put the two together and an unauthenticated visitor on the network gets full code execution. Any UK team currently prototyping AI agents on Langflow, or tools like it, should check whether their instance is reachable from the internet at all, because the default configuration assumes it isn't.

Further behind, but worth tracking: the regulations requiring the Information Commissioner's Office to write a statutory code of practice on AI and automated decision-making came into force in May, complete with a mandatory section on children's data. Three months on, the code doesn't exist, and the regulations set no deadline for producing it. That isn't necessarily bad process; a rushed code helps nobody. But it leaves UK organisations building AI-assisted decision systems working against a rulebook that will eventually carry legal weight and hasn't been written. Worth designing for the direction of travel now rather than retrofitting later.

Sources

If this raises questions about what access your own suppliers have to your systems, get in touch.

More like this

Get the next post by email: subscribe to Decrypted. Double opt-in, unsubscribe any time, or take the RSS feed.