N-able shipped Hotfix 4 for N-central this week. You applied Hotfix 3 yesterday. That build is already insufficient. Every on-premises N-central server below 2026.3.1.14 is in scope, including boxes that took the previous emergency drop a day earlier. The company’s incident notice says the unauthenticated remote code execution flaw has been exploited in the wild. The release notes say that claim is unconfirmed. That split is a cybersecurity problem if your change window still waits for a tidy CVE narrative. Same week, ConnectWise confirmed attackers are spreading malware through ScreenConnect file transfers in Support and Access sessions, cloud and on-prem, with a CVE and a fix promised within the week. The pane of glass you bought to manage everyone else’s risk just spent five weeks in emergency mode.

Hotfix 3 was a day old. It already didn’t count.

Four hotfixes in five weeks is not a patch cadence. It’s a tell. N-central is remote monitoring and management, which means the console can reach the fleet you actually care about. An unauthenticated RCE on that box is a remote shell with a customer list. You do not get to file this under “vendor appliance, we’ll catch the next cumulative.”

The version pin is brutally specific. If your CMDB says “we patched N-central” and the evidence is yesterday’s ticket, you are documenting a false close. Incident response that stops at “hotfix applied” without recording the build string is how Hotfix 3 survives as a comfort object. Ask for 2026.3.1.14 or newer. Screenshot it. Put the screenshot in the ticket. Then assume the prior three drops did not buy you a week of quiet.

N-able’s mixed language on exploitation is the part that will stall a cautious CAB. One document says in the wild. Another hedges. Attackers do not wait for the two pages to agree. If the console is reachable from anywhere an unauthenticated client can speak HTTP, the argument is over. Pull it behind a jump path. Do the hotfix. Hunt afterward. The exploit-status footnote can go in the post-incident writeup.

This is a bad look for any MSP or internal NOC that sells “we patch the customers” while the mothership console is on a hotfix treadmill. The agents you pushed last quarter will cheerfully take orders from whoever owns that server now.

File transfer is doing the attacker’s job

ConnectWise’s ScreenConnect problem is ruder because it hides in a feature you defend in training. A technician starts a Support or Access session. Files move. That is the product. Help Net Security’s reporting, and ConnectWise’s September 3 advisory, say attackers are using that path to spread malware. Cloud deployments are in. On-prem is in. A CVE identifier and an official fix were promised within the week of the advisory. Sessions did not pause while legal numbered the bug.

A support session that can move binaries is a software distribution system with a human on one end. If that human is an attacker, or a hijacked tech account, your endpoint threat-protection has to win a fight against a signed remote-access parent process. A lot of stacks lose that fight because the agent is trusted infrastructure. The payload did not need a drive-by or a loud brute-force against the VPN. It rode the same channel your helpdesk uses to drop a diagnostic ZIP.

Waiting for the CVE string before you disable unmanaged file drops is how this class of bug eats a long weekend. You can restrict who may transfer files, require a second person for binary drops, and alert when ScreenConnect or any RMM agent writes an executable under user profile paths. None of that needs a vendor blog post. The official patch still matters. It is not the first control you have.

Your cybersecurity stack is watching the wrong hop

Most cyber security programs still point the expensive sensors at the front door. The firewall logs inbound 443. Threat detection hunts password spraying and noisy malware callbacks. The RMM console and the remote-support broker sit in the “admin tools” VLAN with a blessed identity, if they sit in a VLAN at all. Defense in depth assumed the management plane was the depth. This week that plane is the ingress.

Unauthenticated RCE on N-central skips the login page entirely. ScreenConnect file transfer skips your email gateway and your web filter. Both look like work. Your SOC runbook for “suspicious executable from Chrome” will not fire the same way for “suspicious executable from the remote support agent we told everyone to install.” If threat detection has no detection for child processes of RMM and remote-access binaries, you are blind on the hop that can touch every server.

Internet-exposed consoles make the rest worse. Teams spend years tuning brute-force lockouts on OWA and VPN, then leave the RMM login on a public IP because vendors default that way and “the techs travel.” An unauth RCE does not care about your lockout policy. A stolen tech session does not care either. Security hardening for these products starts with shrinking who can even attempt a handshake. The rest is logging, least privilege on the agent, and a patch SLA that matches what you demand for domain controllers.

The real problem here is classification. If N-central and ScreenConnect are “IT convenience,” they get monthly maintenance and a shrug. If they are fleet-wide execution, they get the same change discipline you use when someone proposes opening RDP to the world. Pick the second label. The news already did.

Treat the console like a domain controller already

You can cut a lot of blast radius this week without buying a new platform. Do the boring work on the boxes you already run.

• Inventory every RMM, remote support, and “quick assist” console, including the cloud tenant you forgot and the on-prem VM named after a former engineer. Record product, build, last hotfix, and whether the UI is on the public internet.
• Prove N-central is at 2026.3.1.14 or newer. A ticket that says Hotfix 3 closed is an open finding. Snapshot the version page into the incident system.
• Take management UIs off raw internet exposure. Jump host, VPN, or a tight source allowlist. If a technician “needs it from a hotel,” they need a controlled path, not a public login page.
• Until ScreenConnect’s fix is on every cloud and on-prem node you use, restrict file transfer to a named group, block executable extensions where the product allows it, and alert on new binaries written during Support or Access sessions.
• Hunt now: unexpected services or scheduled tasks created around hotfix windows, new local admins on the RMM host, agent jobs you did not schedule, and processes whose parent is the monitoring or remote-access agent.
• Give RMM and remote support the same incident response playbook you use for a domain admin compromise: rotate technician credentials and API tokens, review session recordings or logs, and assume file-drop capability was used until evidence says otherwise.
• Set an ongoing rule: management-plane emergency patches ship in hours, with build proof, not in the next monthly window. Rehearse the “hotfix 4 lands the day after hotfix 3” case so CAB is not improvising under a vendor advisory.

None of this requires a specific vendor’s dashboard. It requires you to stop treating the tool that can patch, script, and file-copy the estate as a toaster. The fourth hotfix in five weeks is the vendor tapping the glass. The file-transfer malware is someone already using the glass as a delivery route.

Sources

• N-able Issues Fourth N-central Hotfix in Five Weeks for Unauthenticated RCE Flaw
• Attackers spread malware through ScreenConnect file transfers