SimpleHelp CVE-2026-48558: a CVSS 10 RMM Bypass That Steals Your Cloud and AI Keys

On June 29, 2026, BleepingComputer reported that attackers were exploiting a critical SimpleHelp flaw to drop a brand-new infostealer. The bug, CVE-2026-48558, scores a perfect CVSS 10.0 and was disclosed by Horizon3.ai on June 12. The same day, CISA added the flaw to its Known Exploited Vulnerabilities catalog, putting it on the federal remediation clock under BOD 26-04. SimpleHelp is remote monitoring and management (RMM) software — the tool a managed service provider uses to reach into every customer endpoint it administers. The vulnerability lets an unauthenticated attacker mint a privileged technician account, and the in-the-wild chain that followed uses that foothold to deploy a stealer whose shopping list is unusually 2026: not just passwords and browser cookies, but SSH keys, Docker credentials, Terraform state, GitHub CLI tokens, and the configuration files for AI coding assistants. The RMM server you trusted to manage everything just became the single best place from which to rob you.

What CVE-2026-48558 actually is

The flaw lives in SimpleHelp's OpenID Connect (OIDC) login flow, and the root cause is almost embarrassingly clean. Per the NVD entry, the server accepts the OIDC identity token a client presents at login without verifying its cryptographic signature. That is the entire bug — CWE-347, improper verification of a cryptographic signature — and it is why this earns a 10.0 with the vector AV:N/AC:L/PR:N/UI:N/S:C.

Think about what an OIDC ID token is: a JWT that asserts "this user is alice@corp, vouched for by your identity provider." The provider signs it so the relying party can trust the claim. SimpleHelp skipped the signature check. So an attacker does not need to steal a token or phish a session — they forge one. Hand-craft a JWT that claims membership in a technician group, present it, and the server reads the claims, trusts them, and issues a fully privileged technician session. No password, no MFA prompt, no provider round-trip that would catch the forgery.

Three conditions have to hold on the target for the door to open:

• At least one OIDC provider is configured on the server.
• A TechnicianGroup is associated with that OIDC provider.
• "Allow group authenticated logins" is enabled on the TechnicianGroup.

That is a common, vendor-documented configuration — exactly how an MSP wires SimpleHelp into its corporate SSO so technicians log in with their normal identity. The feature that makes onboarding convenient is the feature that, unsigned, hands the keys to anyone on the internet.

Why an RMM server is the worst possible box to lose

An RMM platform is not just another web app with a bad bug. It is, by design, a privileged remote-access hub with a standing connection to every machine it manages. Compromise the RMM and you do not get one host — you get the fleet, through the one channel that is supposed to be sending remote commands to endpoints. There is no clearer example of T1219 (Remote Access Software) abuse: the malicious activity is indistinguishable, at the protocol level, from the legitimate purpose of the tool.

This is not theoretical for SimpleHelp specifically. In 2025, CISA published advisory AA25-163A after ransomware actors exploited unpatched SimpleHelp instances to reach a utility billing software provider — and through it, that provider's downstream customers. The RMM was the pivot from one breach into many.

The exposure numbers for CVE-2026-48558 say this will play out the same way. Researchers found nearly 14,000 SimpleHelp servers reachable on the internet, with roughly 7.2% — on the order of a thousand — running the vulnerable OIDC configuration. A thousand RMM servers, each a gateway into the estate it manages, with a CVSS 10.0 that needs no credentials.

Djinn Stealer goes after the keys to your cloud and your AI

Here is where this incident stops looking like a 2020 ransomware play and starts looking like a 2026 one. The observed chain does not encrypt anything. It exfiltrates.

After exploiting CVE-2026-48558 to establish a technician session, the actor deploys TaskWeaver, an obfuscated JavaScript loader masquerading as jquery.js, pulled from a throwaway Cloudflare-fronted domain (T1105, Ingress Tool Transfer). TaskWeaver then installs Djinn, a previously undocumented cross-platform stealer that runs on Windows, macOS, and Linux. Its target list is what makes it worth writing about:

• Cloud provider credentials and identity-service tokens.
• SSH private keys and Git configuration.
• Docker credentials and Terraform state.
• GitHub CLI tokens and package-registry / build-tool authentication.
• The configuration files for AI coding assistants — including Claude MCP server configs.
• Crypto wallets, browser data, and, on Linux, process environment variables.

Read that list again. It is not the inventory of someone after a quick credential-stuffing payday. It is the inventory of someone who wants to move laterally into your supply chain. SSH keys and Git config get them into your source. Docker and registry tokens get them into your build pipeline. Terraform state hands them a map of your entire cloud, often with secrets embedded. And the MCP and AI-assistant configs are the new soft underbelly: those files frequently hold API keys and the connection details for the tools an AI agent is authorized to call — a credential class most organizations have no inventory of and no rotation policy for. An RMM compromise that started as an unsigned JWT ends as a standing key to your cloud, your code, and your AI tooling.

The patch closes the door — it doesn't delete the technician

SimpleHelp fixed the signature-verification flaw in version 5.5.16 (stable) and 6.0 RC2. Applying it is necessary and urgent. It is also not the same thing as being clean, and conflating the two is how this incident quietly survives your remediation.

The exploit's first act is to create an account — a privileged technician. Patching the OIDC flow stops new forged logins. It does not remove a technician account an attacker already created during the exposure window, any more than changing a lock removes the copy of the key the burglar made while it was open. That account is now a legitimate, signed-in-the-database credential: T1078, Valid Accounts. It will survive the update, the reboot, and the "we're patched" status report.

"We're on 5.5.16 across all SimpleHelp servers — we closed it out." "You closed the bypass. Did you delete the technician accounts that were created through it? Pull the account list and the creation timestamps — which one of those did the audit?"

This is the same structural trap we wrote about with Ubiquiti UniFi's rogue 'John Sim' admin accounts: a version scanner confirms the fix and goes green, while the planted account, the loader still on disk, and the credentials already exfiltrated sit entirely outside its field of view.

What each control actually sees

Lay the usual controls against this specific chain and the blind spots line up:

Control	Sees the unpatched flaw?	Sees the rogue technician account?	Sees Djinn exfiltrating keys?
Version / patch scanner	Yes, once the CVE + fixed version exist	No — version reads "fixed", account is invisible	No
EDR on endpoints	n/a on the appliance	No	Partially — if an agent runs where Djinn lands
SIEM (next-day logs)	No	Only if you knew to query account creation	After the fact, if the logs survived
Network traffic ML	Indirectly	The loader fetch and the new outbound sessions are on the wire	Yes — the exfil egress is the event
Offensive re-test (assumed breach)	Reproduces the chain	Yes — enumerates the planted account	After the fact, but conclusively

Two columns carry the incident: the rogue-account column, where every passive control fails, and the exfiltration column, where the only thing watching in real time is whatever models the traffic.

Remediation

A complete runbook, ordered the way you should actually work it. Patching is step two, not the end.

1. Am I affected?

• Check the running version in the SimpleHelp admin console. Affected: 5.5.0 through 5.5.15, and all 6.0 pre-release builds through RC1.
• Determine whether the vulnerable configuration is live: an OIDC provider configured, a TechnicianGroup bound to it, and "Allow group authenticated logins" enabled. If all three are true, you were exploitable; the ~7.2% figure is for exactly this combination.
• Establish your exposure: is the SimpleHelp server reachable from the internet? Treat any internet-facing instance that was on a vulnerable build with OIDC enabled as presumed-compromised until proven otherwise, not the reverse.

2. Patch — exact fixed versions

• Upgrade to SimpleHelp 5.5.16 (stable branch) or 6.0 RC2 (6.0 branch). These verify the OIDC token signature. There is no configuration-only fix that restores signature checking on an unpatched build.
• This stops new forged logins. It does nothing about an account already created — proceed to steps 4 and 5 regardless of how quickly you patched.

3. Can't patch this hour? — compensating controls

• Take the SimpleHelp web interface off the public internet immediately: restrict to VPN / management network / all-listed IPs. An RMM console has no business being open to the world.
• If you can tolerate the operational hit, disable OIDC group-authenticated logins until patched — removing any of the three preconditions removes the attack path.
• Put the server behind a reverse proxy or WAF that enforces source-IP allow-listing for the login endpoints. This is containment, not a fix.

4. Hunt for compromise

• Enumerate all technician accounts and sort by creation timestamp. Anything created during or after the exposure window that you cannot tie to a known onboarding is suspect. Map this to T1136 (Create Account) and T1078 (Valid Accounts).
• Review technician login and session logs for authentications from unrecognized IPs, ASNs, or geographies — especially sessions that ran tools or pushed files to managed endpoints.
• Look on managed endpoints and the server for jquery.js in unexpected paths (the TaskWeaver loader) and for outbound fetches to recently registered Cloudflare-fronted domains (T1105, T1059.007 JavaScript).
• Hunt for credential access and staging: reads of ~/.ssh, ~/.docker/config.json, Terraform state files, gh CLI config, and AI-assistant / MCP config files (T1552.001 Credentials in Files, T1552.004 Private Keys).
• Watch for exfiltration egress — sustained or bursty outbound from hosts that normally only receive management traffic (T1041 / T1567).

5. Eradicate + verify

• Delete every confirmed-rogue technician account and revoke its sessions.
• Remove TaskWeaver / Djinn artifacts from the server and any managed endpoint they reached.
• Rotate everything Djinn touches as if it is already public: SSH keys, cloud and identity tokens, Docker and registry credentials, GitHub CLI / PAT tokens, Terraform-embedded secrets, and any API keys in AI-assistant / MCP configs. Rotation, not patching, is what actually closes this incident.
• Verify after patching by re-attesting that no unexplained technician account exists and that the rotated credentials are the only ones accepted anywhere they were valid.

Where Zero Hunt fits

This chain exposes two failures the conventional stack cannot close on its own: an exfiltration campaign that no host-based control sees while it runs, and a planted account that survives the patch that "fixed" the bug.

The primary answer is on the wire. Zero Hunt's AI Traffic Analysis runs a proprietary deep-learning model with four parallel inference heads — suspicious traffic, malware classification, attack-type identification, and application fingerprinting — locally on the appliance GPU at 2.7+ Gbit/s, with no cloud callback. It does not need an IOC for TaskWeaver to notice that a server which has only ever spoken RMM protocol just fetched an obfuscated script from a one-day-old domain, or that a managed endpoint is suddenly pushing a sustained outbound stream to a never-seen ASN. Djinn's whole purpose is exfiltration, and exfiltration is a traffic event — the staging and the egress are visible as they happen, not reconstructed from tomorrow's SIEM digest after the keys are already gone. This is the case the model was built for: catching the theft during the theft.

The secondary answer is the cleanup the patch dashboard cannot perform. Zero Hunt's 10-agent generative pentest treats the RMM the way an attacker does. The Recon agent maps the SimpleHelp instances actually exposed on your perimeter; the Exploit agent reconstructs the OIDC signature-skip locally for your environment rather than running a public PoC; and the Credential, Post-Exploit, and Pivot agents do the work a version scan structurally cannot — enumerate the planted technician account, find the loader still on disk, and prove which exfiltrated credentials still authenticate somewhere they shouldn't. Every new skill is backtested in the AI Gym before it touches a production target, and every finding is ECDSA-signed at write time, so the evidence bundle proves the server is not merely on 5.5.16 but clean — which is the question your incident response actually has to answer.

A thousand SimpleHelp servers will mostly be patched by next week. The number worth knowing is how many still carry a technician account nobody created on purpose — and how many cloud, Git, and AI keys are already in someone else's hands. For a related take on why a closed CVE is not a closed incident, see our analysis of the UniFi rogue-admin patch gap.