CVE-2026-57147 in PraisonAI
Summary
by MITRE • 09/15/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in PraisonAI prior to version 0.1.6 represents a critical failure in authentication logic, specifically involving the handling of JSON Web Token secrets and environment configuration defaults. The core technical flaw resides within the auth_service.py module, where the system assigns a hardcoded default value for JWT_SECRET when the PLATFORM_JWT_SECRET environment variable is not explicitly set. This default secret, identified as public dev-secret-change-me, is widely known or easily guessable, effectively nullifying the cryptographic integrity of the tokens issued by the platform. Furthermore, the production guard mechanism intended to enforce stricter security protocols fails to activate because the PLATFORM_ENV setting defaults to dev when unset. Consequently, the application operates in a development mode that lacks the necessary safeguards for secure token verification and identity management, leaving the authentication subsystem exposed to exploitation.
From an operational perspective, this misconfiguration allows remote unauthenticated attackers to forge valid JSON Web Tokens using the HS256 algorithm with arbitrary subject claims and email addresses. Since the AuthService._verify_token() function and the get_current_user dependency rely on verifying these tokens against the known default secret, they will accept any token signed with it as legitimate. This enables an attacker to impersonate any user within the system without possessing valid credentials. The impact is severe, granting unauthorized access to protected API routes that depend on identity verification. Attackers can manipulate their perceived role or privileges by altering the sub and email fields in the forged tokens, potentially leading to privilege escalation, data exfiltration, or complete compromise of the application's integrity depending on how these identities are utilized within downstream business logic.
This vulnerability aligns with CWE-798: Use of Hard-coded Credentials, as it involves the use of a static, publicly known secret key for cryptographic operations. Additionally, it relates to CWE-284: Improper Access Control, because the authentication mechanism fails to properly restrict access based on identity verification. In terms of MITRE ATT&CK framework tactics, this flaw facilitates Initial Access through T1078: Valid Accounts, as attackers can create valid-looking credentials out of thin air, and potentially Impact via T1496: Resource Hijacking if the forged identities are used to consume resources or perform malicious actions under false pretenses. The failure to enforce environment-specific security configurations also touches upon CWE-250: Execution with Unnecessary Privileges, as the system operates in a less secure development mode by default rather than requiring explicit confirmation of production readiness for sensitive operations.
To mitigate this vulnerability and prevent similar issues in future deployments, it is imperative that applications never rely on hardcoded defaults for cryptographic secrets such as JWT signing keys. The PLATFORM_JWT_SECRET must be generated using a cryptographically strong random number generator and stored securely via environment variables or dedicated secret management systems like HashiCorp Vault or AWS Secrets Manager. Additionally, the default value for PLATFORM_ENV should not automatically resolve to dev in production contexts; instead, explicit configuration is required to ensure that security guards are active. Developers must implement strict validation checks that reject tokens signed with known weak keys and enforce non-default configurations before allowing access to protected resources. Regular security audits and static analysis tools configured to detect hard-coded secrets can further help identify such misconfigurations during the development lifecycle.