GHSA-cwj8-7gp2-ggcw: praisonai-platform: default JWT signing secret 'dev-secret-change-me' enables token forgery
praisonai-platform: default JWT signing secret `dev-secret-change-me`**Researcher:** Kai Aizen — SnailSploit (@SnailSploit), Adversarial & Offensive Security Research
**Target:** https://github.com/MervinPraison/PraisonAI**Package:** `praisonai-platform` on PyPI
**Latest version (and version tested):** `0.1.4`, current as of 2026-06-01.
**File:** `praisonai_platform/services/auth_service.py` (sha256 `cc29d43c5412da2c73c818859b8d8b146587842999b777336017ab9d9e509258`).
**Weakness:** CWE-798 Use of Hardcoded Credentials + CWE-1188 Insecure Default Initialization of Resource.TL;DR`praisonai_platform/services/auth_service.py` lines 25-37:The guard at line 33 is meant to catch the "deployed to production with the default secret" failure mode. But it only fires when **both**:the operator left `PLATFORM_JWT_SECRET` unset (so `JWT_SECRET` is the default literal), **and**the operator explicitly set `PLATFORM_ENV` to something other than `"dev"`.If the operator left **both** env vars unset — the most common mis-deploy — `PLATFORM_ENV` falls back to `"dev"`, the second leg of the `and` evaluates `False`, and the guard does NOT fire. The server starts up signing every JWT with the public string `'dev-secret-change-me'`.The fix is to invert the polarity: refuse startup when the secret is the default **regardless** of `PLATFORM_ENV`, except when an explicit `PLATFORM_ALLOW_DEV_SECRET=true` (or equivalent) flag is set. That flips "default-allow" to "default-deny", which is what the line-33 comment implies the author wanted.Root causeEmpirical verification`poc/poc.py` imports the **installed** PyPI package (`praisonai-platform==0.1.4`) with both env vars unset:Step [5] is the load-bearing one: the attacker token is decoded by the **same method** the FastAPI dependency `get_current_user` (`praisonai_platform/api/deps.py:28`) calls. The returned `AuthIdentity` carries the attacker-chosen `sub` (user id) and `email`. Every route protected by `Depends(get_current_user)` (register/login, workspaces, projects, issues, agents, labels, activity, dependencies) accepts the forged token as proof of identity.PyJWT itself warns the key is 20 bytes — below the RFC 7518 §3.2 minimum of 32 bytes for HS256.ImpactThis is the familiar default-secret shape — a hardcoded fallback used to sign authentication tokens — with the additional twist that this one has a guard the author *intended* to catch the misconfiguration but whose polarity is wrong. Every route in `praisonai_platform.api.app:create_app` is authenticated via Bearer JWT, and every Bearer JWT is signed and verified with the public default secret. An unauthenticated network-adjacent attacker mints a token carrying any user-id (and any e-mail, name, etc.) they like, and the platform server treats them as that user.Workspace authorisation (`require_workspace_member` in `deps.py`) then checks the forged user is a member of the requested workspace; if the attacker mints a token with `sub` equal to a known member's id, they bypass that check too. In default deployments, workspace IDs and member IDs are exposed via the activity and labels endpoints to any authenticated client — including the attacker's own forged token.Anchors`praisonai-platform` 0.1.4, `praisonai_platform/services/auth_service.py` (file sha256 `cc29d43c5412da2c73c818859b8d8b146587842999b777336017ab9d9e509258`):| Line  | Code                                                                | Meaning |
|-------|---------------------------------------------------------------------|---------|
| 25    | `_DEFAULT_SECRET = "dev-secret-change-me"`                          | Public default literal.  |
| 26    | `JWT_SECRET = os.environ.get("PLATFORM_JWT_SECRET", _DEFAULT_SECRET)` | Env-var fallback chain. |
| 27    | `JWT_ALGORITHM = "HS256"`                                            | HMAC-SHA256 with the default key. |
| 33-37 | `if JWT_SECRET == _DEFAULT_SECRET and os.environ.get("PLATFORM_ENV", "dev") != "dev": raise RuntimeError(...)` | The asymmetric guard.  Defaults `PLATFORM_ENV` to `"dev"`, so the `!= "dev"` check evaluates `False` on the forgot-to-set case. |
| 108-118 | `_issue_token(...)` calls `jwt.encode(payload, JWT_SECRET, …)`     | Signing site. |
| 137-150 | `_verify_token(...)` calls `jwt.decode(token, JWT_SECRET, algorithms=[JWT_ALGORITHM])` | Verification site — accepts attacker-forged tokens.  |`praisonai_platform/api/deps.py:28` `get_current_user` calls `AuthService.authenticate({"token": token})` which routes to `_verify_token`. Every router under `praisonai_platform.api.app` mounts handlers behind this dependency.Suggested fixInvert the guard polarity:This pattern is borrowed from Django's `SECRET_KEY` first-boot generation (refuses to start when unset) and from the first-boot secret-generation pattern used by many production Docker images. The marker variable (`PLATFORM_ALLOW_DEV_SECRET=true`) is explicit and grep-able in deployment manifests, so operators who pass it through to production get caught by their own audit / IaC linter rather than slipping past a guard that always passes by default.Steps to reproduceClone the target: `git clone --depth 1 https://github.com/MervinPraison/PraisonAI`Run the proof of concept (`poc.py`) against the cloned source.Observe the result shown under *Verified result* below.Proof of concept`poc.py`Verification harness (executed against the cloned repo)This drives the unmodified upstream code rather than a reproduction.Verified resultThis PoC was executed against the live upstream code; captured output:CreditKai Aizen — SnailSploit (@SnailSploit). Adversarial & Offensive Security Research.
CVSS v3.1: 9.8