CVE-2026-18556 / CVE-2026-18577 — N-able N-central: unauthenticated admin access to the RMM console, exploited in the wild, and the day-one fix was itself bypassable

N-able disclosed and then re-patched a critical authentication bypass in N-central, the remote monitoring and management platform managed service providers use to monitor, patch and remotely access customer estates. The vendor's own account of the attack is that "an attacker had identified a vulnerability on all N‑central servers running a version prior to 2026.3.1.7, which allowed them to obtain administrative access remotely" (N-able, 2026-08-02). The sequence matters as much as the flaw. N-able first addressed the issue in 2026.2 and, on 1 August, told customers still on older builds to move to 2026.3 as an immediate protective measure (N-able, 2026-08-02); its initial advisory tied the exploitation to CVE-2026-18556, while the hotfix that followed pointed at CVE-2026-18577 (Huntress, 2026-08-03). What changed in between is that the vendor "identified an alternative method to exploit this vulnerability, which was not mitigated in our previous fix" (N-able, 2026-08-02). Huntress records the second identifier's published description as "an incomplete patch for CVE-2026-18556 allows for authentication bypass and account takeover in N-central Versions through 2026.3.1" (Huntress, 2026-08-03). Hotfix build 2026.3.1.7 shipped the same afternoon (N-able status page, 2026-08-02). One discrepancy in the vendor's own material is worth resolving before you scope your estate: the status notice describes the issue as affecting every N-central instance not running 2026.3.1, while the security blog says the attacker reached all servers "running a version prior to 2026.3.1.7" and the published CVE description gives the affected range as through 2026.3.1. The blog and the CVE record agree with each other, so 2026.3.1 is affected and 2026.3.1.7 is the fixed build — for anyone sitting on 2026.3.1 the single digit is the whole decision.

N-able dates the start of the visible signal precisely: "On July 31, 2026, N‑able saw an increase in licensing issues for our on-premises N‑central customers", the anomaly that put its engineering and security teams on the investigation (N-able, 2026-08-02) — which is why 31 July is the sensible left edge for scoping a look-back. Exploitation is confirmed but so far bounded: N-able says "A limited number of customers have been identified to be impacted" (N-able, 2026-08-02), and Huntress reports it "has seen exploitation impacting one organization in our customer base" as of publication (Huntress, 2026-08-03). What removes the comfort from those numbers is the blast radius of the product: Huntress states that "a compromised N-central server can be used to run scripts, push tools, and open remote sessions across every downstream endpoint it manages", including domain controllers, and that an attacker in the console can also create administrative accounts and loosen security-relevant policy (Huntress, 2026-08-03). The observed post-exploitation path is the platform's own tooling rather than malware: N-able records that "the attacker leveraged the Take Control feature and connected to systems within the N‑central managed environment" and that on those devices "the attackers registered a new service for a CloudFlare tunnel, enabling persistence into an environment after access to the N‑central server was revoked" (N-able, 2026-08-02).

Two facts from an update Huntress added on 3 August shape how any of this can actually be hunted. First, the platform's exposure is worse than the confirmed-victim count suggests: at the time of that update "more than half (55.6%) of our partners' and customers' reachable cloud servers were still unpatched" (Huntress, 2026-08-03). Second, the compromised asset is itself a telemetry gap — Huntress notes that "the N-able server runs a custom distribution of AlmaLinux 9, and does not often have EDR software deployed on it due to running as an appliance" (Huntress, 2026-08-03), so the endpoint agent that would normally carry this investigation is frequently absent from the one host that matters most. Detection therefore leans on the server's own application logs and on what the pivot leaves behind downstream. In web-application and authentication logs on the N-central server itself, the signal is administrative activity and remote-control sessions with no corresponding legitimate credential use — Huntress points defenders at the console's UI and remote-access logs and flags sessions whose viewer account presents as a vendor support identity, or that target domain controllers and file servers, or that fall outside the team's working pattern. On managed Windows endpoints, Take Control leaves log files under C:\ProgramData\GetSupportService_N-Central\Logs\, and in service-installation telemetry the durable artifact is an unexpected service registered under the name Cloudflared, and in file-system terms a binary named svchost.exe sitting in a user's Documents folder — both named by N-able as the things to look for on a device you suspect (N-able status page, 2026-08-02). The second is worth dwelling on: the real Windows service host only ever runs from the system directories, so that filename anywhere under a user profile is anomalous by construction. In egress telemetry the signal is outbound tunnel traffic from hosts that have no business originating it. Because the console bypass needs no credentials, Huntress advises that an N-central server still broadly reachable from the internet or other untrusted networks should be considered for temporary shutdown until the hotfix is applied and it can be returned behind strict network controls (Huntress, 2026-08-03).

Triage: the vendor's published network indicators are not a safe discriminator on their own. Huntress found that "the four IPs N-able initially flagged as malicious are actually Mullvad or NordVPN VPN exit nodes" (Huntress, 2026-08-03) — shared commercial infrastructure that ordinary users and unrelated traffic also originate from, so a match is a prompt to investigate the session, never a finding in itself. Take Control log files under GetSupportService_N-Central\Logs\ are not themselves evidence of compromise — Huntress is explicit that "these logs are also created during legitimate Take Control usage" (Huntress, 2026-08-03), so they are a pivot rather than a detection. The discriminators are the surrounding facts: whether the session maps to a ticket or technician, whether the viewer identity is one of your own staff, the criticality of the target host, and the time of day. A service registered as Cloudflared, or an svchost.exe under a user's Documents folder, is the sharper signal — a remote-support session that legitimately used Take Control has no reason to leave either behind (N-able status page, 2026-08-02).