CVE-2026-18556 and CVE-2026-18577 - Unauthenticated Administrative Account Takeover and Additional Attack Path in N-able's N-central Product

Last Updated: 2026-08-11T14:45:18Z
https://www.n-able.com/blog/n-central-security-update-august-6-2026

A threat actor exploited a vulnerability in N‑central that allowed remote administrative access without authentication. Once inside, they used N‑central’s Take Control feature to connect to managed devices, and registered Cloudflare tunnel services on those devices to maintain persistence even after their access to N‑central was revoked. Hotfix 1 addressed the original access point. Continued monitoring identified a related attack path, which Hotfix 2 addresses with additional hardening.

This is being tracked (so far) as CVE-2026-18556 and CVE-2026-18577. CVE-2026-18577 was later identified and registered, and additional Indicators and CVEs will be shared as they become available.

CVSSv3: 7.4, 8.1

Actions

  • Apply Hotfix 2, as well as any new patches released
  • Enforce MFA across all accounts
  • Disable the in-product support account
  • Audit user access and look for anything unfamiliar
  • Review the IoCs for presence of attackers, as well as monitor for other suspicious or unexpected activity.

Indicators of Compromise

Value Type Description
73[.]249[.]252[.]200 IPV4 Suspicious traffic from IP
185[.]156[.]46[.]150 IPV4 Suspicious traffic from IP
23[.]234[.]94[.]43 IPV4 Suspicious traffic from IP
37[.]153[.]90[.]88 IPV4 Suspicious traffic from IP
37[.]19[.]210[.]32 IPV4 Suspicious traffic from IP
68[.]235[.]46[.]214 IPV4 Suspicious traffic from IP
68[.]235[.]46[.]235 IPV4 Suspicious traffic from IP
87[.]249[.]138[.]34 IPV4 Suspicious traffic from IP
92[.]118[.]112[.]181 IPV4 Suspicious traffic from IP

Original Post


I’m sure folks have read about N-able’s N-central security vulnerability, documented as CVE-2026-18556 (it’s a CWE-288 issue (e.g., authentication bypass using an alternate path or channel)).

The company has been tracking this issue fairly actively for about a week at https://uptime.n-able.com/, and they’ve had to issue 3 updates/hotfixes after a couple of successful attempts.

What I’m actually posting about is the after effects of compromise. There’ve been some reports of customers experiencing persistent compromise even after the vulnerability has been patched, mainly due to malicious actors establishing Cloudflare tunnels on endpoints. N-able has a decent blog post at https://www.n-able.com/blog/n-central-security-update-august-6-2026 with IoCs.

I’m curious, has anyone here actually seen a compromised system? Is there any evidence that can be shared?

Thanks.


Additional Sources

2 Likes

This one might be tough since mid-large enterprises have likely blocked and hunt on N-able. For larger orgs RMMs on the file system are auto-contain worthy.

But it certainly has a place among MSPs. I have trust issues with MS{1,2}P . So I’d aim comms at their customers.

These orgs aren’t likely to have the CTI, Threat hunting and observability.

What is the best lever here to help support orgs likely affected by a 3rd party technology they aren’t aware of? Cyber insurance?

Oh I’m with you. I posted this from $Job2, where I’m the IT department, and a customer of a small MSP who uses N-able on our computers. Sad week for me.

Believe me, I wish I had the answers!

1 Like

In lieu of a a CISA and MS-ISAC, I hope every state CIRT and Berkeley-modeled Civil Cyber team has this top-of-mind.

But 2026’s best de facto regulation is via cybersecurity insurance. Which lags behind the holder’s policy year.

(Remember when ransomware was paid with kidnapping policies? Loljajalol :skull:)

From the post:

Releasing specific technical details while threat actors are still active also gives them information they can use. We made a deliberate decision to protect our customers first and explain later. A full root cause analysis is coming, and we will share it as soon as it is safe to do so

That horse left the barn. I really wish this thinking would die.

1 Like