One Unauthenticated POST to N-central: How CVE-2026-86218 Turns getPierDetails Into a Ransomware Channel Across Every MSP Client

We keep watching the same shape of vulnerability roll through the RMM space this summer, and it lands the same way every time. A quiet servlet nobody thinks about, sitting outside the login wall for legacy reasons, takes an unauthenticated request and hands the attacker whatever they wrote inside it back as running code. This week the servlet was /remoteControlAction.do?method=getPierDetails on N-able N-central, and the bug is CVE-2026-86218 (CVSS 10.0). CISA added it to the Known Exploited Vulnerabilities catalog on September 8 with a federal civilian patch deadline of today, live exploitation was confirmed by Huntress on September 4, and it is the third critical zero-day in this one product in about six weeks.

Why the RMM console is the softest possible target

N-central is the pane of glass an MSP uses to run its clients. One instance holds agent credentials for hundreds of downstream tenants, a scripting library primed to fire against any subset of them, and remote execution channels that look on the wire like normal Tuesday afternoon patching. When an attacker gets root on that console, they inherit the trust relationship the MSP has already built with every downstream endpoint, so there is no lateral movement left to do. A ransomware operator who lands here can push a signed script through the same channel the MSP uses for legitimate work, and the endpoints downstream will treat the payload as authoritative because structurally it is. Campaigns targeting Kaseya, ConnectWise, and now N-central in successive months are not coincidence; RMM tooling is the highest yield pivot in the small business ecosystem, and adversaries have learned to shop for zero-days there.

The chain from getPierDetails to a Java shell

CVE-2026-86218 is classed as CWE-96, static code injection, meaning attacker-controlled input reaches a location the server later interprets as code rather than data. Public reporting names the entry point precisely: unauthenticated HTTP requests to /remoteControlAction.do?method=getPierDetails, targeting the Java server that fronts the on-premises N-central appliance. Huntress observed threat actors probing exactly that endpoint with specific appliance IDs before dropping exploit payloads, and confirmed one customer instance compromised on September 4, two days before N-able shipped Hotfix 4 (build 2026.3.1.14).

Two structural properties of that endpoint make the class of bug feel inevitable in hindsight. First, remoteControlAction.do sits outside the authenticated portion of the application because its original job is to bootstrap a remote-session handshake with an appliance before any user session exists. Second, getPierDetails was designed to return a rich description of an internal object, which in a lot of Java applications gets built with a template or expression evaluator that trusts its own inputs. When an endpoint that has to be reachable without credentials meets a code path that treats a request field as an expression rather than a string, the shortest fix in a code review two years ago was almost certainly "cast it to String and move on." That is the mistake CWE-96 catalogs.

N-able's advisory stops short of naming the exact evaluator, and until a patch diff surfaces from watchTowr, Bishop Fox, or Huntress there is no responsible way for us to invent one for you. What is clear from the public detail is that the attack reaches the sink over plain HTTP, needs no credentials, no side channel, and no chained bug, and it lands with the privileges of the N-central server process. From there the attacker inherits the platform's ability to deploy software to any managed endpoint, run remote scripts, harvest stored agent credentials, and reshape the automation policies that decide which of those actions run silently.

Why "static code injection" is worse than the label suggests

A defender reading the CWE-96 line item can be forgiven for filing it next to XSS in their head; both are injection classes, both come down to insufficient neutralization. The difference is where the injected material lands. In cross-site scripting the target is a browser and the blast radius is one user session. In static code injection the target is the server-side interpreter, and on an N-central appliance that interpreter runs inside the Java server that owns the RMM's agent trust, the SSH keys queued for scheduled tasks, the client-specific script libraries, and the endpoint impersonation tokens. There is no user session to blast; there is a fleet. The payload also does not have to look like code to your WAF, because the injection point is deep inside a legitimate parameter parser, and generic signatures for "shell metacharacter in URL" tend to miss cleanly formed exploit strings sitting inside a JSON body or an appliance ID field.

What defenders can actually see

The compromise leaves footprints; they are just on the RMM server and its clients, not on the perimeter you spent all quarter tuning. The pattern Huntress documented is the one to model your detections on:

• N-central access logs. Successful unauthenticated POST requests to /remoteControlAction.do?method=getPierDetails, especially with unusual appliance ID parameters or bodies larger than a normal handshake, are the highest fidelity signal. Public reporting called out probing traffic from the 23.234.64.0/18 range; treat that as one enrichment among many, not a gate.
• Process ancestry on the appliance. The N-central Java server spawning a shell, an interactive interpreter, or a scripting host is the direct signature of successful code injection, and it maps to MITRE ATT&CK T1190 (Exploit Public-Facing Application) into T1059 (Command and Scripting Interpreter). If your EDR runs on the console (and it should), an alert on java as the parent of sh, bash, cmd.exe, powershell.exe, or a script interpreter belongs on your highest tier.
• New N-central admins with off-domain email addresses. Huntress specifically flagged administrative account creations using email suffixes such as .invalid in compromised instances. Any newly created admin whose email domain does not resolve, or whose creation is not tied to a change ticket, is worth pulling apart the same hour it appears.
• Downstream job telemetry. Most SOCs miss this piece because the RMM pushes work through legitimate channels; the tell is not "N-central talked to your endpoints," it is "N-central pushed a job that nobody scheduled." Compare the automation policy audit log against your change management queue and pull any policy edited, added, or triggered outside a ticket window during the exposure period.
• Client-side artifacts. Follow the process tree on managed endpoints for the N-central agent spawning encoded PowerShell, LOLBins used for staging, or outbound connections outside your normal console-to-agent path. This is T1072 (Software Deployment Tools) in the field.

Patch, isolate, rotate, and re-baseline

The remediation order that keeps the fewest customers up at night:

• Upgrade every on-premises N-central instance to 2026.3 Hotfix 4 (build 2026.3.1.14) immediately. Hosted customers were updated by N-able directly. Note that Hotfix 3 shipped only a day earlier and did not fix this bug; environments that applied Hotfix 3 and stopped are still exposed.
• Restrict the N-central web console to an allowlist of management source IPs at the firewall. The last three N-central zero-days would have been non-events for a lot of MSPs behind a VPN gate.
• Assume any instance exposed to the internet across the disclosure window (late August through September 6) is potentially compromised until proven otherwise. Pull access logs for the whole window, not just today, and grep the endpoint above.
• Rotate credentials the N-central server had reach to, in this priority: N-central admin accounts, service accounts used by scheduled scripts, agent-side credentials cached on the console, and any stored API keys for downstream tenants.
• Re-baseline every automation policy against a known good export from before the exposure window. A policy edited by the attacker that fires on next scheduled sync is the follow-through your patch does not stop, and it is the step most teams skip.

Where this fits into the loop we run

This exact loop, detecting the exploit signature on the console, running a downstream job hunt across the managed fleet, correlating N-central audit logs with EDR process ancestry, and proving the hotfix actually held, is one that should be firing continuously against your RMM plane, not scrambled together the morning of a CISA KEV deadline. BASzy is how we keep that validation running daily so the detection and the proof are already there when the next N-central zero-day lands, and on current pace it will.