SURIQ
A maximum-severity flaw in SimpleHelp, the remote-support software that thousands of IT teams and managed service providers use to reach customer machines, is now being used in real attacks. The flaw, CVE-2026-48558, lets an unauthenticated attacker forge a login and walk in as a fully privileged technician without any password. CISA added it to its Known Exploited Vulnerabilities catalog on June 29, 2026, the same day researchers at Blackpoint Cyber published evidence of it being exploited to plant a brand-new credential stealer. If you run SimpleHelp, the patch is not optional and the clock already ran out.
A max-severity flaw that needs no password
The bug carries a CVSS score of 10.0, the highest the scale goes, and it is as bad as that number suggests. There is no precondition beyond network access to the login page, no authentication, and no user interaction. A remote attacker who can reach a vulnerable SimpleHelp server can obtain a technician session that holds the keys to file transfer and remote command execution on every machine that server manages. In some configurations the same trick also sidesteps multi-factor authentication, so a second factor does not save you.
What SimpleHelp got wrong about single sign-on
SimpleHelp can hand login off to an outside identity provider using OpenID Connect (OIDC), the single sign-on standard behind buttons like "Log in with Google." In that flow the identity provider returns a signed token vouching for who you are, and the application is supposed to verify the cryptographic signature on that token before trusting it. Vulnerable SimpleHelp builds skipped that check. The classification is CWE-347, improper verification of a cryptographic signature, which in plain terms means the server accepted a stamped document without confirming the stamp was real. An attacker can therefore mint a token that claims to be any technician, including an administrator, and the server waves it through.
This is the kind of mistake that should never reach production, and it is exactly why a single sign-on path needs the same scrutiny as a password field. A login you delegate to a third party is still a login; trusting an unsigned assertion is the same as having no password at all.
Nearly 14,000 servers exposed, and the patch came first
The vulnerability affects SimpleHelp versions 5.5.15 and earlier, plus the 6.0 pre-release builds. It is fixed in 5.5.16 and 6.0 RC2, which the vendor shipped in late May, before the CVE was even public. That timing is the part defenders should sit with. By the time CVE-2026-48558 was published on June 12 with its perfect 10.0 score, the fix had been available for weeks, and the only thing standing between a patched server and an owned one was whether anyone applied it.
The exposure is not theoretical. Horizon3.ai counted nearly 14,000 internet-facing SimpleHelp servers as of June 12, and reported that roughly 7.2 percent of them were configured to use the vulnerable OIDC login method. That smaller slice is the soft target, and it is not a random one: the shops that bother wiring SimpleHelp into a central identity provider tend to be the larger and better-resourced ones, which makes the exposed subset more valuable, not less.
After the break-in: a stealer built for developers' keys
Getting in is only the setup. Blackpoint Cyber's research team traced an intrusion where an attacker used the forged technician session on an internet-facing SimpleHelp server to run a heavily obfuscated loader they named TaskWeaver, written in Node.js and built to execute arbitrary code while hiding its imports from static scanners. TaskWeaver then delivered Djinn Stealer, a previously undocumented information stealer that runs on Windows, macOS, and Linux.
Djinn's target list reads like an inventory of a modern engineer's keychain, and that is what makes it notable. It does not just scrape browser passwords. It hunts cloud provider credentials across AWS, Azure, Google Cloud, Oracle Cloud, Okta, and Cloudflare; source-control and infrastructure secrets from Git config, the GitHub CLI, SSH keys, Docker, and HashiCorp Vault; authentication tokens for package registries including npm, PyPI, and Cargo; and, tellingly, the configuration and tokens for AI coding assistants such as Claude, Gemini, and Codex, including their MCP (Model Context Protocol) configuration files. It rounds the haul out with cryptocurrency wallets. The data is packed into a compressed archive, encrypted, and shipped out to attacker infrastructure.
The shift here is the story. Infostealers spent years optimizing for saved browser logins and session cookies. Djinn is optimized for the credentials that grant standing access to your build pipeline, your cloud tenancy, and now your AI tooling. Those secrets are long-lived, they rarely sit behind multi-factor prompts, and one of them can be worth more than a thousand reused passwords. We have written before about how attackers are going after AI and developer API keys and how a single stealer can drain a developer's environment; Djinn is that thesis with a wider net.
Why this is worse for managed service providers
SimpleHelp is popular with managed service providers, and that changes the blast radius. For an MSP, one SimpleHelp server is not one box. It is a remote-control channel into every client whose endpoints that server manages. An attacker who forges a technician session inherits that reach, which maps cleanly to the trusted-relationship technique (MITRE ATT&CK T1199): compromise the provider once, and use the provider's own legitimate tooling to push into many downstream networks. The intrusion chain Blackpoint documented also leans on alternate authentication material (T1550.004) and renamed system binaries (T1036.004) to blend in.
This is the same painful pattern we keep seeing with edge and remote-management software, where ransomware crews thrive on patch latency rather than zero-days, and where remote-management tools become the backdoor. The product that lets you manage everything is, by design, the product that lets an intruder manage everything too.
Patch now, then assume the door was already open
The first action is mechanical and urgent: update SimpleHelp to 5.5.16 or 6.0 RC2. If you cannot patch within the hour, take the server off the public internet until you can, since the only attack precondition is reachability.
Patching closes the door, but it does not evict anyone who already walked through. A KEV listing means you should treat any server that was internet-exposed and unpatched as potentially compromised, and hunt accordingly. Horizon3.ai recommends reviewing your SimpleHelp technician list for accounts you do not recognize and checking the server logs (/opt/SimpleHelp/logs/server.log) for unexpected technician login registrations, which is the cleanest on-box signal that a forged session was accepted.
For broader detection, the highest-value rule is behavioral: alert when remote-management software spawns a scripting runtime such as Node.js, PowerShell, or Python from a temporary or download directory, because a legitimate support tool launching node.exe against a one-line script is not normal. Block outbound connections to ephemeral tunneling domains like trycloudflare.com and the loader's command channel at a.dev-tunnels.com, and watch for the stealer's exfiltration to 96.126.130.126. A managed detection and response setup, with alerts mapped to MITRE ATT&CK, is built to catch exactly this kind of post-access behavior even when the initial login looked legitimate. The login was forged; the activity that follows it is not invisible.
Rotate what could have leaked. If a server was exposed, assume the cloud, source-control, registry, and AI-assistant tokens reachable from the machines it manages are burned, and cycle them. Stealers monetize speed, and a credential you rotate today is worth nothing to a buyer tomorrow.