PraisonAI Platform EUVD-2026-78396

Exploitable against DEFAULT deployments of praisonai-platform <0.1.6 (and PraisonAI <4.6.51) that do not explicitly export a strong PLATFORM_JWT_SECRET - which the documented startup command (python -m praisonai_platform --host 0.0.0.0 --port 8000 / uvicorn equivalent) does not, so the vulnerable state is the shipped default rather than an edge case. The two conditions are: (1) PLATFORM_JWT_SECRET unset (falls back to public 'dev-secret-change-me'), and (2) PLATFORM_ENV left at its default 'dev', which leaves the startup and token-issuance guards default-open. The only practical limiting factor is that workspace-owner takeover requires the attacker to know the target owner's user/sub identifier; arbitrary user impersonation needs only a valid target id. Deployments that explicitly set a strong PLATFORM_JWT_SECRET are not exploitable.

All exploitability signals in the CVSS vector align and are genuinely justified: AV:N (JWT verified over the network API), AC:L (mint a token with any JWT library), PR:N and UI:N (no account, no victim interaction). Critically, PR:N is NOT overstated here - unlike most 9.8 authentication flaws, the signing secret 'dev-secret-change-me' is a public string readable in open-source, so the attacker truly needs zero prior privilege. This makes the 9.8/Critical rating well-calibrated. Countervailing signals temper urgency: EPSS is only 0.53% (43rd percentile), there is no CISA KEV listing and no public exploit code, so this is currently a latent high-severity issue rather than one under observed mass exploitation. The most important nuance from the GHSA advisory is that this CVE exists specifically to correct the record on GHSA-3qg8-5g3r-79v5 (the sibling CVE-2026-57147), which declared the flaw fixed in 0.1.4 - it was NOT; 0.1.4 duplicated the same default-open guard into a second function instead of failing closed, so 0.1.4 and main HEAD remain fully vulnerable. Real fix is 0.1.6. Bottom line: a real, high-priority patching target for anyone actually running praisonai-platform, but low real-world exploitation pressure so far.

An attacker reads the hard-coded default secret 'dev-secret-change-me' directly from the public PraisonAI source, then uses any JWT library to sign an HS256 token setting sub to a known target user or workspace-owner id with a future exp. They send this forged token to the platform API (default entry point python -m praisonai_platform --host 0.0.0.0 --port 8000, which sets neither PLATFORM_JWT_SECRET nor PLATFORM_ENV); AuthService._verify_token() accepts it and returns that identity, granting full impersonation. No public exploit is published, but forgery is trivial and requires no account.