CVE-2026-57148 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 falls back to the public dev-secret-change-me HS256 signing key when PLATFORM_JWT_SECRET is unset, while the startup and token-issuance guards are disabled because PLATFORM_ENV also defaults to dev. An unauthenticated attacker can sign a JWT containing an attacker-chosen sub value, and AuthService._verify_token() accepts it as an authenticated identity, enabling user or workspace-owner impersonation when a target identifier is known. This vulnerability is fixed in praisonai-platform 0.1.6.
Statistical analysis made it clear that VulDB provides the best quality 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 stemming from insecure default configurations and improper handling of cryptographic secrets. The core issue resides within the auth_service.py module, which is responsible for validating JSON Web Tokens (JWTs) used to establish user identity and permissions. When the environment variable PLATFORM_JWT_SECRET is not explicitly set during deployment, the system falls back to a hardcoded public development key known as dev-secret-change-me using the HS256 signing algorithm. This default behavior persists because the platform also defaults its operational mode to dev via the PLATFORM_ENV variable, which disables startup security guards and token-issuance restrictions that would otherwise prevent such weak configurations in production environments.
From a technical perspective, this flaw allows an unauthenticated attacker to forge valid authentication tokens. Since HS256 relies on symmetric key cryptography, possession of the signing secret is sufficient for any party to generate new JWTs with arbitrary claims. By leveraging the known default secret, an adversary can construct a token containing a sub (subject) claim corresponding to a specific user or workspace owner identifier that they wish to impersonate. The AuthService._verify_token() method accepts this forged token as valid because it successfully verifies against the public development key without raising any exceptions regarding signature validity or expiration issues inherent in default dev settings.
The operational impact of this vulnerability is severe, enabling complete authentication bypass and identity spoofing. An attacker who knows a target user's identifier can gain unauthorized access to their account with full privileges associated with that role. If the targeted identifier corresponds to an administrator or workspace owner, the attacker may escalate privileges further, potentially gaining control over sensitive data, configuration settings, or other users within the system. This undermines the fundamental security principle of least privilege and compromises the integrity of multi-agent team operations managed by PraisonAI.
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 signing in what should be a secure context. Additionally, it relates to CWE-287: Improper Authentication, specifically regarding the failure to verify identity properly due to weak credential management. In terms of MITRE ATT&CK framework tactics, this flaw facilitates Initial Access through T1078: Valid Accounts and potentially Privilege Escalation via T1068: Exploitation for Privilege Escalation if higher-level roles are targeted.
To mitigate this risk, organizations must ensure that PLATFORM_JWT_SECRET is set to a strong, randomly generated secret value before deploying PraisonAI in any environment other than isolated local development. It is imperative never to rely on default configuration values in production systems. Upgrading to version 0.1.6 or later resolves the issue by enforcing stricter validation rules and removing the insecure fallback mechanism. Security teams should also audit their deployment pipelines to ensure that sensitive environment variables are injected securely and not left unset, thereby preventing accidental exposure of weak cryptographic keys.