Back

Episode 40: Your RMM Is the Target Now: What Three Summer Vulnerabilities Mean for MSPs

TL;DR

This episode breaks down three vulnerabilities disclosed within weeks of each other this summer, in Arista VeloCloud Orchestrator, SonicWall's remote access appliances, and N-able's RMM platform, and why the pattern matters more than any single incident. It covers why the tools MSPs use to manage everything else have become the highest value targets in the environment, and what a real security operations layer catches that a single tool's own dashboard cannot.

Episode notes


Christina

So I want to start with a question that I think most MSPs would answer wrong without even realizing it. When was the last time you patched the tool you use to patch everything else?

Adam

Right, and that's not a trick question. Most MSPs have a really mature process for patching client systems. Way less mature for their own management tools.

Christina

Which is exactly the gap that got exploited this summer. Three separate incidents, three different vendors, all within a few weeks of each other.

Adam

Let's walk through them, because the pattern matters more than any one of them on its own. First one, Arista. They make a product called VeloCloud Orchestrator, and it's basically the control panel for managing a whole fleet of SD-WAN devices, the boxes that manage network traffic across a bunch of sites.

Christina

So one login, potentially touching every site that orchestrator manages.

Adam

Exactly. And the vulnerability here was about as bad as it gets. An attacker didn't even need a username or password. They could send a request to the system and run commands directly on it. It got the maximum severity score there is, and it was already being exploited before the patch even came out.

Christina

That's the part that always gets me. Not "here's a flaw, go patch it." It's "this is already happening in the wild, go patch it now."

Adam

Right. And it landed on the government's known exploited vulnerabilities list almost immediately, which is basically an official flag that says agencies and critical infrastructure need to patch this one on an emergency timeline, not a normal one.

Christina

Can you explain what that list actually is, for anyone who hasn't run into it before?

Adam

Sure. The Cybersecurity and Infrastructure Security Agency keeps a running catalog of vulnerabilities that are confirmed to be under active exploitation, not just theoretically dangerous. Getting added to that list is a signal that this isn't a someday problem, it's a this week problem. Federal agencies actually have binding deadlines to patch anything on it, and most serious security teams treat it as a de facto priority list even though it isn't legally binding on private companies.

Christina

So if an MSP sees a tool they run show up there, that's the moment to stop what you're doing.

Adam

Pretty much. It's one of the simplest ways to cut through vendor noise and know which patch actually needs to happen today versus which one can wait for the normal cycle.

Christina

So this wasn't some quiet advisory nobody noticed.

Adam

Not even close. Second one, a company called SonicWall, they make remote access appliances, basically the boxes that let remote workers connect securely into a network. Two flaws chained together. One let an attacker open a connection to services that should only ever be reachable from inside the box itself, no login required at all. The second let them escalate all the way to full control of the device.

Christina

So a stranger walks in the side door, and then just takes the keys to the whole building.

Adam

That's basically it. And this one actually led to ransomware, didn't it.

Christina

It did. A group called INC Ransomware became the most active actor exploiting that particular chain, and new victims were still showing up on their leak site into August. This wasn't a theoretical risk anybody could shrug off.

Adam

So that's two. What's the third?

Christina

Third one is probably the most interesting, because it's not really a new vulnerability. It's what happens when a fix doesn't actually fix the problem. A company called N-able makes a really widely used remote monitoring and management platform, RMM for short, that's the tool MSPs use to remotely manage and patch client devices.

Adam

The tool that manages everything else.

Christina

Exactly the pattern we keep seeing. They had an authentication bypass, they patched it, and then attackers found a second way around that same patch just days later. So they had to ship a follow-up fix. And in the window between the first patch and the second one, attackers were using the platform's own remote access feature, the same feature the MSP uses to help clients, to reach into managed endpoints and set up persistent access.

Adam

Using legitimate tools against you, basically.

Christina

That's the theme across all three. Nobody had to write custom malware. They just used what was already there. No exploit kit, no obscure backdoor, just the everyday functionality the product ships with, pointed in the wrong direction.

Adam

Okay, so zoom out for a second. Why does this keep happening to these specific kinds of tools? RMM platforms, orchestrators, remote access boxes.

Christina

Because they're worth more to an attacker than almost anything else in the environment. If I compromise one client's laptop, I get one client. If I compromise the tool that manages hundreds of client environments, I potentially get all of them in one move.

Adam

It's the same logic as attacking a key cutter instead of one lock.

Christina

That's a good way to put it. And it's not only RMM platforms either. The same logic applies to your ticketing and automation system, your backup console, and your network monitoring stack. Anything with a login that can reach more than one client at once is worth more to an attacker than any single endpoint.

Adam

So the target list is broader than most MSPs probably assume.

Christina

Much broader. And there's a supply chain angle to this too that's worth sitting with for a second. A single RMM vendor doesn't serve one MSP, it typically serves thousands of them. So a flaw in that one product doesn't just threaten one business, it's a single vulnerability with the potential to touch every MSP running that platform, and every client behind every one of those MSPs.

Adam

So the blast radius on one of these bugs is enormous compared to almost anything else in the security world.

Christina

Enormous is the right word. And that's exactly why attackers spend real time and money hunting for flaws in these specific products rather than in some random line-of-business application. The return on a working exploit is just so much higher.

Adam

It also explains why patch timing matters so much here. A vendor shipping a fix isn't the end of the story if thousands of MSPs are slow to apply it.

Christina

Exactly, and that's the gap attackers are counting on. The vulnerability gets disclosed, a patch goes out, and there's a window, sometimes days, sometimes weeks, where a meaningful share of the install base just hasn't updated yet. That window is where most of the real damage happens.

Adam

And there's a report that backs this up with real numbers. It's called the 2026 State of MSP Threat Report from Guardz, and one stat from it really stuck with me. Almost nine out of ten monitored small business environments had at least one user with a confirmed credential compromise at some point.

Christina

Right, and the same report flagged that session hijacking is the fastest growing type of attack, specifically because it gets around multi-factor authentication rather than trying to beat it head on.

Adam

So walk me through that distinction, because I think people hear multi-factor authentication and assume they're covered.

Christina

So normal credential theft is somebody stealing your password. Multi-factor authentication stops most of that, because the attacker still needs that second factor. Session hijacking is different. If an attacker steals your actual live session, the thing that exists after you've already logged in and proven who you are, they don't need your password or your second factor at all. They already have your access.

Adam

Which is exactly what happened in that N-able example. Nobody guessed a password. They found a hole in the login process itself.

Christina

Exactly the same shape of problem. And it's worth saying, this isn't a knock on multi-factor authentication as a control. It's still one of the highest value things an MSP can enforce. It just isn't the whole answer anymore on its own, because attackers have adapted around it.

Adam

So if I'm an MSP listening to this, feeling slightly uneasy right now, what do I actually go and check this week?

Christina

A handful of things. First, make a list of every tool you run that has reach across multiple client environments. Your remote monitoring platform, your ticketing and automation tool, any network management tool, your remote access gateway, your backup console.

Adam

The stuff that's easy to forget about because it's not client facing.

Christina

Exactly that. Second, go check that each one is actually on the version the vendor says is safe right now, not just the version you patched last quarter. We just saw a vendor need a second hotfix days after the first one.

Adam

So patched once isn't the same as patched.

Christina

Right. Third, enforce multi-factor authentication specifically on the admin accounts for these tools. Not just on the product you sell to clients, on your own internal tools. And where the vendor supports it, use a phishing-resistant method rather than a basic code, since that closes off some of the session-hijacking angle we just talked about.

Adam

And fourth?

Christina

Review the admin activity logs on these tools on an actual schedule, the same way you'd review a client's logs, rather than only looking when something already feels wrong.

Christina

One more I'd add here, and it's easy to skip past. Do this exercise on your backup console and your ticketing and automation platform too, not just the obvious remote access tools. A backup console often has standing access to every client's data by design, and a compromised ticketing system can be used to push malicious scripts out through the same automation that normally deploys legitimate updates.

Adam

So the same review applies even to tools that don't feel like security tools at all.

Christina

Especially those. Nobody thinks of their ticketing platform as a security risk until it's the thing an attacker used to push a script to every managed device overnight.

Adam

And I'd add a fifth, just from what we talked about earlier. Know exactly what each tool's remote access feature can reach, and make sure a single compromised console can't touch every client at once.

Christina

That's the segmentation piece, yeah. It's basically asking, if this one tool gets compromised tomorrow, how much of my business is exposed. And a sixth, worth adding, is knowing where each tool sits on that known exploited vulnerabilities list we mentioned earlier. If a vendor you run shows up there, that's not a routine patch cycle item, that's a today item.

Christina

There's a client conversation angle here too, worth mentioning before we wrap up. If a client or an insurer ever asks how you know your own tooling is safe, "we patched it once" isn't a great answer anymore, especially after what we just walked through with N-able needing a second fix. Being able to show an actual log of when you checked, what you found, and what you changed matters just as much for your own stack as it does for a client's environment during a renewal or an audit.

Adam

That's a fair point. The same evidence trail MSPs are being asked to keep for clients now applies to their own tools too.

Christina

Right, and it's really the same discipline either way. You can't just tell someone you're secure, you need to be able to show it.

Adam

Which is really the whole point of this conversation. Detection and correlation across every surface, endpoint, network, cloud, identity, and the operational technology side too, that's what actually catches this pattern. A management tool can look totally fine on its own dashboard while its access is being abused somewhere else entirely.

Christina

And that's really the argument for having a real security operations team looking at all of it together, rather than trusting any single tool's view of itself.

Adam

This is basically the whole argument for a channel-only security operations partner that actually watches every surface together. Not just the endpoint, but the network, the cloud side, identity, and the operational technology and physical devices that most tools never even look at.

Christina

Right, and that's more or less the model over at enhanced.io. Built specifically for MSPs, never sold direct to end clients, with real integrations across all five of those surfaces so nothing gets missed just because it happened outside the one tool you were watching. A compromised orchestrator or a compromised RMM console doesn't get treated as a separate problem from a compromised endpoint. It's all the same picture.

Adam

Good place to leave it. This year has made one thing pretty clear, the tools you use to protect your clients need protecting themselves, just as seriously.

Christina

Couldn't agree more. And if this episode has you wanting to actually run through that checklist properly rather than just nodding along, that's exactly the kind of review a Fractional Security Director can walk a partner through, tool by tool, rather than leaving it as a good intention nobody gets back to.