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.