🛡️ CVE-2026-57127 — praisonai
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_keyis 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-333—APIKeyAuthMiddleware.dispatchsilent-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
Details
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Affected Packages
| Software | From version | Fixed in |
|---|---|---|
| praisonai | — | 4.6.59 |
References
Similar Threats
- Medium CVE-2026-40112
- High CVE-2026-40113
- High CVE-2026-40114
- Critical CVE-2026-39888
- High CVE-2026-39889
More CVE 2026 advisories
Browse all of CVE 2026 in the advisory index.
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.