EUVD-2026-78397
GHSA-cwj8-7gp2-ggcw
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify exposed praisonai-platform API
-
DeliveryForge HS256 JWT with public dev-secret
-
ExploitSet arbitrary sub/email in token
-
ExecutionCall protected routes as forged user
-
ImpactAccess/modify agent data and resources
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Credential externalization
MITRE ATT&CK
2 techniques across 2 tactics: Persistence, Credential Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitable when the operator deploys praisonai-platform (< 0.1.6) without setting the PLATFORM_JWT_SECRET environment variable AND without setting PLATFORM_ENV - i.e., leaving both at their defaults, which is the common mis-deploy. In that state JWT_SECRET falls back to the public literal 'dev-secret-change-me' and the production guard never fires because PLATFORM_ENV defaults to 'dev', evaluating the guard's second condition to false. The only real limiting factor is that an operator who explicitly set a strong PLATFORM_JWT_SECRET (or set PLATFORM_ENV to non-dev to trigger the guard) is not affected; no authentication, user interaction, or special platform is otherwise required, and the signing secret is public in source code. |
| Impact | All signals point to a genuinely high-priority flaw with a well-calibrated score. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H = 9.8) is credible rather than inflated: the signing secret 'dev-secret-change-me' is published in the open-source repo, and the broken production guard means the most common deployment (both PLATFORM_JWT_SECRET and PLATFORM_ENV left unset) ships vulnerable BY DEFAULT, so PR:N and AC:L are honest. This is a straightforward cryptographic auth-bypass requiring only knowledge of the public constant and any JWT library. Countervailing signals temper urgency: EPSS is 0.51% (42nd percentile), there is no CISA KEV listing and no public exploit-code flag, indicating no confirmed active exploitation yet. The limiting factor is deployment reality - only instances that never set a strong PLATFORM_JWT_SECRET are exploitable, though because that is the default failure mode, exposure is likely wherever the platform is internet-facing. Net: a real priority for any operator running praisonai-platform in production, not a paper-high CVSS. |
| Exploit ScenarioDerived | An attacker finds an internet-exposed praisonai-platform instance whose operator deployed without setting PLATFORM_JWT_SECRET (the default mis-deploy). Using the publicly known secret 'dev-secret-change-me', they mint a valid HS256 JWT with an arbitrary sub and email, then present it to protected API routes, which get_current_user accepts as a legitimate (even administrative) user. No public exploit code is flagged, but the technique is fully documented in the GHSA advisory and trivial to reproduce. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 16, 2026
Authentication bypass in praisonai-platform before 0.1.6 lets any remote unauthenticated attacker mint a valid HS256 JSON Web Token and impersonate arbitrary users against protected API routes. The flaw is a hardcoded fallback signing secret ('dev-secret-change-me') combined with a production guard that never fires when the operator leaves both PLATFORM_JWT_SECRET and PLATFORM_ENV unset - the common mis-deploy - so the platform silently starts signing tokens with a publicly known literal drawn straight from the source code. CVSS 3.1 scores this 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and EPSS is 0.51% (42nd percentile); there is no CISA KEV listing and no public exploit identified at time of analysis, though exploitation requires nothing more than a forged token and no authentication whatsoever.
RemediationAI
Vendor-released patch: upgrade praisonai-platform to 0.1.6 or later (PraisonAI v4.6.51 for the parent project), available via PyPI and the GitHub release at https://github.com/MervinPraison/PraisonAI/releases/tag/v4.6.51; the change is associated with PR https://github.com/MervinPraison/PraisonAI/pull/1793 and commit e0fb8e7dd1ee6759c18ed07f436c21dbd9c20747, and details are in advisory GHSA-cwj8-7gp2-ggcw. If upgrading cannot be done immediately, the highest-value compensating control is to explicitly set PLATFORM_JWT_SECRET to a strong random value (for example, output of a CSPRNG) - this removes the hardcoded literal as a valid signing key and defeats token forgery, with the trade-off that all previously issued tokens become invalid and clients must re-authenticate; additionally set PLATFORM_ENV to a non-dev value so the existing production guard fires and fails fast on any future misconfiguration. Because the default signing secret is public, assume any token ever issued by an affected instance is forgeable: rotate the JWT signing secret and, if user identity or sessions were trusted on that basis, review access logs for anomalous sub/email claims and forced API actions - note that the default 30-day token TTL means rotation (not expiry) is what invalidates outstanding tokens. Operators who cannot set a real secret should restrict network access to the platform's protected API routes at the reverse proxy or firewall as a stopgap, accepting that this breaks legitimate remote clients and is not a substitute for the patch.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in pypi, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The affected component is the Python package praisonai-platform (praisonai_platform/services/auth_service.py), the authentication service backing the PraisonAI multi-agent teams platform distributed via PyPI. The root cause is CWE-798 (Use of Hardcoded Credentials), compounded by CWE-1188 (Insecure Default Initialization of Resource): the module defines _DEFAULT_SECRET = 'dev-secret-change-me' and resolves JWT_SECRET via os.environ.get('PLATFORM_JWT_SECRET', _DEFAULT_SECRET), so an unset environment variable silently falls through to the public literal. The intended production guard is written as a compound condition that only raises RuntimeError when the secret equals the default AND os.environ.get('PLATFORM_ENV', 'dev') != 'dev' - but because PLATFORM_ENV itself defaults to 'dev', leaving both variables unset evaluates the second leg to False and the guard is skipped entirely, giving default-allow rather than default-deny behavior. Tokens are signed with HS256 and a default TTL of 30 days, and the platform's AuthService._verify_token() and get_current_user dependency accept any token whose signature validates against that literal, so an attacker who knows the secret (it is public in the repository) can assert arbitrary sub and email claims. No authentication, user interaction, or unusual network position is required; the only precondition is the operator-side configuration gap described above. The upstream fix flips the polarity so the service refuses to start with the default secret regardless of PLATFORM_ENV.
Know when Praisonai gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Public signing secret plus default-vulnerable deployment gives unauthenticated network forgery (PR:N/AC:L); accepted identity on protected routes yields full impersonation, so C:H/I:H/A:H.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
DescriptionCVE.org
PraisonAI is a multi-agent teams system. Prior to 0.1.6, praisonai_platform/services/auth_service.py assigns the public dev-secret-change-me value to JWT_SECRET when PLATFORM_JWT_SECRET is unset, and its production guard does not run when PLATFORM_ENV is also unset because that setting defaults to dev. A remote unauthenticated attacker can mint an HS256 token with an arbitrary sub and email, and the platform's AuthService._verify_token() and get_current_user dependency accept the forged identity for protected API routes. This vulnerability is fixed in praisonai-platform 0.1.6.
Technical POC Analysis
praisonaiplatform/services/authservice.py in praisonai-platform contains a hard-coded fallback JWT signing key: DEFAULTSECRET = "dev-secret-change-me" and JWTSECRET = os.environ.get("PLATFORMJWTSECRE…
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
praisonai-platform deployments earlier than version 0.1.6 allow any remote, unauthenticated attacker to impersonate arbitrary users - including administrators - against protected API routes, effectively handing over full control of the platform and the data it manages. Because no credentials are needed and the flaw is rated CVSS 9.8 with full confidentiality, integrity and availability impact, any internet-exposed instance should be treated as an open door to customer records, agent configurations and connected data sources. While no public exploit code or active exploitation has been identified at time of analysis, the barrier to abuse is low enough that leadership should assume exposure is possible and act immediately.
Apply vendor patch. Until upgrade to 0.1.6 or later is complete, set PLATFORM_JWT_SECRET to a strong unique value and set PLATFORM_ENV explicitly so the hardcoded fallback signing secret is never used, and restrict network access to the platform to trusted networks.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Remote code execution in PraisonAI before 1.6.78 allows attackers to run arbitrary Python on the host by manipulating th
PraisonAI's TypeScript MCP server (npm package `praisonai`, versions 1.5.0 through 1.7.1) exposes an HTTP JSON-RPC trans
WebSocket origin-validation bypass in PraisonAI's Browser Server (praisonai/browser/server.py) before 4.6.58 lets an att
PraisonAI's `praisonai serve` subsystem (agents and unified modes) accepts an `--api-key` CLI flag that is parsed but ne
System prompt extraction and unauthorized tool invocation in PraisonAI before 4.6.78 arise because the prompt-injection
Unauthenticated remote agent invocation in PraisonAI versions 4.6.34 through 4.6.57 allows any network-reachable caller
SSRF protection bypass in PraisonAI's praisonaiagents library (all versions before 1.6.58) lets low-privileged users rou
Server-side request forgery in PraisonAI's Crawl4AI/Chromium crawling backend (all versions before 1.6.78) lets low-priv
Authentication fail-open in PraisonAI's Recipe HTTP server allows unauthenticated remote attackers to invoke recipe exec
Authentication bypass in PraisonAI's AgentServer component exposes all routes - /publish, /events, /info, /health - to u
Arbitrary Python code execution in PraisonAI's workflow include feature allows an attacker who controls a local recipe d
Server-side request forgery in PraisonAI's web_crawl() function (versions 1.5.128-1.6.57) allows an attacker who can inf
Exploit-DB