CVE-2026-57148: PraisonAI JWT Authentication Bypass Vulnerability

CVE-2026-57148 Overview

CVE-2026-57148 is a critical authentication bypass vulnerability in PraisonAI, a multi-agent teams system. Versions prior to 0.1.6 of praisonai-platform fall back to a public development HS256 signing key (dev-secret-change-me) when the PLATFORM_JWT_SECRET environment variable is unset. Startup and token-issuance guards are simultaneously disabled because PLATFORM_ENV also defaults to dev. An unauthenticated remote attacker can forge a JWT with an attacker-chosen sub claim, and AuthService._verify_token() accepts it as a valid authenticated identity. This weakness is classified under [CWE-287: Improper Authentication].

Critical Impact
Unauthenticated attackers can forge JWTs using the public dev secret and impersonate any user or workspace owner when the target identifier is known.

Affected Products

PraisonAI praisonai-platform versions prior to 0.1.6
Deployments relying on praisonai_platform/services/auth_service.py
Instances running with default PLATFORM_ENV=dev and unset PLATFORM_JWT_SECRET

Discovery Timeline

2026-09-15 - CVE-2026-57148 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-57148

Vulnerability Analysis

The vulnerability lives in praisonai_platform/services/auth_service.py. When PLATFORM_JWT_SECRET is not defined, the service falls back to the publicly known string dev-secret-change-me as the HS256 signing key. The platform's protective guards that normally block insecure startup and token issuance in production are gated on PLATFORM_ENV, which also defaults to dev. This combination produces a silent-insecure state where the platform accepts tokens signed with a secret any attacker can obtain from public source code.

Because JWT signature verification uses the same shared secret, an attacker can generate a valid token offline. AuthService._verify_token() treats the forged token as an authenticated principal and trusts the attacker-controlled sub claim as the user identifier. Impersonation of arbitrary users and workspace owners follows, granting confidentiality, integrity, and availability impact across tenants.

Root Cause

The root cause is insecure default configuration combined with hardcoded fallback credentials. The signing key defaults to a public constant, and the environment flag that should force secure defaults itself defaults to a development mode. There is no fail-closed behavior that rejects requests when a production-grade secret is missing.

Attack Vector

Exploitation is network-based and requires no authentication or user interaction. An attacker who knows or guesses a target sub value (for example, a workspace owner identifier) signs a JWT with the public dev secret and submits it in the Authorization header. The platform validates the signature against the same fallback secret and grants access under the impersonated identity.

No realCodeExamples of an exploit path are provided. Refer to the GitHub Security Advisory GHSA-f38v-77qj-h4jq and the remediation commit for the patched authentication logic.

Detection Methods for CVE-2026-57148

Indicators of Compromise

Authentication events using JWTs signed with the string dev-secret-change-me as HS256 key.
Requests to praisonai-platform API endpoints bearing tokens whose sub claim does not correspond to a legitimate login event.
Access to workspace or admin resources from source IPs that never completed the interactive login flow.

Detection Strategies

Inspect deployed configuration for PLATFORM_JWT_SECRET being unset and PLATFORM_ENV defaulting to dev in production hosts.
Correlate JWT issuance logs against session-establishment logs to surface tokens presented without a matching issue event.
Review AuthService._verify_token() audit logs for sub values that suddenly access resources outside prior behavioral patterns.

Monitoring Recommendations

Monitor process environment variables at deploy time to alert on missing PLATFORM_JWT_SECRET.
Alert on authentication success events immediately followed by cross-tenant or privilege-elevation actions.
Ingest PraisonAI application logs into a centralized analytics platform to run continuous queries for tokens signed with the known fallback secret.

How to Mitigate CVE-2026-57148

Immediate Actions Required

Upgrade praisonai-platform to version 0.1.6 or later, which hardens JWT secret handling per Pull Request #1793.
Set PLATFORM_JWT_SECRET to a cryptographically strong, unique value on every deployment before restarting the service.
Set PLATFORM_ENV=production to activate the startup and token-issuance guards.
Invalidate all previously issued JWTs by rotating the signing secret, forcing re-authentication for all users.

Patch Information

The fix is delivered in praisonai-platform0.1.6 and referenced in PraisonAI Release v4.6.51. The patch removes the insecure fallback key, fails startup when a strong secret is not provided in production, and additionally replaces unsafe eval() usage in bundled examples. See the remediation commit for full changes.

Workarounds

If upgrading immediately is not possible, explicitly export PLATFORM_JWT_SECRET with a strong random value and set PLATFORM_ENV=production before starting the service.
Restrict network access to the PraisonAI platform behind an authenticated reverse proxy until the upgrade is applied.
Revoke and reissue any JWTs that may have been generated while the dev fallback was active.

bash

# Configuration example: fail-closed secret handling before starting PraisonAI
export PLATFORM_ENV=production
export PLATFORM_JWT_SECRET="$(openssl rand -base64 48)"

# Verify the variables are set before launching the service
if [ -z "$PLATFORM_JWT_SECRET" ] || [ "$PLATFORM_ENV" != "production" ]; then
  echo "Refusing to start: PLATFORM_JWT_SECRET must be set and PLATFORM_ENV=production" >&2
  exit 1
fi

# Start the platform (example)
praisonai-platform serve