CVE-2026-47410: praisonai-platform: JWT signing key defaults to hardcoded "dev-secret-change-me", allowing token forgery for any user when PLATFORM_ENV is unset

Should you act?

Critical and remotely reachable

No known exploitation yet, but it is network-reachable without credentials. This signal is computed from CISA KEV, EPSS and CVSS data; it is not an editorial verdict.

• Not in CISA KEV, but CISA’s SSVC assessment records a public proof-of-concept, so attack code exists.
• EPSS 0.6%, percentile 50: FIRST’s model estimates a 0.6% chance of exploitation activity in the next 30 days, higher than 50% of all scored CVEs (low). EPSS is a probability, not a verdict.
• Remotely reachable with no login and no user interaction. If the vulnerable service is exposed to the internet, prioritize it.
• Only applies if your dependency tree includes praisonai-platform (PyPI) <= 0.1.2, fixed in 0.1.4. Check your lockfile, including transitive dependencies.

What it is

PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have an insecure default cryptographic key. The JWT signing secret defaults to the hardcoded literal "dev-secret-change-me" when PLATFORMJWTSECRET is unset. A safety check exists but only fires when PLATFORMENV != "dev"; the default value of PLATFORMENV is "dev", so the check is silently bypassed in any deployment that does not explicitly opt out. The attacker reads the literal from this public source file, mints a JWT with arbitrary sub and email claims, and authenticates as any existing user (including workspace owners and admins). PraisonAI Platform version 0.1.4 patches the issue.

From the GitHub advisory

Summary

Type: Insecure default cryptographic key. The JWT signing secret defaults to the hardcoded literal "dev-secret-change-me" when PLATFORMJWTSECRET is unset. A safety check exists but only fires when PLATFORMENV != "dev"; the default value of PLATFORMENV is "dev", so the check is silently bypassed in any deployment that does not explicitly opt out. The attacker reads the literal from this public source file, mints a JWT with arbitrary sub and email claims, and authenticates as any existing user (including workspace owners and admins). File: src/praisonai-platform/praisonaiplatform/services/authservice.py, lines 25-36 and 114-137. Root cause: the production-mode guard checks os.environ.get("PLATFORMENV", "dev") != "dev" — but the default is "dev", so a clean deployment that just imports the package and runs uvicorn praisonaiplatform.api.app:app proceeds with the hardcoded secret. The package documentation does not warn loudly enough that BOTH variables must be set; the guard suppresses itself when either condition is missed. JWT verification at line 129 trusts whatever the token says (sub, email, name) once the HMAC-SHA256 signature validates against the publicly-known secret. Since the verifier accepts forged tokens for any userid, the attacker becomes that user across every authenticated route.

Affected Code

File: src/praisonai-platform/praisonaiplatform/services/authservice.py, lines 25-36 and 114-137.

Why it's wrong: the guard's predicate is wrong. The intent — "warn loudly if a production deployment ships without setting the secret" — is correct, but the implementation requires the operator to set BOTH variables (PLATFORMJWTSECRET and PLATFORMENV != "dev") for the guard to fire. A common deployment misconfiguration is to set only one (or neither): pip install praisonai-platform, uvicorn praisonaiplatform.api.app:app --host 0.0.0.0, done. The package starts with no warning, the JWT signing key is the literal string sitting in this source file, and any attacker who reads the GitHub repo can forge tokens. The standard pattern is to fail-closed at import time when the secret is the default, regardless of any environment variable. The code at line 32-36 inverts that: it fails-open by default and only fails-closed when the operator opts in.

Weakness type: CWE-321, CWE-798.

Product: praisonai-platform (PyPI) · Assigned by: GitHub_M · Published: 2026-07-21

Affected and fixed versions

Severity scores

• Attack vector: network (remotely reachable)
• Attack complexity: low
• Privileges required: none (no login)
• User interaction: none
• Scope: unchanged

CVSS measures how bad a flaw is if exploited, not how likely exploitation is. Read it next to the exploitation data below.

Exploitation and urgency

• CISA KEV: not listed (no confirmed in-the-wild exploitation known to CISA).
• CISA SSVC assessment: exploitation poc, automatable yes, technical impact total.
• FIRST EPSS (model of 2026-10-21): 0.64% probability of exploitation activity in the next 30 days; percentile 50.

Timeline

• 2026-05-29 — GitHub-reviewed advisory GHSA-3qg8-5g3r-79v5 published (critical)
• 2026-07-21 — CVE record published by GitHub_M
• 2026-07-22 — CVE record last updated

Sources and references

Original sources first. Version and fix details should always be confirmed against the vendor or project advisory.

Vulnerability records

1. GitHub Advisory GHSA-3qg8-5g3r-79v5 github.com
2. CVE.org record CVE-2026-47410 cve.org
3. NVD entry CVE-2026-47410 nvd.nist.gov

Other references from the CVE record and advisory

1. github.com github.com
2. github.com github.com
3. github.com github.com

Critical PyPI advisories · Today’s Security Digest