Critical SimpleHelp Exploit (CVE-2026-48558): TaskWeaver & Djinn Stealer in the Wild

We isolated our SimpleHelp servers as soon as the alert dropped. While we dig through logs, we've temporarily blocked the specific OIDC endpoints on the WAF.

I'd suggest looking for PowerShell child processes spawned by the SimpleHelp client. In our testing, Djinn Stealer attempts to drop a loader via PowerShell immediately after the auth bypass.

This is exactly why I hate exposing RMMs directly to the web, even with SSO.

If you can't patch immediately, restrict access to the management interface via VPN or IP allow-listing. As for detection, we've had success monitoring for cmd.exe or powershell.exe making outbound network connections where the parent process is the remote support tool.

Solid query. I'd also recommend checking your EDR for unusual file creation in the AppData directories. TaskWeaver seems to stage payloads there before execution.

Here is a quick Sigma rule concept we are testing:

detection:
  selection:
    ParentImage|endswith: '\SimpleHelp.Client.exe'
    Image|endswith:
      - '\powershell.exe'
      - '\cmd.exe'
  condition: selection

Better safe than sorry with a CVSS 10.

Solid advice. Beyond the endpoint, lateral movement is the biggest risk with this RMM compromise. You should audit the SimpleHelp backend directly for unauthorized technician accounts spawned during the attack window.

SELECT * FROM technicians WHERE created_at > 'start_time' AND source NOT IN ('admin', 'sso');

Also, watch for the specific C2 heartbeats Djinn uses; they often mimic standard HTTPS but have distinct JA3 fingerprints.

Great insights on the lateral movement. To supplement endpoint checks, I recommend hunting for the C2 infrastructure associated with Djinn. It often uses a specific User-Agent string during exfiltration. If you're pulling proxy logs, this quick grep helps identify potential callbacks:

grep -i "Mozilla/5.0 (compatible; DjinnBot/1.0)" /var/log/squid/access.log

Monitoring for this specific string has helped us catch instances where the initial payload bypassed signature-based detection.

Building on Ivan's point, don't just check for accounts—audit the database sessions directly. Since this bypasses OIDC, look for technician sessions missing the standard SSO correlation tokens. This Python snippet can help identify "ghost" sessions generated by the exploit:

import sqlite3
conn = sqlite3.connect('simplehelp.db')
cursor = conn.cursor()
cursor.execute("SELECT * FROM sessions WHERE auth_source='oidc' AND external_id IS NULL")
print(cursor.fetchall())

Excellent discussion on containment. To complement the Sigma rules and endpoint checks, don't overlook memory analysis. TaskWeaver often attempts to stay fileless by injecting directly into legitimate processes. I recommend scanning memory with a YARA rule targeting its specific section headers or known mutex strings.

yara rule TaskWeaver_Injected { strings: $mutex1 = "Global\WeaverTaskPool" wide $c ascii condition: 2 of them }

This can catch artifacts even if the disk payload is wiped.