Hardcoded JWT Secret in Default Configuration Enables Unauthenticated Privilege Escalation
PraisonAI Platform defaults to a publicly-known JWT signing secret when environment variables are not explicitly configured, allowing attackers to forge authentication tokens and impersonate any user including admins. This vulnerability is trivially exploitable in any default deployment.
CVE References
Affected
Vulnerability Description
PraisonAI Platform contains an insecure cryptographic default where the JWT (JSON Web Token) signing secret falls back to the hardcoded literal string "dev-secret-change-me" when the PLATFORM_JWT_SECRET environment variable is unset. The vulnerability is compounded by a broken safety guard: a check intended to prevent this in production only activates when PLATFORM_ENV != "dev", but the default value of PLATFORM_ENV is "dev". This creates a logical bypass where the default deployment state—simply running the application without explicit environment configuration—silently proceeds with the compromised secret. The JWT verification logic at line 129 performs HMAC-SHA256 validation against this known secret, then blindly trusts the decoded token's sub, email, and name claims without further validation. An attacker who possesses the hardcoded secret can mint valid JWTs impersonating any user ID in the system, including workspace owners and administrators.
Proof-of-Concept Significance
The PoC demonstrates complete authentication bypass requiring only knowledge of the hardcoded secret (readable from the public source repository) and the target user's ID. No interaction with legitimate users, social engineering, or session hijacking is necessary. The attack is 100% reliable against any deployment that has not explicitly set both PLATFORM_JWT_SECRET and overridden PLATFORM_ENV to a non-"dev" value. Preconditions are minimal: the application must be running with default configuration, which is the likely scenario for quick prototyping, CI/CD test environments, and users unfamiliar with the library. The vulnerability is trivially discoverable since the secret is hardcoded in a public repository.
Detection Guidance
Configuration Audit: Scan deployment pipelines and container images for the absence of PLATFORM_JWT_SECRET or PLATFORM_ENV environment variables; flag any instance where the application inherits defaults. Search for PLATFORM_ENV=dev or missing PLATFORM_ENV entirely. Log Indicators: Monitor authentication service logs for JWT validation success patterns that correlate with unusually rapid or bulk token generation; inspect decoded JWT claims in auth logs for iss or aud fields that deviate from expected issuer. Runtime Detection: Implement JWT secret entropy checks at startup; warn or fail if PLATFORM_JWT_SECRET matches common default strings or has entropy below a threshold. Behavioral Signals: Detect impossible travel (tokens from unrelated geographic regions in seconds), privilege escalation sequences (user→admin role transitions via single JWT), or lateral movement across workspaces using the same forged token.
Mitigation Steps
Immediate: Set PLATFORM_JWT_SECRET to a cryptographically random string (≥256 bits) in all deployments via environment variables or secrets management (HashiCorp Vault, AWS Secrets Manager, Kubernetes secrets). Set PLATFORM_ENV to "production" or similar non-"dev" value in production systems. Rotate all existing JWTs by invalidating sessions and forcing re-authentication. Code-level: Update auth_service.py to remove the default fallback to "dev-secret-change-me"; instead, raise an exception at startup if PLATFORM_JWT_SECRET is unset, making the requirement explicit and fail-safe. Replace the PLATFORM_ENV check with a positive assertion: verify that PLATFORM_JWT_SECRET is configured to a non-default value regardless of environment mode. Deployment: Enforce environment variable validation in CI/CD pipelines; fail builds that attempt to deploy without the required secrets. Add startup health checks that verify JWT secret entropy and configuration compliance.
Risk Assessment
This vulnerability poses extreme risk in the wild because default configurations are common in rapid prototyping, educational use, and early-stage deployments. Threat actors routinely scan public repositories for hardcoded secrets and default credentials; the advisory being public and the secret being in version control history means exploitation is inevitable if the library is used in any internet-facing deployment without explicit configuration. Organizations using PraisonAI Platform for multi-tenant or role-based access control systems are at highest risk; a single forged admin token compromises the entire installation. Likelihood of exploitation is very high because no technical sophistication is required beyond retrieving the secret from GitHub. The library's positioning as an accessible AI platform suggests a user base less likely to implement defense-in-depth security practices, increasing real-world exposure.
Sources