A Forged Token, a Trusted Technician, an Entire Fleet: CVE-2026-48558

SimpleHelp never checked the signature on its OIDC login tokens. CISA added the flaw to KEV yesterday, and the attackers using it are already shipping new malware families through it. Here is how the bypass works, why it lands hardest on managed service providers and the infrastructure they support, and what to do this week.

What the vulnerability is

SimpleHelp is a remote monitoring and management product. IT teams, and especially managed service providers, install a SimpleHelp server, attach their fleet of managed endpoints to it, and use it to remote in, push scripts, transfer files, and run privileged operations on those endpoints from one console. When the server is configured to use OpenID Connect for sign on, the workflow looks normal: the user is redirected to their identity provider, the identity provider issues a signed JSON Web Token, and the server is supposed to verify that signature before trusting the claims inside.

That signature check is the one step SimpleHelp skipped. The vulnerable versions, every release up to and including 5.5.15 and all 6.0 release candidates, accept any well formed OIDC identity token at face value. An attacker can craft a token, write whatever they want in the claims, including the group membership that maps to a Technician role, and submit it to the login endpoint. The server returns a real technician session, and from there the attacker can do everything a legitimate technician can do: remote into managed endpoints, execute scripts, transfer files, create more privileged accounts, and persist on the fleet.

Three preconditions have to be true for the bypass to work, and on real SimpleHelp deployments they often are: OpenID Connect is enabled, a TechnicianGroup is associated with an OIDC provider, and "Allow group authenticated logins" is turned on for that TechnicianGroup. Horizon3 reports that around 7.2 percent of the 14,000 public servers they enumerated meet those conditions. That is roughly a thousand internet-facing servers in the vulnerable state, and each of them is a hub to many downstream endpoints.

How the real attack unfolds

Blackpoint Security observed a clean campaign tied to this bug. Attackers identify an OIDC-enabled SimpleHelp server, forge a token that grants Technician access, and then move through the fleet the server controls. The follow-on payload is novel. The attackers stage a Node.js loader the researchers are calling TaskWeaver, which fingerprints the system and pulls down a JavaScript task graph. One of those tasks deploys Djinn Stealer, a previously undocumented cross-platform info stealer that hunts for browser data, SSH key material, cloud and developer tokens, AI tool credentials, and other secrets that let the attacker pivot well beyond the initial SimpleHelp foothold.

The server that lets one operator manage thousands of endpoints is also the server that, in a forged-token scenario, lets one attacker do the same.

This is the second time in eighteen months that SimpleHelp has shown up in a campaign against high value targets. The 2025 CISA advisory AA25-163A described ransomware actors using unpatched SimpleHelp instances (CVE-2024-57726, -57727, -57728) to reach into a utility billing software provider and detonate DragonForce ransomware on downstream customers. The 2026 bug is different and worse: no credentials needed, no path traversal, just a missing signature check on the front door.

Why this hits OT and critical infrastructure

SimpleHelp itself is general-purpose IT software, not industrial gear. The reason it matters for OT and critical infrastructure is that managed service providers, including the ones that service water and wastewater utilities, manufacturing sites, energy operators, and rural healthcare networks, use RMM platforms exactly like this one to reach into their customers' environments. That puts the SimpleHelp server in the same threat model as a domain controller or jump host: compromise it once, and the blast radius is everything it manages.

The 2025 precedent is the clearest illustration. The Royal Mail / billing-provider style of attack chain works the same way here: take the RMM, ride its trusted channel into customer estates, and detonate the payload of choice. With Djinn Stealer that payload is credential harvesting, which is the precursor to whatever the operator wants to do next: ransomware, data theft, or quiet long term access to operational systems.

What we see from our sensors

We run a fleet of honeypots and edge decoys, so we went looking for this activity in our own data. We want to be precise about what we found, and what we did not.

We did not see CVE-2026-48558 itself in our captures. Our decoys are generic SSH, Telnet, SMB, HTTP, and a curated set of industrial protocol and edge-appliance emulations. None of them currently impersonate a SimpleHelp server with OIDC enabled, so an attacker hunting that exact surface would not find it on our sensors.

What we do see, every day, is the perimeter pressure that this campaign assumes. RMM consoles, web admin panels on non-standard ports (8443, 9090, 443 with self-signed certs), JWT-bearing requests to login endpoints, and probes for "/auth/oidc", "/callback", and similar SSO entry points are all visible on our HTTP decoys as part of the normal background internet noise. The Shodan-confirmed exposure of about 14,000 SimpleHelp servers is consistent with how easily that probing finds real targets.

What to do this week

• Patch the server, then validate it. Upgrade to 5.5.16 or 6.0 RC2 and confirm the running build. If OIDC was enabled, also rotate the OIDC client secret and review every Technician and group account that exists.
• Get the SimpleHelp console off the public internet. If your administrators do not need direct access from the open internet, do not give it to them. Put the server behind a VPN or bastion, restrict source IPs, and require step-up authentication for technician roles.
• Hunt for rogue technician accounts. Review the user list and the audit log for newly created technicians, especially ones tied to your OIDC provider, ones with no real human owner, or ones created outside business hours. Horizon3 has published indicators tied to TaskWeaver and Djinn Stealer; cross check endpoint telemetry against them.
• Assume managed endpoints may have been touched. If your server was vulnerable and exposed, treat every endpoint it manages as in scope for hunt, not just the server itself. Look for unexpected Node.js processes, scheduled tasks calling out to unknown domains, browser-profile and SSH-key access patterns, and exfiltration of developer or cloud credentials.
• If you are an MSP serving OT or CI customers, brief them. The customer impact of a compromised RMM lands on their estate, not yours. They should know what you patched, when, and what evidence you have that their endpoints were not touched.

Indicators and references