The tool your IT provider uses to reach your computers got broken into

Most of the security stories we write up here are about software you run yourself. SharePoint on your own server. A Metabase dashboard pointed at your database. In both cases the fix ends with someone on your side installing a patch.

This one is different, and it is worth understanding for exactly that reason. In the first week of August 2026, attackers broke into N-able N-central, a remote monitoring and management platform that managed service providers use to administer their clients’ computers. If you are a small business with an outsourced IT provider, there is a decent chance you have never heard of N-central and an equally decent chance it has an agent installed on every machine in your office right now.

That is the whole point. The compromise did not start with you. It flowed downhill.

What an RMM actually is

Remote monitoring and management software is how an IT provider does its job at scale. One console, an agent on every managed machine, and from that console a technician can see which devices need patches, push software, run scripts, and take remote control of a desktop to fix something while the person who owns it watches the cursor move.

It is genuinely useful, and it is the reason a three-person IT shop can support four hundred endpoints across thirty companies. It also means the console is, functionally, administrator on every one of those endpoints. There is no way to build the useful version of this tool without that being true.

So when the console has an authentication bypass, the blast radius is not one company. It is every company that provider manages.

What happened

On July 31, 2026, N-able’s own managed detection service flagged unusual activity inside a customer environment. What it found was a threat actor exploiting a previously unknown flaw in N-central that let them reach administrative control of the console without logging in at all. No password, no valid session, no prior access.

The vulnerability is tracked as CVE-2026-18577, rated 8.2, and it affects N-central versions up through 2026.3.1. The uncomfortable detail is that it is an incomplete patch for an earlier authentication bypass, CVE-2026-18556. The first fix closed the front door and left a window open.

The timeline from there was fast on both sides:

• August 2: N-able published an advisory and shipped Hotfix 1, build 2026.3.1.7.
• August 3: CISA added CVE-2026-18577 to its Known Exploited Vulnerabilities catalog and gave federal agencies until August 6 to patch. A three-day deadline is not routine.
• August 4: CISA added the earlier CVE-2026-18556 to the same catalog, with a deadline of August 7.
• August 6: N-able shipped Hotfix 2, build 2026.3.1.10, after identifying a related attack path that Hotfix 1 did not close. Hotfix 2 is required even on servers that already took Hotfix 1.

Update, September 9, 2026. This happened again, and worse. On September 8, CISA added CVE-2026-86218 to the KEV catalog: a static code injection flaw in N-central rated CVSS 10.0 that allows pre-authentication remote code execution. It is confirmed exploited in the wild, and the federal deadline is September 11. Pre-auth is the important word. The August flaws below still required an attacker to get past something. This one does not: network access to an exposed N-central server is the entire prerequisite, on a platform that holds privileged agent credentials for every endpoint in every client network it manages. The fix is N-central 2026.3 Hotfix 4, build 2026.3.1.14. It is the fourth hotfix in about five weeks, and CVE-2026-86218 arrived alongside a separate pair, CVE-2026-86206 and CVE-2026-86207, which chain to let a remote unauthenticated attacker create their own System Administrator account. Question 1 in the list below now reads: are you on build 2026.3.1.14 or later. And watchTowr’s line on this round is the one to repeat to your provider: “Patching alone is not enough.” A compromise that predates the hotfix survives the hotfix, so the indicator hunt is not optional.

Correction, August 22, 2026. We originally dated the second catalog entry to August 5. CISA’s own Known Exploited Vulnerabilities feed records CVE-2026-18556 as added on August 4, 2026, with a remediation due date of August 7. The rest of the timeline checks out against the same feed. The three-day deadline we flagged as unusual has since become the norm: CISA now issues it on most new entries under BOD 26-04, the risk-based patching directive that took effect in June.

N-able’s hosted environments were updated by N-able. On-premises installations, where a provider runs the N-central server on its own infrastructure, needed an administrator to go install the thing.

What the attackers did once they were in

This is the part that matters to a small business owner, because it is not abstract.

After taking over a console, the attackers used N-central’s built-in Take Control feature, the same remote-access function a technician uses for legitimate support, to open sessions into managed servers and workstations. That included domain controllers, the machines that hold the keys to a company’s entire Windows network. They enumerated running processes, poked around for the systems worth targeting, and moved between hosts.

Then they set up persistence. On compromised endpoints they registered a service running Cloudflare’s tunnel client, cloudflared, which opens an outbound connection the attacker can come back through later. Outbound connections tend to sail through firewalls that block inbound ones, and the traffic looks like ordinary encrypted web traffic to a legitimate provider.

The important consequence: that tunnel survives the fix. If an attacker got into your machines and left a tunnel behind, patching the N-central server closes the door they came in through and does nothing about the one they built on the way out. N-able said as much in its own update, that patching does not remove a threat actor who may already be present.

They were also careful. Sessions were routed through commercial VPN services, and at least one login used N-central’s default “MSP Support” account name, which blends into a log full of legitimate support activity.

N-able has said a limited number of customers were identified as impacted and that it contacted each of them directly. It has not published a number.

What to actually do

If you run an IT provider or manage N-central yourself, the list is short: install 2026.3.1.14 now, which is Hotfix 4 and supersedes every earlier fix in this article, get the console off the public internet and behind a VPN, enforce multi-factor authentication on every account including support accounts, and hunt for the published indicators rather than assuming you are clean.

If you are a small business whose IT is outsourced, which describes most of the people reading this, your job is different. You cannot patch this. You can ask about it, and the answers tell you a great deal about who you have hired. Send your provider an email today with five questions:

1. Do you use N-able N-central, and if so, are you on build 2026.3.1.14 or later? (That is Hotfix 4, released in early September for the CVSS 10.0 pre-auth flaw in the update above. Build 2026.3.1.10, the answer we asked for in August, is no longer sufficient.) If they use a different RMM platform, fine, but ask which one and whether it has had any advisories this year. The answer “we do not use that product” is a complete answer to the first half only.
2. Was your console reachable from the public internet between July 31 and when you patched? This is the question that decides whether you were exposed at all. A console that only accepts connections over a VPN was not sitting there to be found.
3. Have you checked our machines for the published indicators of compromise? Specifically: a service named Cloudflared that nobody installed on purpose, and an svchost.exe sitting in a user’s Documents folder, which is not where that file lives on a healthy Windows machine.
4. Are there any Take Control or remote sessions in our logs that you cannot account for? A good provider can answer this from records. A provider who cannot tell you who remoted into your machines and when has a bigger problem than this vulnerability.
5. Is multi-factor authentication enforced on every account in your management console, including your own support accounts? Unauthenticated bypasses are rare. Stolen technician credentials are not, and MFA is the control that matters for the common case.

Update, September 12, 2026: add a sixth question, because it is now a different product. On September 11, CISA added CVE-2026-84869 in ConnectWise ScreenConnect to the Known Exploited Vulnerabilities catalog with a three-day deadline of September 14. ScreenConnect is the other tool in this category, and if your provider answered question one with “we do not use N-central,” there is a reasonable chance this is what they use instead.

The flaw matters because of the specific thing it defeats. CISA’s entry describes an improper privilege management and missing authorization issue that “may allow an attacker to file transfer and execution through an active remote session without authorization or host confirmation.” Host confirmation is the prompt on your screen asking whether you want to let the technician in. This bypasses it. So the abuse path is: an attacker who reaches a ScreenConnect session gets to push and run a file on your machine without the consent step that exists precisely to stop that.

So, question six: Do you use ConnectWise ScreenConnect, and if so, have you applied the fix for CVE-2026-84869? CISA’s federal deadline is September 14. Yours is the same week.

The pattern this makes with the N-central entries is the point. Two different vendors, both remote-access platforms for IT providers, both actively exploited, both inside six weeks. This is not one vendor having a bad year. Remote management is the highest-value target surface in small business IT, because one compromise reaches every client at once, and attackers have worked that out. The general question to your provider, which outlasts any particular CVE, is: what is the name of the tool you use to reach our machines, and how will you tell us when it has an advisory?

If those questions get you a clear, specific, same-week answer, you have a good provider. If they get you a shrug, that is worth knowing too, and it is worth knowing before something happens rather than after.

The uncomfortable general lesson

Outsourcing IT is the right call for most small businesses. You get patching, monitoring, backups, and a phone number to call, for less than a fraction of one salary. We recommend it constantly. Nothing about this incident changes that math.

What it should change is how you think about the trust you are extending. Your provider does not just have access to your systems. Their tooling has administrator rights on every machine you own, and their security posture is now part of yours. That is a real dependency, and like any dependency it is worth asking questions about once a year rather than never.

The same logic we applied to keeping your own servers patched applies one level up the chain. Somebody has to own the question. If the answer is “our provider does,” make sure the provider knows that, and make sure they can prove it.

If you want a second opinion on how your IT is managed, or help writing the questions above into an actual vendor review, send us a note.