SimpleHelp OIDC Bypass Gets Weaponized: TaskWeaver and Djinn Stealer Land on Unpatched Servers
An unauthenticated auth bypass scoring a perfect 10.0 is dropping two new malware families on remote-support boxes that nobody remembered were internet-facing.
Another SimpleHelp bug, another remote-support server doing the attacker's job for them.
An unidentified threat actor is actively exploiting CVE-2026-48558, a CVSS 10.0 authentication bypass in SimpleHelp's OpenID Connect flow. The payload of choice is a pair of previously undocumented families the responders are calling TaskWeaver and Djinn Stealer. Neither has been seen in the wild before this campaign.
The failure mode here is the usual one. SimpleHelp instances tend to live on the public internet because that is the entire point of remote support tooling. They get stood up by IT, not security. They rarely sit behind the same egress controls as the rest of the estate, and patch cadence is measured in quarters, not days. When the OIDC handler accepts unauthenticated requests as valid sessions, an attacker does not need credentials, social engineering, or a phishing lure. They need a TCP connection.
In practice, that is what we are seeing. Initial access via the bypass, then TaskWeaver as the foothold and Djinn Stealer for credential harvesting. Stealers landing on a remote-support server are particularly nasty because those boxes already hold session tokens, technician credentials, and persistent connections into customer endpoints. One compromised SimpleHelp host is a directory of downstream targets.
This is not the first time SimpleHelp has been the doorway. Earlier CVEs in the same product were folded into ransomware playbooks within weeks of disclosure, and at least one of those campaigns went after MSPs specifically. The pattern repeats because the install base is sticky and the upgrade path requires a maintenance window most shops will not schedule.
A few things worth doing today rather than next sprint:
- Inventory every SimpleHelp server, including the one the helpdesk lead stood up in 2022 and forgot about. Shodan will find it before you do.
- Patch to the fixed build per the vendor advisory, then rotate technician credentials and any OIDC client secrets the server touched.
- Pull access logs for anomalous OIDC callbacks and unexpected technician sessions. The bypass leaves traces if you know where to look.
- Put the management plane behind a VPN or identity-aware proxy. There is no reason a remote-support admin console should answer to the open internet.
One thing the post-mortem will say: the vulnerable host was known to IT, unknown to security, and last touched eighteen months ago.
Operational takeaway — treat remote-support tooling as Tier 0. It already has Tier 0 access.
