Threat feed liveUpdated — 04.08.2026 10:27 CET86 dossiersMITRE ATT&CK mappingThreat feed liveUpdated — 04.08.2026 10:27 CET86 dossiersMITRE ATT&CK mapping

Unattributed. N-able describes «an attacker» and publishes six IP addresses, naming no grouphigh

The console that commands other people's computers: N-central breached twice, by the same flaw

N-central is the console a managed service provider uses to administer its customers' computers: install, patch, run scripts, open remote-control sessions. On 2 August 2026 N-able disclosed that an attacker had obtained administrative access remotely on those servers, and from there reached the managed endpoints, where it registered a service for a Cloudflare tunnel — so as to remain inside even after access to the console was revoked. The uncomfortable part is the genealogy: CVE-2026-18577 is not a new flaw, it is the same one as CVE-2026-18556 reached by another route, because the earlier fix did not cover every path. CISA added it to KEV on 3 August with a remediation due date of the 6th.

The force multiplier

To see why this story is worth more than the sum of its technical parts, you need to know what N-central is. It is the platform a managed service provider — the company a small business hands "the IT" to — uses to administer its customers' machines: inventory, updates, script execution, remote control of workstations. One panel, many networks that do not belong to it.

Which means the value of that server is not measured by the data it holds. It is measured by the number of machines it can command. Whoever takes it over does not need to breach each customer separately: they have inherited the legitimate channel through which those customers are administered.

What happened, according to the vendor

The account that follows comes from N-able's statement of 2 August 2026, the only first-hand source on the dynamics.

On 31 July 2026 the company records an unusual rise in licensing issues among on-premises N-central customers. Not a rare phenomenon, but the volume is high: engineering and security teams are engaged. On the morning of 2 August, analysis of a previously addressed vulnerability — CVE-2026-18556, fixed in version 2026.2 — reveals another way to reach it. That afternoon the hotfix ships, build 2026.3.1.7, and a new CVE is assigned: CVE-2026-18577.

  1. 31 July 2026
    The symptom

    Unusual rise in licensing issues on on-premises servers.

  2. 2 August 2026 (morning)
    The finding

    The CVE-2026-18556 fix did not cover every route.

  3. 2 August 2026 (afternoon)
    The hotfix

    Build 2026.3.1.7, based on 2026.3.0 released on 30 July.

  4. 3 August 2026
    Into KEV

    CISA records active exploitation. Remediation due date: 6 August.

The chain N-able describes is short and needs no sophisticated malware. The attacker obtains administrative access remotely on the N-central server. From there it uses Take Control, the native remote-control feature, to connect to machines inside the managed environment. On those machines it registers a new service for a Cloudflare tunnel.

That last step is the heart of the matter, and is worth reading twice: it exists to maintain access after access to the N-central server has been revoked. Closing the console does not close the door the console opened elsewhere.

  1. 01
    N-central server
    remote administrative access without valid credentials
  2. 02
    Take Control
    a legitimate feature, used to reach the managed machines
  3. 03
    «Cloudflared» service
    persistence on the individual endpoint, independent of the console

How to check tonight

N-able's status page gives two concrete indicators, and it is the most useful part of the whole disclosure: look on devices for a file named svchost.exe in the user's Documents folder — a legitimate system name in a place where it has no reason to exist — and for a registered service named Cloudflared.

In firewall logs, N-able lists six inbound addresses associated with the attack: 173.249.252.200, 87.249.138.34, 37.19.210.32, 37.153.90.88, 92.118.112.181, 68.235.46.214. The status page lists four, the blog six: we kept the longer list, and this is a discrepancy between two pages of the same vendor, not between different sources.

On remediation: hosted instances (NCOD) receive the upgrade automatically and are notified of the schedule. Self-hosted installations must upgrade manually to 2026.3.1.7, with a direct path from 2025.4, 2026.1, 2026.2 and 2026.3. Upgrading agents is not required for protection against this CVE.

What we do not know, and should say

The scale. N-able writes that "a limited number of customers" are affected and that support has engaged them directly. It publishes no figure. It is not possible today to say how many organisations were reached downstream — which is the real question, since every customer of an affected MSP is a different organisation.

Attribution. None: the statement says "an attacker" and stops there. No official MITRE ATT&CK mapping appears to have been published for this case, so you will not find one here: identifiers are copied from advisories, not inferred from a description.

The score. NVD recorded the CVE on 2 August with status Received and a CVSS v4.0 score of 8.2 (High) from a secondary source, vector AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N, weakness CWE-288 (Authentication Bypass Using an Alternate Path or Channel). Read it with two cautions: it is not yet an NVD-validated score, and it measures the vulnerability in itself, not the product's position in the ecosystem. An 8.2 on a console administering thousands of other people's machines weighs differently from an 8.2 on a bookkeeping app.

A detail that does not quite line up. The NVD description gives affected versions as "through 2026.3.1", while N-able speaks of "all versions prior to 2026.3.1.7". The two do not match literally. Where in doubt, the more cautious reading — the vendor's — applies.

A third-hand figure. Some trade outlets — Help Net Security, citing the security firm Huntress — reported that in early August more than half of reachable servers were still unpatched. We were unable to read Huntress's original analysis directly, so we report it as unverified by us, and will not build any conclusion on it.

The incomplete patch is the real subject

There is a reason this case deserves its own category among the dozens of CVEs that pass every week. It is not that a flaw existed: it is that it had already been fixed.

Anyone who had upgraded to 2026.2 had done everything asked of them. Box ticked, right version number, ticket closed. The difference between that person and someone who had not patched at all turned out, in this episode, to be thinner than anyone would have bet — because the fix closed one route to the defect, not the defect.

The lesson travels beyond N-central. When a vendor fixes an authentication bypass, the useful question is not "did I apply the patch?" but "did the patch address the cause or the occurrence?" In the first case you are done. In the second you bought time, and here the time bought ran from 2026.2 until last Sunday.

Then there is the part that applies to anyone who hands their IT to someone else, which is nearly everyone. The provider managing your machines has, by construction, privileged and permanent access to your network. That is a reasonable arrangement: it is why the service works. But it means your company's attack surface includes your provider's console — a system you do not see, do not patch and do not monitor. Asking what version it is on, and when it was last updated, is a legitimate customer question. This week it is also an urgent one.

More dossiers