An attacker with no credentials, no MFA challenge and no relationship whatsoever with your organisation can obtain a fully authenticated technician session on a vulnerable SimpleHelp server. All it takes is a hand-crafted identity token, because the server never checks the signature. That is CVE-2026-48558 in one sentence: a CVSS 10.0 authentication bypass in the SimpleHelp remote support platform, added to CISA's Known Exploited Vulnerabilities catalogue on 29 June 2026 with a remediation deadline of 2 July for US federal agencies — three days.
The urgency is well founded. This is not an academic proof of concept: exploitation is under way, and attackers are using the access to deploy two previously undocumented malware families, TaskWeaver and Djinn Stealer, built to harvest cloud credentials, SSH and Git keys, and configuration files for AI coding assistants. When the compromised tool is the one helpdesks and managed service providers use to administer entire estates, the problem stops being one server's and becomes the whole supply chain's.
What SimpleHelp is, and why this flaw carries so much weight
SimpleHelp is a remote monitoring and management (RMM) platform widely used by IT support teams and managed service providers. A technician session on the server grants remote control over every endpoint registered under it — employee laptops, servers, kiosk machines. That is why an authentication flaw in this product earns the maximum severity score: it does not compromise one machine, it compromises the master key to many.
Nor is this the product's first appearance in bad news. In 2025, an earlier SimpleHelp vulnerability (CVE-2024-57727) also entered the KEV catalogue after being used in ransomware campaigns that reached end customers through their managed service providers. The pattern repeats: compromising the remote administration tool is the shortest route into hundreds of organisations at once, which is why third-party risk management has to ask explicitly which RMM tooling each provider with access to your systems relies on.
Anatomy of the flaw: a token nobody verifies
OIDC (OpenID Connect) authentication delegates identity verification to an external provider: the user authenticates against their identity provider — Microsoft Entra ID, for instance — which issues a signed token, and the application verifies that signature before granting access. The signature is precisely what guarantees the token was issued by who it claims.
According to the technical analysis by Horizon3.ai, SimpleHelp servers configured with generic OIDC or Azure AD OIDC accepted identity tokens without verifying the signature. The consequence is immediate: anyone who knows the expected token structure can build one claiming to be a legitimate technician, and the server believes it. MFA is not broken — it simply never comes into play, because the attacker never touches the identity provider at all.
The conditions that make it possible
The flaw affects versions 5.5.15 and earlier, plus all 6.0 pre-release builds; it is fixed in SimpleHelp 5.5.16 and 6.0 RC2. To be exploitable, the server must have OIDC authentication configured and be reachable by the attacker — a common situation, since these consoles are routinely published to the internet so technicians can work from anywhere.
The trail it leaves
This is the defender's leverage. A forged sign-in produces an authentication event in SimpleHelp with no counterpart in the identity provider's logs: the token was never actually issued. That asymmetry between application logs and identity provider logs is the most reliable indicator of compromise, alongside technician sign-ins from IP addresses outside the support team's usual ranges.
The campaign: TaskWeaver and Djinn Stealer
A so-far unattributed actor is exploiting the flaw to deploy a two-stage chain, as documented by BleepingComputer and The Hacker News building on Blackpoint Cyber's research.
The first stage, TaskWeaver, is a heavily obfuscated Node.js loader, distributed disguised as jquery.js and executed through node.exe. Rather than shipping a fixed set of commands, it implements an encrypted, reusable payload delivery channel — infrastructure, not a one-off attack.
The second stage, Djinn Stealer, runs on Windows, macOS and Linux and goes after what is most valuable in a technical environment: browser data, SSH material, Git keys, Docker credentials, cloud provider tokens and configuration files for AI coding assistants. The aim is plain — turning the initial foothold into persistent access to the victim's development and cloud estate. It is the same reason non-human identity security — tokens, API keys, service accounts — has become a priority front.
The verifiable numbers
What public sources establish, at the time of writing:
- CVSS 10.0, the maximum severity score, for granting privileged access without authentication (The Hacker News).
- Affected versions: 5.5.15 and earlier, plus 6.0 pre-releases. Fixed in 5.5.16 and 6.0 RC2 (Help Net Security).
- Post-disclosure exposure counts put roughly 14,000 SimpleHelp servers reachable from the internet, with around 1,000 estimated to remain on vulnerable versions (SOCRadar).
- Added to CISA's KEV catalogue on 29 June 2026, with a 2 July remediation deadline for US federal civilian agencies (CISA).
- Two new malware families tied to the exploitation: TaskWeaver and Djinn Stealer (SecurityWeek).
Why the usual controls do not stop it
This case dismantles several comfortable assumptions. First: “we have MFA, we are covered.” MFA protects the legitimate authentication path; here the attacker takes a parallel path the application accepts unverified. No conditional access policy at the identity provider sees anything, because nothing passes through it.
Second: “the EDR would catch it.” RMM traffic is, by definition, legitimate remote administration: signed processes, expected connections, technician behaviour. An attacker holding a technician session operates entirely within the product's normal envelope. And node.exe, the process that runs the loader, is unremarkable on many development and support machines.
Third: “the perimeter will warn us.” The console is published to the internet on purpose, the access arrives TLS-encrypted on the expected port, and an initial intrusion generates minimal volume. What remains is watching your exposed attack surface and the inconsistencies between log sources — which is exactly where this attack does leave a mark.
Operational detection
Working from the indicators published by Horizon3.ai and Blackpoint Cyber, there are at least four concrete checks a SOC can run today:
- Cross-reference SimpleHelp authentication events against the identity provider's sign-in logs: any OIDC session in the application with no matching event at the provider is a strong indicator of a forged token.
- Review technician sign-ins from IP addresses outside the support team's usual ranges, and technician accounts or role changes created outside change windows.
- Hunt for node.exe executing jquery.js across managed endpoints. In Microsoft Defender, a starting point:
DeviceProcessEvents | where FileName =~ "node.exe" and ProcessCommandLine has "jquery.js" | project Timestamp, DeviceName, InitiatingProcessFileName, ProcessCommandLine - Watch for anomalous outbound connections from the SimpleHelp server itself, which in normal operation should show a highly predictable traffic pattern.
If the server sat exposed and unpatched during the exploitation window, the right posture is not “let's see if anything looks odd” but assume compromise until proven otherwise: a targeted threat hunting sweep, and if anything surfaces, a full incident response engagement with rotation of every credential and token reachable from the managed endpoints.
Practical defence
- Upgrade immediately to SimpleHelp 5.5.16 or 6.0 RC2. If upgrading today is not feasible, temporarily disabling OIDC authentication removes the condition that makes the flaw exploitable.
- Restrict access to the administration console: VPN or allow-listed addresses rather than open publication to the internet.
- Rotate credentials, cloud tokens and deployment keys reachable from managed endpoints, given Djinn Stealer's focus on exactly that material.
- Formally ask every provider with remote access to your systems which RMM tool they use, on what version, and what their KEV patching commitments are. That is a third-party risk question, not a courtesy.
- Make the KEV catalogue a first-class prioritisation signal in your vulnerability management: a three-day deadline for US federal agencies is an urgency signal for European private organisations too.
- Monitor remote administration consoles as critical assets, with their logs feeding the SOC and specific alerting on technician account creation.
Compliance implications: NIS2 and DORA
Article 21 of NIS2 requires supply chain security measures, including the relationship with service providers. A provider administering your systems through a vulnerable RMM platform is precisely the scenario the directive aims at: their compromised server is your incident. For entities in scope, documenting which remote access tools providers use, on which versions and under which patching commitments belongs to NIS2 compliance work, not to good intentions.
In the financial sector, DORA adds the ICT third-party register and concentration risk analysis: if several of your providers rely on the same remote administration platform, a single vulnerability like this one hits several links of your chain at once. That common-dependency analysis is rarely done — and cases like this show it is anything but theoretical.
At a glance
Remote administration tools concentrate privilege: that is their purpose and their risk. CVE-2026-48558 is not sophisticated — it is a signature verification failure — but its effect is the kind that defines a quarter: technician sessions for anyone who asks, malware built to steal the keys to your cloud and your code, and a three-day patching deadline set by CISA. Treating RMM platforms as top-criticality assets — inventoried, patched on KEV priority, with logs cross-checked against the identity provider and a response plan ready — is the difference between reading this story and starring in it.