Back-to-back N-able bugs send admins on a patching spree

N-able is asking admins to patch against a CVSS 10.0 zero-day in its N-central RMM platform, a day after disclosing and patching two other vulnerabilities affecting the product. A max-severity zero-day bug could be affecting cybersecurity firm N-able’s N-central remote monitoring and management platform, the company said, even as administrators were applying a hotfix for two vulnerabilities disclosed just a day earlier. The latest flaw, tracked as CVE-2026-86218, is a remote code execution bug that can give an attacker access to an N-central server without authentication. Through its incident page, the company said the new vulnerability is unrelated to the two flaws disclosed on September 5, and has already found active exploitation. “Unlike the earlier vulnerabilities, this newly identified vulnerability has been observed being exploited in the wild,” it said, adding that it is investigating the matter and has taken steps to help protect customer environments. These steps include applying the mitigations to all hosted N-central instances. On-premises customers, however, remain exposed until they download and upgrade their N-central deployments using instructions provided on the N-able support portal. In a blog post, Huntress disclosed an undocumented exploit chain involving CVE-2026-86206 and CVE-2026-86207, the two flaws N-able had disclosed on September 5, that can bypass access controls and allow unauthorized administrative accounts to be created. The disclosure had come after Huntress started investigating a compromise involving a customer’s fully patched (with Hotfix 2) N-central production on September 4. The flaws were addressed with Hotfix 3 (build 2026.3.1.13) on September 5, but systems updated with that fix need to be re-upgraded now with Hotfix 4 to upload protections against CVE-2026-86218. The cybersecurity outfit cautioned that due to limited historical logging, it could not definitively say which vulnerability the attacker used in the September 4 incident. Pinning down exploitation is getting trickier N-central is an RMM platform used by managed service providers to monitor and remotely manage their customers’ systems. That makes access to the platform particularly valuable to attackers, who can use compromised N-central accounts to create unauthorized administrative users and interact with the platform’s internal APIs. Huntress said the September exploit chain can provide control over N-central’s user management, allowing attackers to create unauthorized administrative accounts. Researchers observed attackers manipulating account names by adding strings such as .invalid to N-able email addresses, along with reconnaissance against an N-central remote control endpoint. Unlike previous August attacks involving CVE-2026-18556 and CVE-2026-18577 (addressed with Hotfix 2), which made heavy use of N-central’s “Take Control” functionality, the newer activity targets the underlying API and appliance logs, the researchers said. The distinction matters as defenders cannot simply look for suspicious remote-control sessions and declare the matches as newly exploited. Huntress recommended checking “envoy_proxy_HTTPs.log” and “syslog ncentraldms” for successful requests to API routes containing URL-encoded values such as %2F, while auditing recently created accounts for suspicious naming patterns. The new flaw makes things worse The situation became more serious on September 6, when N-able disclosed CVE-2026-86218, a separate pre-authentication RCE vulnerability with a CVSS score of 10.0. N-able as well as Huntress researchers said the flaw has been exploited in the wild and that customers should patch immediately. Technical details of the exploitation remain unavailable, presumably to allow administrators time to patch vulnerable systems. N-able’s Hotfix 4 supersedes Hotfix 3, and on-premises customers should, and on-premises customers should apply it immediately. Huntress also recommended restricting inbound access to the N-central console using controls such as IP allowlisting or a VPN, rather than leaving the RMM interface broadly exposed to the internet. Organizations should also review user creation, permission changes, and API activity for signs of abuse, the researchers noted.