🛡️ CVE-2026-57127 — praisonai

🔴 CVSS 9.5 — Critical ✅ No Known Exploit CWE-1188 OSV
9.5
CVSS Score
0 Low4 Medium7 High9 Critical10

Description

praisonai: recipe serve auth middleware silently disables itself when no secret is set

# praisonai: recipe serve authentication middleware silently disables itself when no secret is set

Researcher: Kai Aizen — SnailSploit (@SnailSploit), Adversarial & Offensive Security Research

Target: https://github.com/MervinPraison/PraisonAI

Package: praisonai on PyPI

Version tested: 4.6.48.

File: praisonai/recipe/serve.py (sha256 491bf8f29e399418260810ba4bf0f6802c6e4aa675628e2be68a9726c15d9b23).

TL;DR

praisonai/recipe/serve.py:312-410 defines two auth middlewares (APIKeyAuthMiddleware, JWTAuthMiddleware). Both contain the same "fail open when the secret is unset" branch at the top of their dispatch:

```python

async def dispatch(self, request, call_next):

if request.url.path == "/health":

return await call_next(request)

expected_key = api_key or os.environ.get("PRAISONAI_API_KEY")

if not expected_key:

# No key configured, allow request

return await call_next(request)

...

```

```python

async def dispatch(self, request, call_next):

if request.url.path == "/health":

return await call_next(request)

secret = jwt_secret or os.environ.get("PRAISONAI_JWT_SECRET")

if not secret:

return await call_next(request)

...

```

The realistic mis-deploy:

1. operator sets auth: api-key (or auth: jwt) in their recipe YAML, expecting that line alone to enable auth,

2. operator does not set the corresponding api_key: / jwt_secret: value in the same YAML, AND

3. operator does not export PRAISONAI_API_KEY / PRAISONAI_JWT_SECRET in the environment.

The middleware silently treats every request as authenticated and forwards it to the recipe-execution route.

Combined with the praisonai jobs API having zero auth (a separate finding), operators who paid attention to "I have to set auth: api-key to lock this down" still don't get auth on the recipe-serve surface unless they also remember the secret.

Root cause

```

Expected behavior, after setting auth: api-key in the recipe YAML:

"Now my recipe endpoints require an X-API-Key header."

Actual behavior (serve.py:325-333):

  • middleware reads `expected_key = api_key or

os.environ.get("PRAISONAI_API_KEY")`

  • if expected_key is None (neither YAML nor env supplied

one), middleware logs nothing and forwards the request.

  • operator's recipe routes accept the request as if it were

authenticated. request.state.user is unset.

Impact:

The middleware's documented job is "validate the API key

against the configured value". The configured-value-is-None

case is exactly the case the middleware should fail closed

on — operator has signalled they want auth. Failing open

silently turns a documented authentication into a runtime

no-op.

```

Empirical verification

poc/poc.py:

1. Imports the installed praisonai 4.6.48 praisonai.recipe.serve module (sha256 491bf8f29e399418260810ba4bf0f6802c6e4aa675628e2be68a9726c15d9b23).

2. Clears PRAISONAI_API_KEY / PRAISONAI_JWT_SECRET env vars to simulate the mis-deploy.

3. Calls serve.create_auth_middleware('api-key', api_key=None, jwt_secret=None) and instantiates the returned middleware.

4. Builds a Starlette Request for /runs (the recipe-execution path) with empty headers — no X-API-Key, no Authorization.

5. await middleware.dispatch(request, fake_call_next) returns the sentinel 'REACHED-DOWNSTREAM (path=/runs)' from the fake call_next — proving the middleware passed the request through without authenticating.

6. Repeats the test for auth_type='jwt' — same bypass on the JWT path.

Run log (poc/run-log.txt) summary:

```

[2] auth_type='api-key', no api_key / no PRAISONAI_API_KEY env

middleware.dispatch -> 'REACHED-DOWNSTREAM (path=/runs)'

[3] auth_type='jwt', no jwt_secret / no PRAISONAI_JWT_SECRET env

middleware.dispatch -> 'REACHED-DOWNSTREAM (path=/runs)'

APIKeyAuthMiddleware allowed the request through without an API key.

JWTAuthMiddleware allowed the request through without a Bearer token.

[4] grep '# No key configured, allow request' -> line 333

VERDICT: VULNERABLE

EXIT 0

```

Impact

The recipe-serve surface runs agentic workflows — same execution posture as praisonai/jobs/server.py but separately configured / separately reached. Unauth access on this surface yields:

  • Trigger arbitrary recipe executions, passing attacker-controlled inputs and configurations.
  • Read the inputs / outputs of in-flight recipes — the operator's prompts and the LLM responses.
  • In some deployments, the recipe execution surface is wired to tools (browser automation, file-system writes, code execution). Reaching those tools without auth is a direct RCE path.

Anchors

  • praisonai/recipe/serve.py:325-333APIKeyAuthMiddleware.dispatch silent-bypass branch.
  • praisonai/recipe/serve.py:352-355 — `JWTAuthMiddleware.

How this vulnerability can be exploited

This issue can be reached over the network, attack complexity is low, an attacker needs no privileges on the target. No user interaction is required. The scope is unchanged, so the impact stays within the vulnerable component. Rated impact: confidentiality high, integrity high, availability high.

Weakness class

CVE-2026-57127 is classified as CWE-1188: Insecure Default Initialization of Resource. Default settings are insecure, so an installation is exposed until someone changes them.

Affected software

CVE-2026-57127 is recorded against 1 package.

  • praisonai (fixed in 4.6.59)

Timeline and source

Published on 18 June 2026 and last revised on 23 July 2026. No public exploit is currently recorded for this entry. Record sourced from OSV.

References

github.com (Web)
github.com (Package)

Details

Severity CRITICAL
CVSS Score 9.5
CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE CWE-1188
Public Exploit ✅ No
Source OSV
Published 2026-06-18
Updated 2026-08-12
Modified 2026-07-23
Fix URL N/A

Affected Packages

Software From version Fixed in
praisonai 4.6.59

Similar Threats

Exploit Protection

Are you running praisonai?

CVE-2026-57127 carries CVSS 9.5 Critical rating. BotEraser checks your installation against this and other known CVE records, and blocks IPs associated with exploit activity.

Check My Site For CVE-2026-57127 →

No credit card required  ·  Results in minutes

ⓘ Data Notice: The information presented above has been compiled from publicly available internet sources. Boteraser aggregates this data solely for informational purposes and does not independently classify, evaluate, or endorse any findings about the vulnerabilities listed. The accuracy and completeness of this information is the sole responsibility of the original publishers. Boteraser and its operators accept no liability for any decisions made based on this data.