A remote support tool exists to give one person total control over another person’s machine — that’s the entire point of RMM software. So when the authentication in front of that control plane turns out to accept a token nobody bothered to check the signature on, the blast radius isn’t “one server got popped.” It’s every endpoint that server manages, all at once, no credentials required. That’s CVE-2026-48558.

TL;DR

  • CVE-2026-48558 is a CVSS 10.0 authentication bypass in SimpleHelp RMM: the OIDC login flow accepts identity tokens without verifying their cryptographic signature, letting an unauthenticated attacker forge a token and walk away with a fully privileged Technician session.
  • Disclosed by Horizon3.ai on June 12, 2026; by June 29, 2026 Blackpoint MDR confirmed active exploitation in the wild, and CISA added it to the KEV catalog the same day with a three-day remediation window.
  • Exploitation delivers a two-stage chain: TaskWeaver, an obfuscated JavaScript loader disguised as jquery.js, followed by Djinn Stealer, a previously undocumented cross-platform infostealer targeting cloud, developer, and — notably — AI coding assistant credentials.
  • Horizon3.ai’s internet scan found roughly 14,000 SimpleHelp servers exposed online, of which about 7.2% (roughly 1,000) had the vulnerable OIDC configuration enabled — each one a potential single point of compromise for every endpoint it manages.
  • Vendor patches (5.5.16 and 6.0 RC2) have existed since before public disclosure — this is a case where patching moved faster than adoption, and the gap is exactly what’s being exploited.

Why This Matters to You

If your organization uses SimpleHelp — or if your managed service provider does, which you may not even know — this single vulnerability can turn one exposed server into a compromise of every machine that server was trusted to administer. RMM tools sit at a uniquely privileged layer: they’re designed to bypass normal user friction, push arbitrary scripts, and reach endpoints that live behind other organizations’ firewalls entirely. That’s exactly why they’re such an attractive target, and exactly why “we don’t run SimpleHelp ourselves” isn’t the same as “we’re not exposed” if a vendor in your supply chain does.

Table of Contents

What CVE-2026-48558 Actually Is

SimpleHelp supports logging into its administrative console via OpenID Connect (OIDC), the standard identity-federation protocol used by Azure AD, Okta, and many other identity providers. The idea is straightforward: an organization configures an OIDC provider, associates it with a Technician group, and lets technicians log in through their existing corporate identity rather than a separate SimpleHelp password.

The flaw, tracked as CVE-2026-48558 and assigned CWE-347 (Improper Verification of Cryptographic Signature), is that SimpleHelp accepted the identity token presented during that login flow without verifying its cryptographic signature. An OIDC identity token is only trustworthy because it’s signed by the identity provider — strip out the signature check, and the token becomes a self-attested claim the client can write however it likes. An attacker with no credentials and no relationship to the target organization can hand-craft a token claiming to be any user, in any group, and the server has no way to tell the difference.

Exploitation requires three conditions to be true on the target server, all of which are unfortunately common in real deployments:

  1. OIDC is enabled with at least one identity provider configured
  2. At least one Technician group is associated with that OIDC provider
  3. “Allow group authenticated logins” is enabled on that Technician group

Where all three hold, a forged token is enough to create a new Technician account and obtain a fully authenticated session — in some configurations, bypassing MFA entirely, since the compromise happens at the identity-assertion layer MFA is meant to protect. From there, the attacker has the same capabilities any legitimate technician has: remote access to every managed endpoint, script execution, and configuration changes.

CVSS scoring reflects how little stands between an attacker and total compromise: a CVSS 3.1 base score of 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) — network-exploitable, low complexity, no privileges or user interaction required, and complete impact on confidentiality, integrity, and availability, with the “scope changed” flag reflecting that compromising the server compromises every endpoint downstream of it. (Under the CVSS 4.0 rubric, several vendor trackers list it slightly lower at 9.5, reflecting methodology differences between the two standards rather than a disagreement on severity.)

Affected versions: SimpleHelp 5.5.15 and earlier, plus all 6.0 pre-release builds, wherever OIDC is configured as described above. Patched in: 5.5.16 and 6.0 RC2.

Timeline: Disclosure to Active Exploitation

The publicly reported sequence of events, cross-referenced across Horizon3.ai’s own advisory and downstream coverage:

  • May 21, 2026 — Horizon3.ai discovers and validates the vulnerability.
  • May 22, 2026 — Reported to SimpleHelp.
  • Late May–early June 2026 — SimpleHelp releases fixed builds (5.5.16 / 6.0 RC2) ahead of public disclosure; the exact patch date is reported inconsistently across sources, so treat “before June 12” as the reliable anchor rather than a specific day.
  • June 12, 2026 — Public disclosure of CVE-2026-48558.
  • June 29, 2026 — Blackpoint MDR confirms active exploitation in the wild; CISA adds the CVE to its Known Exploited Vulnerabilities (KEV) catalog the same day, with a remediation deadline of July 2, 2026 for U.S. federal civilian agencies under Binding Operational Directive 26-04 — a three-day window reflecting how urgently CISA rated the threat.

Seventeen days between a public advisory with a working technical writeup and confirmed in-the-wild exploitation is not a fast turnaround by the standards of 2026’s exploitation timelines — it’s practically leisurely. What made the difference here wasn’t speed; it was that patched builds had existed for weeks before disclosure, and a meaningful share of internet-facing servers simply hadn’t been updated by the time attackers started actively scanning for the vulnerable OIDC configuration.

How Attackers Are Using It

Once an attacker has a forged Technician session, the observed attack chain deploys two distinct pieces of malware in sequence, according to Horizon3.ai and Blackpoint’s joint reporting:

Stage 1 — TaskWeaver. An obfuscated JavaScript file disguised as a common library file (jquery.js), executed through node.exe rather than a browser. TaskWeaver fingerprints the compromised host, reports that data back to attacker infrastructure, and pulls down further JavaScript modules for execution based on what it finds — effectively letting the attacker tailor the second stage to whatever platform and privilege level it lands on. Command-and-control and payload delivery both route through temporary Cloudflare domains, a choice that blends malicious traffic into the enormous volume of legitimate Cloudflare-fronted traffic most networks already allow.

Stage 2 — Djinn Stealer. A previously undocumented, cross-platform credential and data stealer that runs on Windows, macOS, and Linux alike. This is the payload that does the actual theft, covered in detail below.

The use of a disguised, Node-executed loader as the first stage is a deliberate evasion choice — running through a legitimate runtime with a filename that mimics a common web library is intended to blend into both automated endpoint detection baselines and casual manual log review.

As of this writing, no public reporting ties this specific CVE or campaign to a named threat actor or to follow-on ransomware deployment — several sources covering the campaign explicitly note the absence of ransomware activity in observed intrusions. Treat that as accurate for the intrusions documented so far, not as a guarantee about how the access is being monetized elsewhere; credential-theft campaigns of this scale frequently feed into activity that surfaces only later, once stolen access changes hands.

Djinn Stealer: What It Steals

Djinn Stealer’s target list is notable less for its breadth — infostealers have targeted browsers and crypto wallets for years — than for how squarely it’s built around the modern developer and cloud-operations toolchain. Reported categories, consistent across Horizon3.ai, Help Net Security, and BleepingComputer’s coverage:

  • Cloud platform credentials — AWS, Azure, GCP, and reportedly Oracle Cloud, Okta, and Cloudflare tokens
  • Source control and infrastructure tooling — GitHub/GitLab credentials, SSH keys, Docker and Helm/Kubernetes configuration
  • Package registry credentials — across ecosystems including npm, pip, and cargo
  • AI development assistant credentials — tokens and configuration for tools including Claude, Gemini, OpenAI Codex, and Cline
  • Cryptocurrency wallets — including Bitcoin, Ethereum, and Monero
  • Browser data, shell history, PGP keys, and Linux process environment variables that commonly hold secrets in CI/CD and automation contexts

Exfiltration follows a consistent pipeline reported by multiple sources: collected data is packaged into a TAR archive, compressed with GZIP, then encrypted with AES-256-GCM using a session key itself protected by an embedded RSA-2048 public key, before being sent out over the same temporary Cloudflare-fronted infrastructure TaskWeaver used for delivery.

The emphasis on AI assistant credentials and package registry tokens is the detail worth sitting with. A stolen npm or PyPI publishing token, or a compromised AI coding assistant’s API key with access to a private repository, isn’t just a privacy loss for one developer — it’s a potential entry point into a supply chain affecting everyone downstream of whatever that credential can touch.

Scale: How Exposed Is This, Really

Horizon3.ai’s internet-wide scan is the most concrete public number available here, and it’s worth being precise about what it does and doesn’t show: it counts internet-exposed SimpleHelp servers and vulnerable configurations, not confirmed breaches.

  • Approximately 14,000 SimpleHelp servers were found exposed to the internet — up sharply from roughly 3,400 in a January 2025 scan of the same product, reflecting SimpleHelp’s growing footprint rather than a sudden exposure spike tied to this CVE specifically.
  • Of those, roughly 7.2% — on the order of 1,000 servers — had OIDC authentication configured in a way that satisfies the three preconditions for exploitation.

Those two figures (14,000 total, 7.2% vulnerable) come from the same source and are internally consistent with independent reporting citing “approximately 1,000” vulnerable servers directly, which is a reasonable cross-check even though it isn’t truly a second independent measurement. Treat the ~1,000 figure as a solid estimate of internet-facing exposure at scan time, not a count of confirmed compromises — no public source has published a specific number of organizations known to have been breached through this vector. Given that each compromised SimpleHelp instance can cascade into every endpoint it manages, even a four-digit server count represents a considerably larger number of at-risk endpoints — plausibly the entire client base of any affected MSP.

Detection: What to Look For

Because exploitation happens at the authentication layer rather than through a memory-corruption exploit, the clearest detection signals live in SimpleHelp’s own logs and administrative console rather than in network IDS signatures:

  • Unfamiliar Technician accounts. Check Administration → Technicians → Group Authenticated Users for names or email addresses your organization doesn’t recognize, especially ones that appeared without a corresponding onboarding action.
  • Log entries for unexpected technician registrations. SimpleHelp server logs (server.log, located under /opt/SimpleHelp/logs/ and per-session subdirectories in typical installs) record lines like Registering technician login for [email] — audit these against your actual technician roster.
  • Unexpected configuration saves. Entries showing configuration changes attributed to unrecognized technician identities are a strong indicator of a forged session actively being used, not just created.
  • Outbound connections to short-lived Cloudflare-fronted domains from managed endpoints, particularly node.exe processes making outbound HTTPS connections shortly after any SimpleHelp technician session — TaskWeaver’s C2 pattern.
  • Files named jquery.js executed via Node.js rather than served to a browser. A legitimate jQuery file has no business being executed as a standalone Node script; this mismatch is close to a direct IOC when observed on an endpoint SimpleHelp manages.

MITRE ATT&CK Mapping

TacticTechniqueID
Initial AccessExploit Public-Facing ApplicationT1190
Initial AccessValid AccountsT1078
ExecutionCommand and Scripting Interpreter: JavaScriptT1059.007
Command and ControlApplication Layer Protocol: Web ProtocolsT1071.001
Command and ControlProxy: Domain FrontingT1090.004
Credential AccessUnsecured CredentialsT1552
StealthMasqueradingT1036
CollectionArchive Collected DataT1560
ExfiltrationExfiltration Over C2 ChannelT1041

What You Can Do Today

  1. Patch immediately. Upgrade to SimpleHelp 5.5.16 or 6.0 RC2. If you can’t upgrade right now, disabling OIDC authentication entirely removes the precondition for exploitation as an interim mitigation.
  2. Audit your Technician roster now, patched or not. Compromise may have already occurred before you upgrade — a patch stops new forgeries, it doesn’t undo an account an attacker already created.
  3. Check whether any vendor or MSP in your supply chain runs SimpleHelp. If they do, ask directly whether they use OIDC authentication and whether they’ve patched — you inherit their exposure regardless of what you run internally.
  4. Rotate credentials that Djinn Stealer specifically targets on any endpoint that was managed by a potentially compromised SimpleHelp instance: cloud provider keys, Git/SSH credentials, package registry tokens, and AI assistant API keys, not just the obvious browser-saved passwords.
  5. Hunt for TaskWeaver’s specific fingerprint — jquery.js executed via node.exe, and outbound connections to short-lived Cloudflare-fronted domains — across endpoints reachable by any SimpleHelp server, not just the server itself.
  6. Don’t treat internet-facing RMM as “someone else’s problem.” Whether it’s your own SimpleHelp deployment or a vendor’s, remote support software sitting on the open internet with a weak identity check is exactly the kind of single point of failure that turns a config oversight into a fleet-wide breach.
  7. Add SimpleHelp (and RMM tools generally) to your CISA KEV monitoring rotation. A three-day federal remediation window is a strong signal about how attackers are prioritizing this class of vulnerability even outside government networks.

Sources