CVE-2026-48558: 10 Questions to Ask Your MSP About RMM Security

If your MSP runs SimpleHelp, every workstation and server in your environment was potentially one unpatched console away from full compromise. CISA added CVE-2026-48558 to its Known Exploited Vulnerabilities catalog on July 1, 2026, confirming active exploitation of an unauthenticated authentication bypass in SimpleHelp, a Remote Monitoring and Management (RMM) platform used by thousands of IT providers worldwide. The vulnerability allows an attacker to gain administrative control of the SimpleHelp server without valid credentials, and from there, push commands to every endpoint the server manages.

What CVE-2026-48558 Actually Does

SimpleHelp is one of dozens of RMM platforms that managed service providers use to monitor, patch, and remotely access client systems. The software installs a lightweight agent on each managed device, and that agent maintains a persistent connection back to the provider’s SimpleHelp server. Technicians use the server’s web console to run commands, deploy software, and troubleshoot issues across all client environments from a single interface.

CVE-2026-48558 is an authentication bypass. An attacker who can reach the SimpleHelp server’s web interface can skip the login process entirely and gain full administrative access. The attacker does not need stolen credentials, a phishing campaign, or social engineering. A single network request to an exposed management console is enough.

Once inside, the attacker inherits every capability the RMM platform provides. That includes pushing scripts to managed endpoints, deploying executables, accessing file systems, and modifying system configurations. The same features that make RMM tools efficient for IT support make them devastatingly effective for attackers.

CISA’s addition to the KEV catalog triggers a remediation deadline under BOD 26-04’s risk-based patching framework. For a public-facing, known-exploited, automatable vulnerability that grants full system control, the deadline is three days. SimpleHelp released a patch in late June. Any provider still running an unpatched instance after the first week of July is operating outside the standard that federal agencies, cyber insurers, and compliance auditors increasingly treat as the baseline.

RMM Compromises Are a Pattern, Not an Outlier

CVE-2026-48558 is not the first time a vulnerability in an RMM or remote access platform has been exploited at scale. The pattern is well established, and each incident has reinforced the same lesson: the tools your IT provider uses to manage your systems are among the highest-value targets an attacker can pursue.

Kaseya VSA (July 2021). The REvil ransomware group exploited a zero-day vulnerability in Kaseya’s VSA platform to push ransomware through MSPs to their downstream clients. The attack compromised approximately 60 MSPs and between 800 and 1,500 of their client organizations in a single weekend. Victims included grocery chains, dental practices, accounting firms, and other small businesses that had no direct relationship with Kaseya but were exposed through their provider’s management tool.

SolarWinds Orion (December 2020). While technically a supply chain compromise rather than a vulnerability exploit, the SolarWinds incident demonstrated what happens when attackers gain access to a platform that has trusted, privileged connections to thousands of environments. The attack affected federal agencies, Fortune 500 companies, and IT service providers, all through a single compromised update channel.

ConnectWise ScreenConnect (February 2024). CVE-2024-1709, an authentication bypass in ConnectWise ScreenConnect, was patched in February 2024 but continues to be actively exploited in 2026. Microsoft Threat Intelligence has linked ongoing attacks to threat actors deploying Medusa ransomware through compromised ScreenConnect servers. The vulnerability sat in the KEV catalog for over two years before CISA escalated its urgency.

The common thread across all of these incidents is privileged access. RMM agents run with system-level permissions on every managed endpoint. They maintain persistent outbound connections that most firewalls and security tools are configured to allow. Traffic from the RMM platform looks identical to legitimate IT management activity, which means traditional detection tools often won’t flag it. An attacker who compromises the management console doesn’t need to evade your endpoint detection because they arrive through a channel your security stack is designed to trust.

10 Questions Every SMB Should Ask Their MSP

You don’t need to understand the technical details of authentication bypass vulnerabilities to evaluate whether your provider takes RMM security seriously. The questions below will tell you whether your MSP treats their own management infrastructure with the same discipline they apply to your systems.

1. What RMM and remote access tools are installed on our systems?

Your provider should be able to name every agent and remote access tool running in your environment. If they can’t produce this list immediately, it suggests they don’t maintain a current inventory of their own tooling footprint, which is a problem in itself.

2. Are your RMM servers patched against CVE-2026-48558 and all other known exploited vulnerabilities?

This should be a yes-or-no answer with a specific version number or patch date. Any hesitation or vagueness here is a signal worth paying attention to.

3. What is your patching SLA for critical vulnerabilities in your own management tools?

A responsible provider patches critical RMM vulnerabilities within hours of a vendor advisory, not days or weeks. Ask for a specific number. CISA’s BOD 26-04 framework sets a three-day maximum for the highest-risk vulnerabilities. Your MSP should be meeting or beating that standard for their own infrastructure.

4. Is multi-factor authentication enforced on your RMM platform’s management console?

MFA on the management console protects against credential theft and brute-force attacks. Ask whether it’s enforced for every technician account, including contractors and after-hours staff, not just recommended as a best practice.

5. Is your RMM management console exposed to the public internet?

A SimpleHelp, ScreenConnect, or similar server reachable from any IP address on the internet has a dramatically larger attack surface than one restricted to VPN or IP-allowlisted access. Some providers expose their consoles for convenience. That convenience comes at a cost your business absorbs.

6. Do you segment your RMM infrastructure so that a compromise of one client doesn’t spread to others?

In the Kaseya VSA attack, many MSPs ran a single server managing all client environments. One compromised server meant every client was exposed simultaneously. Ask whether your provider maintains logical or network-level separation between client environments in their management platform.

7. Do you monitor your RMM platform for anomalous activity, or only your clients’ endpoints?

Many MSPs focus their security monitoring on client environments but don’t apply the same scrutiny to their own management infrastructure. Ask whether unusual login attempts, bulk command execution, or off-hours remote sessions on their RMM console trigger alerts and investigation.

8. How do you control which technicians can access which client environments?

Role-based access control within the RMM platform limits the blast radius if a single technician’s account is compromised. Ask whether every technician can access every client, or whether access is scoped to assigned accounts only. The principle of least privilege applies to your provider’s internal access just as much as it applies to your employees.

9. Do you have an incident response plan for a compromise of your own management tools?

This question separates providers who have thought about supply chain risk from those who haven’t. A good answer includes client notification timelines, isolation procedures for affected servers, and forensic steps to determine whether the compromise reached client environments. A bad answer is “that hasn’t happened to us.” Past performance is not a security control.

10. Are you aligned with CISA’s Secure by Design principles for the RMM products you select?

CISA’s Secure by Design initiative asks software vendors to ship products that are secure out of the box, with features like MFA enabled by default, minimal attack surface, and transparent vulnerability disclosure. Ask your provider whether the RMM platforms they choose meet these criteria. Providers who select tools based on price and feature set alone, without evaluating the vendor’s security posture, are passing that risk directly to you.

What to Do If the Answers Concern You

Not every MSP will have perfect answers to all ten questions. Smaller providers in particular may not have formalized every aspect of their RMM security posture. But the quality of the conversation matters as much as the specific answers. A provider who engages openly, acknowledges gaps, and describes concrete plans to address them is in a fundamentally different position than one who deflects or claims everything is fine without evidence.

If your provider can’t tell you what tools are installed on your systems, can’t confirm their patching status, or doesn’t monitor their own management infrastructure, those are material risks to your business. Your cyber insurance carrier may ask about your IT provider’s security practices at your next renewal. Your ability to answer those questions depends entirely on whether you’ve had this conversation.

The broader takeaway from CVE-2026-48558, and from Kaseya, SolarWinds, and ScreenConnect before it, is that your MSP’s security posture is part of your security posture. The tools they use to manage your systems carry the same risk as any other privileged access point in your environment. Treating your IT provider’s cybersecurity practices as outside your scope is the same as leaving a domain admin account unmonitored because someone else controls it.

Start with the ten questions above. Write down the answers. Compare them against what you’d expect from any other vendor with administrative access to your network. The gap between what you find and what you expect will tell you what needs to change.