Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-15T11:17:11.760Z",
  "pubdate": "2026-09-15T11:17:11.760Z",
  "executiveSummary": "PraisonAI versions prior to 0.1.6 are vulnerable to an authentication bypass vulnerability stemming from the use of a hardcoded, publicly known cryptographic secret for JSON Web Token (JWT) signing.\nThe vulnerability type is improper authentication/cryptographic failure, allowing unauthenticated remote attackers to forge valid authentication tokens.\nBy leveraging the default secret 'dev-secret-change-me' when environment variables are unset, an attacker can mint HS256 tokens with arbitrary user claims.\nThis flaw grants unauthorized access to protected API endpoints, enabling full impersonation of any user on the platform, including administrative accounts.\nThe risk is critical as it requires no prior authentication and can be exploited remotely by any user with access to the platform's authentication service.\nThe vulnerability persists because the production guard mechanism fails to trigger when the PLATFORM_ENV variable defaults to 'dev' due to an unhardened configuration pattern.",
  "technicalDetails": "The vulnerability resides within 'praisonai_platform/services/auth_service.py', specifically in how the application manages its JWT signing secret.\nThe root cause is a dual-configuration failure: the application assigns a default, insecure, and hardcoded string 'dev-secret-change-me' to the 'JWT_SECRET' variable if 'PLATFORM_JWT_SECRET' is not explicitly defined. Simultaneously, the application’s environment-based production guard logic depends on the 'PLATFORM_ENV' variable. If this variable is unset, the system defaults to 'dev' mode, effectively bypassing the mandatory security check that would otherwise enforce a strong, secret key in production environments.\nAn attacker can exploit this by constructing a JWT using the HS256 algorithm (HMAC with SHA-256) and signing it with the known string 'dev-secret-change-me'. Because the 'AuthService._verify_token()' method uses this same insecure default to validate incoming requests, the forged token is treated as cryptographically valid.\nThe attack flow is as follows: 1) The attacker identifies that the target instance has not overridden the default environment variables. 2) The attacker crafts a JWT payload containing desired 'sub' (subject) and 'email' fields. 3) The attacker signs this payload using the known hardcoded secret. 4) The attacker sends this token in the Authorization header to protected API routes. 5) The 'get_current_user' dependency in the FastAPI/service layer validates the signature against the hardcoded key, finds it valid, and elevates the attacker’s privileges to match the identity defined in the forged token.\nThis allows for complete session hijacking and unauthorized resource access. Because the platform relies on this token for identity verification across its entire ecosystem, successful exploitation leads to full compromise of the affected PraisonAI instance, bypassing all session-based access controls."
}