N-able N-central Hotfix 2: your first patch wasn't enough

Six days ago the answer was 2026.3.1.7. It isn't anymore. N-able has shipped a second hotfix for the actively exploited authentication bypass in N-able N-central, and the build number your managed IT provider needs to be on is now 2026.3.1.10. If they patched once and closed the ticket, the ticket is open again.

What actually happened

CVE-2026-18577 (CVSS 8.2) is the incomplete-fix flaw that reopened account takeover on N-central after CVE-2026-18556 was supposedly closed. Hotfix 1, build 2026.3.1.7, shipped August 2. On August 6, N-able published Hotfix 2, build 2026.3.1.10, which supersedes Hotfix 1 with additional hardening. N-able is explicit that on-premises customers need it even if Hotfix 1 is already installed. Hosted N-central environments have the mitigations applied already.

Two other details moved since the first round. The Register reported on August 7 that N-able has confirmed attackers reached customer networks, not just N-central servers — going through the console's own Take Control feature to land on managed endpoints. And CISA gave federal agencies until August 6 to remediate, a three-day deadline it reserves for what it treats as urgent.

The persistence detail from the first wave still stands and still matters: attackers registered a Cloudflare Tunnel as a service on compromised devices, which survives losing access to the N-central server entirely. N-able has published ten malicious IPs as indicators.

Why patching your MSP console twice is the whole job

An RMM console is the one system where "we patched it" is not a sufficient answer, because a version bump does not remove an attacker who already established a tunnel out. Patching closes the door. It does not evict anyone already inside.

So this is a two-part ask to your IT provider, and both parts need a written answer.

One: the build number, in writing. Not "we're current." The string 2026.3.1.10 or later. If they reply with 2026.3.1.7, they applied Hotfix 1 and stopped — which was correct advice for about four days and is stale now.

Two: what they did about persistence. Specifically: did they hunt for unauthorized Cloudflare Tunnel services on managed endpoints, and did they check their egress logs against N-able's published IP indicators? "We patched" and "we checked for persistence" are different sentences. Only one of them answers the question.

There is a pattern here worth naming for your own stack, because this is the second incomplete fix in this same CVE lineage in two weeks. When a vendor patches an authentication bypass, the correct posture is not relief. It is to assume the underlying flaw has more than one route to it, and to re-check the advisory a week later. N-able has now revised twice. Vendors that revise are being honest; the failure mode is on your side, if you only read the advisory once.

Sources: N-able status, The Register, The Hacker News.