SimpleHelp CVE-2026-48558: Unverified OIDC Signature, RMM Takeover (CVSS 10.0)

CVE-2026-48558 (CVSS 10.0) is the kind of vulnerability that makes you wince: SimpleHelp, a remote access and RMM tool used by MSPs and internal support teams, accepts OIDC identity tokens without verifying their cryptographic signature. An unauthenticated attacker forges a token carrying whatever identity claims they like and obtains a fully authenticated technician session. No user interaction required. In some configurations, MFA is bypassed too.

The CVE was added to the CISA KEV catalog on June 29, 2026 with a three-day remediation deadline. It is exploited in the wild.

Technical Details

The bug, in the advisory's own words

SimpleHelp versions 5.5.15 and prior and 6.0 pre-release versions contain an authentication bypass vulnerability in the OIDC authentication flow. When OIDC authentication is configured, identity tokens submitted during login are accepted without verifying their cryptographic signature. In a vulnerable configuration, a remote, unauthenticated attacker can submit a forged token containing arbitrary identity claims to obtain a fully authenticated technician session. In some configurations, this may also allow bypass of multi-factor authentication. No user interaction is required.

Why this is a foundational failure

OpenID Connect rests entirely on the signature of the identity JWT. An ID token has three parts: header, payload, signature. The payload holds the claims (sub, email, groups…) and is merely base64-encoded, not encrypted — so anyone can read and modify it.

The only thing stopping an attacker from rewriting the payload to taste is signature verification against the identity provider's public key (fetched from its JWKS endpoint).

Skipping that verification turns authentication into a mere declaration: the attacker crafts a JWT with "email": "admin@victim.com", leaves the signature empty or random, and the application believes it.

Hence the 10.0, logically: no prior authentication, low complexity, changed scope (compromise extends beyond SimpleHelp to every managed endpoint), maximum impact on all three axes.

Affected Products and Versions

Important condition: the vulnerability only affects instances where OIDC authentication is configured. If your technicians authenticate solely with local SimpleHelp accounts, you aren't exposed to this CVE — but verify that rather than assume it.

Exploitation and Impact

What a technician session actually is

This is where severity goes far beyond mere application access. In an RMM tool, a technician account can typically:

• Take remote control of any managed endpoint, without user consent
• Execute commands as SYSTEM/root on inventoried machines
• Deploy executables at scale across the fleet
• Transfer files in both directions
• Browse the full inventory: machines, users, addresses, client organisations

Why RMMs are a top-tier target

An RMM tool is an attack multiplier. Compromise one server and you reach every endpoint it manages. At an MSP, that means every endpoint of every client, simultaneously.

This pattern is well documented in ransomware history: operators deliberately target MSP administration and monitoring tools because the payload then propagates through a perfectly legitimate channel — the management agent itself, signed, authorised, and invisible to EDR, which treats it as an expected administration tool.

Realistic scenario

1. The attacker identifies an internet-exposed SimpleHelp instance (the technician portal is exposed by nature, since technicians work remotely)
2. They detect that OIDC authentication is enabled
3. They forge an ID token with a known technician's email address (LinkedIn is often enough) or an administrator account
4. They submit the token to the login flow → authenticated technician session, MFA possibly bypassed
5. They enumerate the managed machine inventory
6. They deploy their payload through the legitimate distribution feature

Between steps 1 and 6 there is no memory exploit, no malware, no EDR signal — only normal use of an administration tool with a fraudulently obtained session. That's what makes this attack class so hard to detect.

Detection and IOCs

SimpleHelp authentication logs

This is the primary control point. Look for:

• Successful technician logins from geographically or organisationally inconsistent IPs
• Sessions without an MFA challenge when policy requires one
• Technician logins outside their usual hours
• OIDC tokens whose iss (issuer) doesn't match your declared identity provider

Correlation with the identity provider

Here's the decisive test: every OIDC-authenticated SimpleHelp session must have a matching sign-in event at your IdP (Entra ID, Okta, Keycloak…).

A SimpleHelp session without a corresponding IdP event = forged token. That's an unambiguous indicator of compromise, and it's verifiable retroactively against your existing logs.

Post-compromise activity

• Remote control sessions not tied to a support ticket
• Script execution or package deployment outside maintenance windows
• Large file transfers from managed endpoints
• Creation of new technician accounts

Mitigation and Patch

1. Update immediately

Move to 5.5.16 or later. Given the score, active exploitation, and the tool's role, this update warrants an emergency window.

2. Temporarily disable OIDC if you can't patch right away

Moving technicians back to local accounts with MFA removes the attack vector while you schedule the update. It's inconvenient, but effective and immediate.

3. Take the server off the internet

A technician portal has no business being publicly exposed. Put it behind a VPN or conditional access. That drastically shrinks the surface for this CVE and the next ones.

4. Incident response — do this even after patching

If your instance was exposed with OIDC enabled between June and your update date, treat compromise as possible:

1. Correlate every technician session from the last 90 days against your IdP logs — any orphan session is a signal
2. Audit technician accounts: creations, role changes
3. Review remote session and script deployment history
4. Rotate secrets: OIDC configuration (client secret), local account credentials
5. If you're an MSP: notify your clients per your contractual and regulatory obligations

5. Long-term hardening

• Enforce MFA at the IdP rather than in the application — then an application-level bypass doesn't defeat central policy
• Apply conditional access: geographic restriction, device compliance
• Ship SimpleHelp logs to an external SIEM with an alert rule on technician sessions lacking an IdP match

Why Continuous Monitoring of Administration Tools Matters

RMM, remote access and monitoring tools (SimpleHelp, ScreenConnect, AnyDesk, TeamViewer, N-able, Kaseya…) share a distinctive risk profile: maximum privileges across the whole fleet, internet exposure by functional necessity, and near-systematic absence from classic vulnerability inventories. A 10.0 CVE in this category is worth, in real-world impact, several dozen CVEs on isolated application servers.

With cveo.tech, inventory your administration and support tools alongside your critical servers, and get automatic alerts whenever a CVE — especially a KEV-listed one — targets one of your exact versions. Because a flaw in the tool that controls your fleet won't wait for the next quarterly review.