SimpleHelp CVE-2026-48558 — TaskWeaver Loader & Djinn Stealer

CVE-2026-48558 is a critical (CVSS 10.0) authentication bypass in the OpenID Connect (OIDC) login flow of SimpleHelp remote-support / RMM servers. When OIDC is configured, the server does not verify the cryptographic signature of identity tokens, so an unauthenticated attacker can submit a forged token and be issued a fully authenticated Technician session. A Technician can remote into managed endpoints, transfer files, and execute scripts — turning a single internet-exposed RMM server into a fan-out point across every device it manages.

Horizon3.ai disclosed the flaw on June 12, 2026; by late June it was under active exploitation and added to the CISA KEV catalog (BOD 26-04 remediation due July 7, 2026). In intrusions reported by Blackpoint, attackers used the technician session to drop TaskWeaver — a heavily obfuscated Node.js loader delivered as a ~1.08 MB single-line jquery.js run through node.exe — which fingerprints the host and stages Djinn Stealer, a cross-platform (Windows/macOS/Linux) info-stealer that harvests cloud keys, SSH keys, source-control sessions, AI-tooling configs, and crypto wallets. Nearly 14,000 SimpleHelp servers are internet-exposed and ~7% run the vulnerable OIDC configuration.

Highest-value defensive angle: the RMM server process tree is the choke point. SimpleHelp's service spawning node.exe, interactive shells, or download utilities — and node.exe executing a bloated jquery.js — is high-fidelity and rare in benign operations. The stolen-credential blast radius (cloud/SSH/SCM) means containment must include credential rotation, not just server patching.

Defender priority: Hunt for the SimpleHelp service (Remote Access.exe / RemoteWorker.exe) spawning node.exe or shells (Q1, Q5), and treat any hit as a credential-theft incident — rotate cloud keys, SSH keys, and SCM tokens for every account that touched affected hosts.

Intel note: No atomic file hashes, C2 IPs, or stealer domains were published in primary sources as of the access date. Endpoint coverage here is therefore behavior-led; atomic-IOC slots in §10 are placeholders to be filled when vendor IOCs publish.

Hunt hypotheses (fidelity-ordered)

1. H1 (high): A SimpleHelp server-side process spawns node.exe on a managed host — TaskWeaver loader execution through the RMM channel.
2. H2 (high): node.exe executes a script named jquery.js (or a similarly mis-named bulky JS) — direct TaskWeaver signature.
3. H3 (high): The SimpleHelp service spawns interactive shells / LOLBins (powershell.exe, cmd.exe, curl.exe, certutil.exe) — hands-on-keyboard via forged technician.
4. H4 (medium): node.exe makes outbound connections / DNS to ephemeral Cloudflare-style hosting (loader pull or stealer exfil).
5. H5 (medium): A process enumerates credential stores (.aws, .ssh, gh CLI, Docker, kube, wallets) — Djinn Stealer harvest.
6. H6 (server-side): SimpleHelp server.log shows an unexpected technician registration / forged config-save — primary server-side IOC (native hunt §7).

Attack chain

No atomic hashes / IPs were published in primary sources at access time (2026-06-30). The two SHA256/Domain rows are explicit placeholders — do not deploy them as-is.

SimpleHelp server (most important — server-side)

• Search server.log (and rotated logs/<YYYYMMDD-HHMMSS>/server.log) for Registering technician login for and Configuration save requested (Forged Attacker. Any unrecognized technician = compromise.
• In the SimpleHelp admin console: Administration → Technicians → Gear → Show Group Authenticated Users and review for unexpected/anonymous accounts.
• Confirm whether OIDC is enabled with a TechnicianGroup and "Allow group authenticated logins" — that trio is the exploit precondition.

Identity / cloud (post-theft reuse)

• AWS CloudTrail / Azure sign-in / GCP audit: look for access-key or session reuse from new ASNs shortly after any affected host's activity.
• GitHub audit log: new PATs, SSH keys, or OAuth grants on accounts whose workstations are SimpleHelp-managed.

Promote Q2 (Node-Runs-jQuery) first — lowest FP, highest specificity. Deploy others as Detect until baselined against legitimate technician activity, then raise to Block.

One-click blocks for ingestion and audit. Atomic IOCs (hash/C2) are placeholders until vendors publish — the behavioral and audit blocks are deployable today.

type,value,action,severity,expiration,description,tags
sha256,REPLACE_WITH_TASKWEAVER_SHA256,prevent,critical,2026-12-30,TaskWeaver loader,campaign:SimpleHelp-CVE-2026-48558
domain,REPLACE_WITH_C2,detect,high,2026-09-30,Djinn staging/C2,campaign:SimpleHelp-CVE-2026-48558

SimpleHelp service (Remote Access.exe / RemoteWorker.exe) -> node.exe
node.exe -> jquery.js  (bloated ~1MB single-line JS)
SimpleHelp service -> powershell/cmd/curl/certutil/mshta
node.exe -> outbound to trycloudflare.com / *.workers.dev / *.pages.dev

TaskWeaver  - Node.js loader, delivered as jquery.js, host fingerprint + stage
Djinn Stealer - cross-platform (Win/macOS/Linux); steals AWS/Azure/GCP/Oracle/
  Okta/Cloudflare/DO/Linode keys, GitHub CLI + git config, SSH keys, Docker auth,
  Helm, npm/pnpm/Yarn creds, Claude/Gemini/Codex/Cline configs, BTC/ETH/XMR wallets,
  browser history + PGP + shell history
CVE-2026-48558 - SimpleHelp OIDC token-signature bypass -> forged Technician

# Grep SimpleHelp server.log (and rotated logs/<ts>/server.log)
Registering technician login for
Configuration save requested (Forged Attacker -
# Admin console: Technicians -> Gear -> Show Group Authenticated Users
# Precondition check: OIDC enabled + TechnicianGroup + "Allow group authenticated logins"

⚠ Vendor-specific: confirm the exact fixed SimpleHelp version and OIDC config steps against current SimpleHelp release notes before deploying.

1 · WDAC/AppLocker — block node.exe on servers (PowerShell, AppLocker example)

# Create a deny rule for node.exe on systems that should never run Node.
# PILOT ON ONE RING FIRST -- node.exe is legitimate on developer workstations and on
# anything shipping an Electron app (Teams, Slack, VS Code).
#
# PREREQUISITE: the Application Identity service (AppIDSvc) must be Running/Automatic,
# or AppLocker evaluates nothing.
#
# New-AppLockerPolicy requires -FileInformation piped from Get-AppLockerFileInformation,
# and -Xml is a SWITCH, not a value parameter. It also only emits Allow rules -- there is
# no Deny mode, so the deny is made by editing Action in the generated XML.

$nodePath = "C:\Program Files\nodejs\node.exe"

# 1. Generate a path rule for the binary (this produces an ALLOW rule).
Get-AppLockerFileInformation -Path $nodePath |
  New-AppLockerPolicy -RuleType Path -User "BUILTIN\Users" `
    -RuleNamePrefix "Block-Node-RMM" -Xml |
  Out-File C:\Temp\block-node.xml -Encoding utf8

# 2. EDIT C:\Temp\block-node.xml before merging:
#      - change Action="Allow" to Action="Deny" on the generated FilePathRule
#      - set EnforcementMode="AuditOnly" on the RuleCollection for the pilot week
#      - keep the three default Allow rules (Program Files, Windows, Administrators).
#        AppLocker is default-deny: a collection holding only a Deny rule and no Allow
#        rules blocks EVERY executable on the machine, including your RMM agent.

# 3. Merge, then review audit events for a week before enforcing.
Set-AppLockerPolicy -XmlPolicy C:\Temp\block-node.xml -Merge

Verify: during the AuditOnly week, check Applications and Services Logs > Microsoft > Windows > AppLocker > EXE and DLL for EventID 8003 (would-have-blocked). Zero unexpected entries means it is safe to set EnforcementMode="Enabled"; a real block then logs EventID 8004.
Rollback: set EnforcementMode="NotConfigured" and re-merge, or unlink the GPO and gpupdate /force. If a host is locked out by an over-broad policy, boot to Safe Mode (AppLocker does not enforce there) and stop AppIDSvc.

2 · Restrict SimpleHelp exposure (host firewall allowlist)

# Limit inbound to the SimpleHelp listener to your VPN/ZTNA egress range only.
#
# DO NOT add a companion "-RemoteAddress Any -Action Block" rule on TCP/443. Two reasons:
#   1. The Windows Filtering Platform does not evaluate host rules in creation order --
#      an explicit Block always overrides an explicit Allow, so it would also block the
#      VPN range this rule exists to permit.
#   2. Port 443 is not exclusive to SimpleHelp. An unscoped Block on 443 takes out ALL
#      inbound HTTPS on the host, not just the RMM listener.
# Scope the Allow, then let the profile default do the blocking.

# PILOT ON ONE HOST. Staged disabled -- review, then enable deliberately.
$vpnRange = "10.20.0.0/16"    # <-- replace with your real VPN/ZTNA egress range

# 1. Record current state so you can roll back exactly.
Get-NetFirewallProfile | Select-Object Name, DefaultInboundAction

# 2. Create the scoped allow rule, DISABLED. Nothing changes yet.
#    -Program scopes it to the SimpleHelp service binary so other HTTPS is untouched.
New-NetFirewallRule -DisplayName "SimpleHelp-Allow-VPN-only" -Direction Inbound `
  -Protocol TCP -LocalPort 443 -RemoteAddress $vpnRange -Action Allow -Enabled False

# 3. Confirm the rule matches what you intended, THEN enable it.
Get-NetFirewallRule -DisplayName "SimpleHelp-Allow-VPN-only" | Get-NetFirewallAddressFilter
# Enable-NetFirewallRule -DisplayName "SimpleHelp-Allow-VPN-only"

# 4. Only after step 3 verifies clean, set the profile default for the profile the
#    listener is exposed on. This is what blocks the public internet.
# Set-NetFirewallProfile -Name Public -DefaultInboundAction Block

Verify: from inside the VPN range, Test-NetConnection <host> -Port 443 returns TcpTestSucceeded : True; from outside it must fail. Confirm any other HTTPS service on the host is still reachable.
Rollback: Remove-NetFirewallRule -DisplayName "SimpleHelp-Allow-VPN-only" and Set-NetFirewallProfile -Name Public -DefaultInboundAction NotConfigured (or whatever step 1 recorded).

3 · Falcon CQL spot-check after hardening

# Should return ZERO results once node.exe is blocked on RMM servers:
#event_simpleName=/ProcessRollup2/
| ParentBaseFileName=/^(Remote Access|RemoteWorker)\.exe$/i
| FileName=/^node\.exe$/i
| table([ComputerName, FileName, CommandLine])

Strongest coverage is at execution (Q1/Q2 — high CONF, low FP). Two structural gaps remain: the server-side auth bypass (covered by native log hunts in §7, not EDR) and off-host credential reuse (cloud/IdP telemetry). Validation: baseline Q1/Q5 for benign technician activity before promoting to Block.