N-able has released a second required hotfix for an actively exploited N-central vulnerability after attackers used the remote monitoring and management platform to gain administrative access and reach managed endpoints.
The company’s latest security update, published August 6, says on-premises N-central customers should upgrade immediately to 2026.3.1.10. The update supersedes the first hotfix, 2026.3.1.7, that N-able released on August 2 after detecting exploitation tied to a zero-day issue in a customer environment on July 31. Hosted N-central environments have already had mitigations applied, according to N-able.
The incident matters because N-central is not ordinary enterprise software. It is an RMM platform used by managed service providers and IT teams to monitor, patch, script, and remotely control fleets of servers and workstations. If an attacker turns that console into their own control plane, the compromise can move from one vulnerable management server to many downstream machines very quickly.
What N-able says happened
In its August 6 update, N-able said its Adlumin MDR team detected unusual activity on July 31 and found a threat actor actively exploiting a vulnerability in an N-central server. As the investigation progressed, the company determined that the issue affected all versions of N-central and released Hotfix 1 on August 2.
The second hotfix arrived four days later because N-able was seeing attackers adapt. The company was explicit that the August 6 release is “not a duplicate” of the earlier communication and that Hotfix 2 is required even for customers that already installed Hotfix 1.
N-able’s description of the attack chain is direct: attackers identified a vulnerability on N-central servers running versions before 2026.3.1.7, obtained remote administrative access, used the platform’s Take Control feature to connect to systems inside the managed environment, and then registered a Cloudflare Tunnel service to preserve access after the N-central server path was cut off.
The company says a limited number of customers have been identified as impacted and that support has engaged with them directly. That does not make the risk narrow for everyone else. A vulnerable RMM server is valuable precisely because it can sit above many customers, departments, or endpoints at once.
Why the second hotfix changes the response
Security firms tracking the issue describe it as an authentication-bypass problem with unusually serious downstream consequences. Rapid7 says CVE-2026-18577 can let a remote unauthenticated attacker obtain administrative control of vulnerable N-central servers, and that it followed an incomplete fix for the earlier CVE-2026-18556 issue. CISA added CVE-2026-18577 to its Known Exploited Vulnerabilities catalog on August 3 and CVE-2026-18556 on August 5.
Huntress, which published detailed guidance for MSPs, warned that an attacker with N-central console access can run scripts, push tools, and open remote sessions across managed endpoints. Huntress also advised organizations with broadly reachable N-central servers to consider temporarily disabling the platform, including taking it offline, until the required hotfix is applied and the server is brought back behind strict network controls.
That is the practical difference between a normal software patch and this incident. Patching closes the entry point, but it does not prove that the management console, its accounts, its remote-control sessions, or the machines it touched are clean. Once an RMM product has been used for attacker movement, the response has to follow the blast radius.
What teams should check now
The first step for on-premises deployments is straightforward: move to N-central 2026.3.1.10. Teams that applied only Hotfix 1 should not treat that as complete. Hosted customers should still review N-able’s communications and their own environment for suspicious activity, because hosted server mitigation does not automatically answer what happened on managed endpoints before the fix.
- Confirm every on-premises N-central server is on 2026.3.1.10.
- Upgrade N-central agents after the server hotfix where N-able’s guidance requires it.
- Review N-central authentication logs, administrative account changes, and newly created or modified users.
- Audit Take Control session activity for unusual timing, source addresses, target systems, or technician accounts.
- Look for Cloudflared or unexpected Cloudflare Tunnel services on systems reached from N-central.
- Check for suspicious
svchost.exefiles in user Documents folders, one of the endpoint artifacts referenced in public guidance. - Review remote-management logs, script execution history, Windows service installation events, and outbound network connections from managed endpoints.
- Restrict access to N-central from untrusted networks and avoid exposing the console broadly to the internet.
MSPs should also think in customer-impact terms. If the RMM system was exposed or possibly exploited, the review should not stop at the N-central appliance. Customers may need to know whether their endpoints were accessed through Take Control, whether scripts or tools were pushed, whether local accounts or services were changed, and whether any persistence remained after the server was patched.
RMM compromise is different from ordinary server compromise
RMM products are attractive targets because they already have the permissions attackers want. They can inventory machines, execute scripts, move files, open remote sessions, deploy tools, and operate across many customer environments from a single console. That makes authentication bypass especially dangerous: it can skip the usual credential-theft step and land directly inside the tool trusted to administer everything else.
The Cloudflare Tunnel detail is also important. Cloudflare Tunnel is a legitimate remote-connectivity tool, but in this incident N-able says attackers registered a new service to keep access after the N-central path was revoked. Defenders should treat unexpected tunnel services, unusual service names, unfamiliar outbound tunnel connections, and newly installed remote-access utilities as high-priority persistence signals, not just suspicious software inventory.
The safest working assumption is that an exposed or unpatched N-central server needs both a patch and an incident-response review. For MSPs, that review should include the management server, technician accounts, remote-control logs, downstream endpoints, and customer notification obligations. For enterprises running N-central internally, it should include the same checks across business units and high-value systems.
The broader lesson for management platforms
CISA’s recent KEV activity put N-central alongside other exploited infrastructure flaws, including Langflow and Apache Tomcat issues. The common thread is not that the products are similar; it is that internet-reachable management and automation systems are being turned into fast operational footholds.
For N-central customers, the immediate priority is 2026.3.1.10 and log review. The longer-term priority is reducing how much trust any one management platform gets by default. RMM servers should sit behind tight network access, strong identity controls, monitored administrative actions, short-lived access paths, and tested procedures for taking the platform offline without losing the ability to respond.
That may feel heavy for a tool built to make IT operations easier. But once attackers can use the same console as the service desk, the management plane itself becomes part of the incident.
