Access unattributed; post-exploitation with TaskWeaver loader and Djinn stealer (Blackpoint Cyber)critical
A token nobody signed: SimpleHelp accepted forged logins and opened every managed endpoint
SimpleHelp is remote-support software: whoever controls it controls the computers it manages. CVE-2026-48558 (CVSS 10.0) is an authentication bypass in the OIDC flow: when single sign-on is configured, identity tokens were accepted without verifying their cryptographic signature. A remote, unauthenticated attacker could therefore submit a forged token with arbitrary claims and obtain a full technician session — in some configurations bypassing MFA too. The flaw was exploited in the wild to deliver the TaskWeaver loader and the Djinn stealer, and was added to the CISA KEV catalog on 29 June.
The tool that holds the keys to other people's homes
SimpleHelp is remote-support software: it is installed by whoever needs to enter, with consent, the computers of clients or employees to help them. It is exactly the kind of product where the trust level is total — an authenticated technician session can see the screen, move the mouse, transfer files, run commands on managed endpoints. For Managed Service Providers it is the console from which dozens or hundreds of client companies are administered. Compromising it is not breaching a website: it is obtaining a master key to everything that server manages.
On 29 June 2026 CISA added CVE-2026-48558 to the catalog of known-exploited vulnerabilities. It is an authentication bypass rated CVSS 10.0 (3.1 scale) in the OIDC single sign-on flow. It is the kind of flaw that hurts precisely because it is simple to explain.
The signature that wasn't checked
When SimpleHelp is configured for OIDC authentication, during login it receives an identity token: an object signed by the identity provider that says "this user is who they claim to be." The whole point of that signature is that it is the cryptographic proof the token really comes from the provider and was not fabricated. In vulnerable versions — SimpleHelp up to 5.5.15 and the 6.0 pre-releases — that token was accepted without verifying its signature.
The result is mechanical. A remote attacker, with no credentials, could build a token with arbitrary identity claims — write "I am an authorized technician" — and present it. With the signature unchecked, the server took it at face value and opened a fully authenticated technician session. In some configurations, the flaw description warns, this also allowed bypassing multi-factor authentication: if the gate is the token and the token is forgeable, the second factor is never invoked.
- 01Forged OIDC tokenarbitrary claims: "authorized technician", no real credentials
- 02Signature not verifiedthe server does not check the token comes from the provider
- 03Full technician sessionauthenticated access, in some cases MFA bypassed
- 04Managed endpointsfrom a forged login to control of the administered computers
What happened after entry
The flaw did not stay theoretical. According to the reconstruction by Horizon3.ai — which discovered and disclosed the vulnerability — and the analysis reported by Blackpoint Cyber, attackers used the forged login to deploy a Node.js loader called TaskWeaver and a new infostealer, Djinn, aimed at harvesting credentials across cloud, development, AI and wallet tools. The sequence is the classic one for a high-value initial access: not an isolated hit, but the first step of a chain that aims to steal more access and spread.
What is verified and what is not
Some distinctions in fairness. The technical description of the flaw and the affected versions come from the NVD record and the vendor security advisory, which shipped the fix (5.5.16 and 6.0 RC2) back in late May 2026. Active exploitation is confirmed by the KEV entry. The link to TaskWeaver and Djinn comes from Horizon3.ai and Blackpoint Cyber research carried by several outlets: it is solid threat-intelligence research, not an agency advisory, and attribution to a named actor is absent. The KEV catalog lists ransomware use as unknown. The ATT&CK IDs at the top — T1190, T1606, T1219 — are a reasoned mapping of what the chain enables (hit an exposed service, present forged web credentials, abuse remote-access software), not IDs copied from a primary source.
What to do, now
The priority is to update to 5.5.16 or 6.0 RC2 (or later). But for a product that was exposed and exploitable with no credentials, the patch alone is not enough: anyone who was vulnerable should assume possible access and check the indicators published by Horizon3.ai — looking for anomalous technician sessions and OIDC logins in the logs, and activity on managed endpoints that does not match real interventions. Where there is evidence of compromise, cleaning an RMM is broader than the patch: rotate credentials, invalidate sessions, check managed endpoints for the loader and the stealer. The lesson of this CVE is the one that keeps returning on remote-access products: a tool built to enter anywhere, if it gets who is entering wrong, does not give away a single host — it gives away the list of everyone it manages.
