CVE-2026-47410 - PraisonAI Platform default JWT secret
PraisonAI Platform versions 0.1.2 and earlier can start with a public,
hardcoded JWT signing secret when PLATFORM_JWT_SECRET is not set. The
intended production guard is tied to PLATFORM_ENV, but PLATFORM_ENV also
defaults to development mode, so a clean deployment can miss both variables and
still accept tokens signed with the public default.
For exposed platform APIs, this turns a configuration mistake into an
authentication boundary failure. If an attacker can reach the API and learn or
guess user identifiers, a forged bearer token can be accepted as that user
across authenticated workspace routes. The safe remediation is not just setting
PLATFORM_ENV; the runtime must consume a fixed package, require a strong
secret, reject the public default, and invalidate tokens issued under the old
key.
Affected versions
- Vulnerable package:
praisonai-platform <=0.1.2 - Fixed package:
praisonai-platform 0.1.4+ - Affected coordinate:
praisonai-platformon PyPI - Affected surface: PraisonAI Platform authentication service and any deployed API that verifies platform JWT bearer tokens
- Risky default: missing
PLATFORM_JWT_SECRETplus missing or defaultPLATFORM_ENV
Indicator-of-exposure
- The repository depends on, vendors, forks, or deploys
praisonai-platform <=0.1.2. - A PraisonAI Platform API is launched with
uvicorn, FastAPI, Docker, Compose, Helm, Kubernetes, systemd, Procfile, or platform-as-a-service config controlled by this repository. PLATFORM_JWT_SECRETis missing, weak, checked into source, shared across environments, generated at image-build time, or stored outside a secret manager.- Deployment docs,
.env.example, Helm values, CI variables, or runbooks rely onPLATFORM_ENV=devor do not explain that a production secret is required. - Long-lived platform JWTs, workspace-owner privileges, admin routes, issue data, agent configuration, or tenant data are protected only by the platform bearer token.
Quick checks:
rg -n "praisonai-platform|praisonai_platform|PLATFORM_JWT_SECRET|PLATFORM_ENV|auth_service|uvicorn.*praisonai_platform|praisonai.*platform" .
python -m pip show praisonai-platform
python -m pip freeze | rg -i '^praisonai-platform=='
[ -n "${PLATFORM_JWT_SECRET:-}" ] && echo "PLATFORM_JWT_SECRET is set" || echo "PLATFORM_JWT_SECRET is missing"
[ -n "${PLATFORM_ENV:-}" ] && echo "PLATFORM_ENV is set" || echo "PLATFORM_ENV is missing"
Windows:
rg -n "praisonai-platform|praisonai_platform|PLATFORM_JWT_SECRET|PLATFORM_ENV|auth_service|uvicorn.*praisonai_platform|praisonai.*platform" .
python -m pip show praisonai-platform
python -m pip freeze | rg -i '^praisonai-platform=='
if ($env:PLATFORM_JWT_SECRET) { "PLATFORM_JWT_SECRET is set" } else { "PLATFORM_JWT_SECRET is missing" }
if ($env:PLATFORM_ENV) { "PLATFORM_ENV is set" } else { "PLATFORM_ENV is missing" }
Do not print PLATFORM_JWT_SECRET, decoded production JWTs, database user
records, or live authorization headers during triage.
Remediation strategy
- Upgrade every controlled
praisonai-platformdependency, lockfile, image, deployment, SBOM, and generated dependency report to0.1.4+. - Require
PLATFORM_JWT_SECRETfrom a secret manager, Kubernetes Secret, platform secret, or equivalent runtime-only source. Use a high-entropy value of at least 32 random bytes. - Reject the public default and fail closed when no secret is configured. If this repository owns a fork or wrapper, local development should require an explicit opt-in and use an ephemeral per-process secret, not a shared literal.
- Add deployment preflight checks that report secret presence without logging the secret value.
- Invalidate existing platform JWTs after changing the signing key. Restart services, clear cached auth state where applicable, and rotate any weak, shared, or default-derived platform secrets.
- Review workspace membership, admin, issue, project, agent, and audit logs for suspicious access during the window where the default or weak secret may have been accepted.
When to use it
Use this recipe when a repository deploys, packages, forks, wraps, or configures
PraisonAI Platform authentication, JWT verification, environment files, Helm or
Kubernetes manifests, Compose files, Procfiles, systemd units, or platform
secrets. It is most important when PLATFORM_JWT_SECRET may be missing, weak,
shared, committed, image-baked, or defaulted.
Use it to upgrade the platform and enforce a strong runtime JWT secret with token invalidation. Do not use it to forge tokens against a live deployment or print production secrets.
Inputs
- Python manifests, lockfiles, constraints, Dockerfiles, Compose files, Helm
charts, Kubernetes manifests, Procfiles, systemd units, CI jobs, deployment
templates,
.env.example, docs, SBOMs, generated reports, forks, and local auth wrappers. - Runtime auth config:
PLATFORM_JWT_SECRET,PLATFORM_ENV, secret manager references, Kubernetes Secrets, platform secrets, image-build variables, docs examples, and startup preflight checks. - Token and exposure evidence: public/default/weak secrets, shared secrets, JWT lifetimes, token caches, session stores, API instances, workspace/admin routes, audit logs, and suspicious auth activity.
- Secret-handling controls: entropy requirement, per-environment uniqueness, runtime injection, fail-closed startup, log redaction, local-dev opt-in, and token invalidation or logout.
- Validation evidence: auth startup tests, missing/default-secret rejection, log redaction tests, deployment rendering, container builds, SBOM refresh, and non-secret smoke checks.
The prompt
You are remediating CVE-2026-47410 / GHSA-3qg8-5g3r-79v5, a PraisonAI
Platform hardcoded default JWT signing secret issue. Produce exactly one
output:
- A reviewer-ready PR/change request that upgrades affected package usage,
requires a strong runtime JWT secret, adds fail-closed checks and regression
tests, and documents operator token rotation, or
- TRIAGE.md if this repository does not control an affected PraisonAI Platform
runtime, dependency, image, or deployment.
## Rules
- Scope only CVE-2026-47410 / GHSA-3qg8-5g3r-79v5 and directly related JWT
secret handling.
- Treat `PLATFORM_JWT_SECRET`, bearer tokens, decoded JWT claims, user IDs,
email addresses, workspace data, admin routes, database rows, audit logs, and
platform session stores as sensitive.
- Do not print secrets, decode production tokens into logs, capture live
authorization headers, or forge tokens against a live deployment.
- Do not treat `PLATFORM_ENV=production` alone as a fix. The signing secret
must be strong, runtime-provided, and absent from source control.
- Do not leave the public default secret usable in any non-test code path.
- Do not auto-merge.
## Steps
1. Inventory every PraisonAI Platform reference controlled by this repository:
requirements, pyproject files, lockfiles, constraints, Dockerfiles,
Compose files, Helm charts, Kubernetes manifests, Procfiles, systemd units,
CI jobs, deployment templates, `.env.example`, docs, SBOMs, and generated
dependency reports.
2. Determine every resolved `praisonai-platform` version. A target is
vulnerable if it resolves to `0.1.2` or earlier.
3. Search all runtime configuration for `PLATFORM_JWT_SECRET`,
`PLATFORM_ENV`, hardcoded JWT secrets, image-build-time secret generation,
copied `.env` files, and examples that omit the secret.
4. If this repository does not deploy or package PraisonAI Platform, stop with
`TRIAGE.md` listing checked files and the external owner if another
platform supplies the runtime.
5. Upgrade all controlled package pins to `praisonai-platform 0.1.4+`.
Regenerate lockfiles, constraints, image metadata, SBOMs, dependency
reports, and generated docs.
6. Wire `PLATFORM_JWT_SECRET` from a runtime secret source:
- secret manager, Kubernetes Secret, platform secret, or CI/deployment
secret;
- at least 32 random bytes or equivalent entropy;
- unique per environment;
- never committed to the repository or baked into a container image.
7. Add a startup or deployment preflight where this repository owns runtime
code or manifests:
- fail closed if `PLATFORM_JWT_SECRET` is absent;
- fail closed if the known public default appears;
- emit only a non-secret remediation message;
- run before the API begins accepting requests.
8. If this repository owns a fork, wrapper, compatibility shim, or local auth
service copied from PraisonAI Platform, remove hardcoded default signing
keys. Permit local development only through an explicit opt-in that creates
an ephemeral per-process secret, and add comments that it is not valid for
shared or network-reachable environments.
9. Add regression tests that do not use production credentials:
- missing `PLATFORM_JWT_SECRET` fails closed;
- the public default secret is rejected;
- test-only explicit dev mode uses an ephemeral secret;
- tokens signed with the old default are rejected after rotation;
- logs and validation errors never include the secret value or bearer token.
10. Add operator cleanup:
- restart all API instances after secret rotation;
- invalidate existing JWT sessions where the platform supports it;
- rotate any weak, shared, or default-derived platform secret;
- review workspace membership, admin, issue, project, agent, and audit logs
for suspicious activity during the exposure window.
11. Add a PR body section named `CVE-2026-47410 operator actions` that states:
- PraisonAI Platform versions before and after;
- every deployment surface reviewed;
- how `PLATFORM_JWT_SECRET` is provided without exposing the value;
- whether the public default, missing secret, or shared secret was present;
- how existing JWTs are invalidated or why manual logout is required;
- which logs and tenant-impact indicators operators must review.
12. Run relevant validation: dependency install, lockfile checks, unit tests,
auth startup tests, deployment-template rendering, container build, SBOM
refresh, dependency/security scans, and non-secret smoke checks available
in this repository.
13. Use PR title:
`fix(sec): remediate CVE-2026-47410 in PraisonAI Platform auth`.
## Stop conditions
- No affected PraisonAI Platform runtime, package pin, image, or deployment is
controlled by this repository.
- A fixed `praisonai-platform` version cannot be consumed without a broader
platform migration.
- Production token invalidation or secret rotation requires an operator change
window that the agent cannot schedule.
- The only affected runtime is supplied by an external platform owner; document
the owner, required version, and required secret contract in `TRIAGE.md`.
- Verification would require forging tokens against a live service, printing
secrets, or querying tenant data.
- Validation fails for unrelated pre-existing reasons; document those failures
instead of broadening scope.
Verification - what the reviewer looks for
- No controlled lockfile, image, SBOM, or deployment target resolves
praisonai-platformto0.1.2or earlier. - Runtime manifests require
PLATFORM_JWT_SECRETfrom a secret source and do not commit or bake the value. - Missing or public-default JWT secrets fail closed before the API accepts requests.
- Tests reject the default secret and prove logs do not disclose secrets or bearer tokens.
- Operator actions cover JWT invalidation, service restarts, secret rotation, and audit-log review.
Watch for
- Updating
praisonai-platformbut leaving old images, generated lockfiles, or SBOMs pinned to vulnerable versions. - Setting only
PLATFORM_ENV=productionwhile leaving the JWT secret absent, weak, or shared. .env.example, Helm values, Compose files, docs, or tutorials that still suggest the public default.- Secrets generated during image build instead of injected at runtime.
- Reusing one JWT secret across development, staging, and production.
- Allowing internet-reachable “dev” deployments to use ephemeral or test-only auth behavior.
- Rotating the secret without invalidating tokens or restarting every API instance.
Output contract
Return one of:
- A reviewer-ready PR/change request that upgrades every controlled
praisonai-platformruntime to0.1.4+, wiresPLATFORM_JWT_SECRETfrom a strong runtime secret source, rejects missing or public defaults before serving requests, adds regression tests, refreshes artifacts, and documents token invalidation and operator cleanup. TRIAGE.mdwhen no affected runtime, package pin, image, deployment, auth wrapper, or dependency is controlled by the repository.
The output must list versions, deployment surfaces reviewed, how the secret is
provided without disclosure, default/missing/shared-secret status, token
invalidation plan, service restart requirements, validation commands, and logs
to review. It must not print secrets, decode live tokens into logs, forge
production tokens, or treat PLATFORM_ENV=production alone as a fix.
Related recipes
- CVE-2026-47416 - PraisonAI Platform workspace owner promotion
- a separate workspace RBAC flaw in the same package family. Do not treat the JWT secret rotation as sufficient coverage for member-to-owner escalation.
References
- GitHub Advisory: https://github.com/advisories/GHSA-3qg8-5g3r-79v5
- NVD CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-47410
- Tenable CVE summary: https://www.tenable.com/cve/CVE-2026-47410
- PraisonAI project: https://github.com/MervinPraison/PraisonAI