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 5: CISA added the earlier CVE-2026-18556 to the same catalog.
• 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.

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.10 now even if you took the earlier hotfix, 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.10 or later? 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.

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.