Cloud Security

SimpleHelp RMM CVE-2026-48558: CVSS 10 OIDC Auth Bypass

June 19, 2026 · 6 min read · By CloudAI Security

SimpleHelp, the self-hosted remote monitoring and management (RMM) platform widely used by IT help desks and managed service providers, is shipping a CVSS 10.0 authentication bypass that turns its OpenID Connect (OIDC) login into a one-step technician-forge. Tracked as CVE-2026-48558, the flaw was disclosed on June 12, 2026 by Zach Hanley of Horizon3.ai — found, notably, by an autonomous vulnerability-hunting pipeline — and it lets an unauthenticated, remote attacker mint privileged “Technician” accounts out of thin air. If you run SimpleHelp with OIDC and haven’t moved to v5.5.16 or v6.0 RC 2, treat the box as compromisable.

A CVSS 10 Authentication Bypass

The CVE sits squarely in SimpleHelp deployments configured to authenticate technicians via OpenID Connect. When OIDC is in use, the server accepts identity tokens submitted during login without verifying their cryptographic signature, according to Belgium’s Centre for Cybersecurity (CCB). That single missing check is the entire vulnerability: forge a token, claim whatever technician-group membership you like, and walk in (CCB Belgium).

Beazley Security frames the impact bluntly: successful exploitation lets an unauthenticated attacker create and access privileged Technician accounts, which by default can remote into managed endpoints, execute scripts, install programs, and view, change, or delete data (Beazley Security). CIS echoes that assessment in advisory 2026-061 — the result is full administrative reach across every machine the RMM console touches (CIS). For an MSP, that is the entire customer estate in a single hop.

How the OIDC Bypass Works

The mechanism is a textbook signature-validation failure. A SimpleHelp server trusts the contents of an OIDC token it never authenticated, so an attacker crafting a token with arbitrary claims — group membership, username, roles — gets it accepted as genuine. Horizon3’s disclosure notes three prerequisites for exploitation: at least one OIDC provider is configured on the server; a TechnicianGroup is associated with that provider; and the “Allow group authenticated logins” setting is enabled on the TechnicianGroup (Help Net Security).

Horizon3 assesses the second condition as effectively guaranteed in any deployment actually using OIDC, and the third was enabled on every client they assessed. The vendor counters that an attacker must also be able to reach the server and connect from an IP permitted by Technician login IP restrictions — so boxes walled off behind trusted IP ranges carry meaningfully lower risk. But that defense only holds for the disciplined minority; the exposed majority has no such filter.

MFA Buys You Nothing Here

The detail that should unsettle every defender: this bug bypasses MFA enforcement. Even when the SimpleHelp server is configured to require multi-factor authentication for technicians, the bypass holds — because on first login, a freshly forged Technician can self-register their own MFA method. The attacker controls both the identity and the second factor. Horizon3 flagged this explicitly, and it is the reason this is a 10.0 and not a routine 8.x: there is no compensating control inside the product that closes the gap (Help Net Security).

The implication for cloud and identity teams is that OIDC-based SSO in front of an RMM is not, by itself, a defense — the same class of identity-layer audit gap that bit Okta applies here too. The trust has to terminate in a correctly validating endpoint — and SimpleHelp, prior to patch, was silently discarding the validation step entirely.

Exposure and Ransomware Precedent

Horizon3 reports roughly 14,000 SimpleHelp servers exposed on the internet, and a random sampling found about 7.2% configured to use the vulnerable OIDC method — on the order of 1,000 reachable, vulnerable consoles (Help Net Security). That is a concentrated, high-value target list for initial-access brokers, and SimpleHelp has form here: the three SimpleHelp server vulnerabilities Horizon3 disclosed in January 2025 were subsequently exploited by ransomware operators (Beazley Security).

At the time of June’s disclosure, SimpleHelp stated it was not aware of malicious exploitation of CVE-2026-48558, and Horizon3 deliberately withheld technical exploit details. But the 2025 precedent is the operative warning — RMM flaws that look quiet at disclosure have a habit of lighting up ransomware pipelines months later. The patches shipped in late May 2026, and the gap between fix-availability and disclosure is the window attackers care about.

Detection: Hunt For Forged Technicians

SimpleHelp’s own guidance, echoed by CIS and Beazley, is to hunt for the artifacts a forged Technician leaves behind. The table maps the highest-value signals to where you will find them.

Signal	Location	What It Indicates
Unexpected Technician accounts	Administration → Technicians	Forged account from bypass
New logins / sessions	Server logs	First-use of minted identity
Script runs, tool execution	Session / audit logs	Post-auth privileged action
Activity from unrecognized IPs	Server access logs	External actor pivoting
Self-registered MFA methods	Technician MFA settings	Attacker locking the account

Any of these against an OIDC-configured server still running an unpatched build is presumptive compromise until proven otherwise.

Mitigation: Patch, Then Disable OIDC

Upgrade to SimpleHelp v5.5.16 (stable) or v6.0 RC 2 (pre-release); everything below v5.5.16 and below v6.0 RC 2 is affected (Beazley Security). If you cannot patch immediately, Beazley recommends disabling OIDC authentication to remove the vulnerable code path — a functional trade-off that closes the hole at the cost of login convenience. Where neither is feasible in the short term, disconnect the server from the internet entirely and restrict Technician login to trusted IP ranges; SimpleHelp itself stresses that local-network-only or IP-restricted deployments are at far lower risk (Help Net Security).

Apply the patch, then immediately run the detection hunt above. The assumption must be that anything reachable and unpatched has already been probed.

RMM Is Initial Access Infrastructure

The wider lesson is that RMM consoles — SimpleHelp, ScreenConnect, ConnectWise, the lot — are not productivity tools from a security standpoint. They are initial-access infrastructure, and they are treated as such by every ransomware affiliate worth tracking. A single authentication bug in an RMM tier is a skeleton key to thousands of endpoints, which is precisely why phishers and IABs have spent years abusing trusted RMM tooling to compromise dozens of organizations at a time, as documented in the VENOMOUS#HELPER RMM abuse campaign. CVSS 10 in that context is not a score; it is a deadline.

OIDC signature validation is table-stakes engineering, and a vendor shipping a CVSS 10 because it skipped it deserves scrutiny. But the burden still lands on operators: inventory every RMM console, assume it is internet-exposed by accident, and validate that the identity tokens it consumes are actually being checked.