Jul 1, 2026BTA Team10 min read

SimpleHelp's OIDC Login Never Checked the Signature: CVE-2026-48558 Ships Djinn Stealer to Managed Dev Fleets

Every so often a CVSS 10 lands where we work and we can already see the incident notes writing themselves before the vendor advisory finishes loading. This week that was SimpleHelp. The bug is not a memory corruption chain or a sandbox escape. It is that SimpleHelp's OIDC login accepted identity tokens without checking whether they were signed by the identity provider it claimed to trust. If your fleet is managed by a SimpleHelp server sitting on the internet, an unauthenticated attacker could forge a token, walk in as a full Technician, self-register MFA to satisfy any policy that demanded it, and start pushing files and scripts to every endpoint underneath it.

That last part is the one we could not stop thinking about at BlueTeamAutomation, because RMM traffic is exactly the traffic your SOC has already agreed to trust. An adversary who owns the console is not sneaking around your network; they are sitting in the operator's chair.

How an Unsigned Token Becomes a Technician Session

OIDC outsources identity to a signed handoff. The identity provider signs an id_token JWT with a key the application fetches and pins; the application receives the token, verifies the signature against that pinned key, then trusts the claims inside (sub, email, groups, and so on) to decide who you are. Skip the signature check and the claims turn into an unauthenticated form. Anyone can print whatever email address, subject id, and group membership they want and hand you the receipt.

CVE-2026-48558 is that skipped step, in a shipping enterprise product. SimpleHelp's OIDC login flow parses the id_token, reads the claims, and applies its group mapping to decide whether the user is a Technician. It never validates the cryptographic signature over those claims, so a JWT with alg set to none, or one signed with any random key, is treated the same as a genuine token from the customer's real IdP.

Because the group mapping runs on claims the attacker gets to pick, the attacker also picks their own role. The advisory language and CISA's Known Exploited Vulnerabilities addition make the impact unusually blunt for a login bug: pre-auth, remote, and immediately privileged. Full Technician.

MFA Self-Registration Turns "Bypass" Into "Whole Session"

The other detail that makes this dangerous is what happens on first login. SimpleHelp lets a fresh Technician self-register their own MFA method on initial sign in, so the attacker's first successful forgery not only lands them in the console; it also lets them attach a TOTP or WebAuthn credential of their choosing to the account before anyone else does.

MFA that a user can enroll themselves is not a second factor against someone who has already forged the first. It is a lock the intruder installs behind them.

From Technician Console to jquery.js on a Dev Laptop

Blackpoint Cyber's Adversary Pursuit Group traced a live intrusion where the attacker forged the OIDC login, then used SimpleHelp's technician-standard file transfer and remote script features to push a payload down to managed endpoints.

The payload was TaskWeaver, a heavily obfuscated Node.js loader roughly 1.08 MB in size, staged from a short-lived Cloudflare-fronted domain and dropped as jquery.js. It was executed via node.exe on Windows and via the equivalent Node runtime on macOS and Linux. Once resident, TaskWeaver fingerprints the host, phones the C2, and pulls encrypted JavaScript modules on demand. The loader is deliberately generic, so the same primitive can move a stealer, a reverse shell, a ransomware module, or a lateral movement helper without the on-disk artifact changing shape.

The module Blackpoint recovered was Djinn Stealer. It sweeps every credential it can find, TARs and gzips them, encrypts the archive with an AES-256-GCM session key, wraps that key with an RSA-2048 public key embedded in TaskWeaver, and posts the bundle to a hard-coded exfiltration endpoint (96.126.130.126 in the observed intrusion, per BleepingComputer's reporting on the Blackpoint IOCs). Only whoever holds the private key can decrypt what leaves the box.

What Djinn Stealer Actually Sweeps

If you were writing a shopping list for what would hurt a modern engineering org the most, it would look a lot like Djinn Stealer's targets:

The part that made us stop and reread the writeup was the AI coding assistant coverage. Djinn Stealer specifically enumerates configuration, authentication, and session data for Anthropic Claude, Google Gemini, OpenAI Codex, and the open source assistants Cline, OpenCode, and Kilo, including their Model Context Protocol settings. The stealer walked in through your patch management channel and left with the credentials developers ship code with, plus the credentials their AI coding tools depend on.

Why Your Tooling Has Already Waved This Traffic Through

An RMM channel is, by construction, an allow-listed remote administration overlay. Your EDR knows the SimpleHelp agent runs signed helper processes, your firewall knows the appliance is allowed to reach those agents, and your SIEM has probably already learned that scripts and file drops from the operator's console are normal business.

That is the problem. TaskWeaver lands as jquery.js from the RMM console and is executed by node.exe, an ordinary binary on developer boxes, with a script path under the same directories your automation writes to every day. If your rule set only alerts on unexpected parent processes for cmd.exe or powershell.exe, this one will not flip a single toggle. And the OIDC login itself looks like a normal SSO flow, just with a slightly unfamiliar technician email in the audit log.

Mapping to MITRE ATT&CK, initial access rides T1190 (Exploit Public-Facing Application) against the SimpleHelp server and T1078 (Valid Accounts) once the forged Technician account exists. Execution runs through T1059.007 (JavaScript) and T1218 (Signed Binary Proxy Execution) via node.exe. Collection sweeps T1552 (Unsecured Credentials), T1555 (Credentials from Password Stores), and T1539 (Steal Web Session Cookie), while exfiltration rides T1567 (Exfiltration Over Web Service) wrapped in T1573.002 (Asymmetric Cryptography).

What to Hunt in Your SimpleHelp and EDR Logs

Two hunts pay for themselves in an afternoon.

On the SimpleHelp server, walk to Administration then Technicians, click the gear icon, and enable "Show Group Authenticated Users" to list every account created through the OIDC group mapping. Read that list slowly, because any name, email, or subject you do not recognize is a compromise until proven otherwise. Then export Server Logs, per Help Net Security's writeup of the vendor guidance, and grep for successful OIDC logins whose email addresses do not match a real employee.

On managed endpoints, hunt for node.exe or node executing a file named jquery.js from a temp directory or from the RMM staging path, with no adjacent web project on disk. Correlate against outbound TLS or HTTPS to 96.126.130.126 or to short-lived Cloudflare-fronted domains reached by node processes. Any developer laptop that emitted that flow should be treated as credentialed compromise, not endpoint compromise. Rotate every AWS, GCP, Azure, GitHub, npm, PyPI, and AI coding assistant token that machine had access to, and invalidate active browser and cloud sessions before the exfiltrated bundle is decrypted.

Patch, Rotate, and Verify the Patch Actually Held

Upgrade SimpleHelp to 5.5.16 or 6.0 RC2, which enforce proper JWT signature validation on the OIDC login path. If you cannot patch inside the CISA KEV window (federal deadline is July 2, and everyone else should treat it the same), disable OIDC authentication or restrict the management interface to a jump host and VPN. Delete any technician account you cannot tie to a real human. Reset MFA enrollments for every technician and require re-registration through a controlled channel, since the bug's whole trick is that the attacker owns the first enrollment moment.

Then verify the fix actually held. Attempt an OIDC login with a self-signed id_token against a lab copy of the upgraded server and confirm the login is rejected. Push a replay of the outbound TLS pattern to 96.126.130.126 through your egress controls to confirm it is blocked. Diff today's technician roster against yesterday's and reconcile any delta with a named human. A patched system is a hypothesis until you have watched the attack fail against it.

The BTA View

This is the loop we automate at BlueTeamAutomation. BASzy simulates the forged OIDC login and the TaskWeaver drop on a schedule, your EDR and SIEM correlate the detections, and response and evidence flow continuously rather than as a scramble after the next KEV entry.

Turn the next KEV entry into a rehearsal, not a fire drill.

BASzy runs continuous breach and attack simulation against your live stack, so the detections for bugs like CVE-2026-48558 are proven before the vendor advisory drops.

Explore BASzy →