PERMISSION/PROTOCOL
Back to incident tracker

2026-05-11

HighPrimary

PraisonAI CVE-2026-44338 — Auth disabled by default exposes agent workflows, scanned within 4 hours

PraisonAI shipped with authentication disabled by default, exposing agent workflows to any caller. Active scanning began within 4 hours of CVE disclosure.

PraisonAITool execution / MCPAuthentication bypass enabling unauthorized agent workflow executionPraisonAI Flask API server / agent workflow endpoints

What happened

Internet-exposed PraisonAI instances accepted unauthenticated GET /agents and POST /chat requests. POST /chat executed PraisonAI(agent_file='agents.yaml').run() for any caller regardless of message content. A DigitalOcean-hosted scanner confirmed the auth bypass on public instances within hours of CVE disclosure.

Why it matters

Any internet-exposed PraisonAI instance running versions 2.5.6–4.6.33 was vulnerable to unauthenticated workflow execution. Impact is bounded by what the configured agent workflow was authorized to do — which could include cloud API calls, file access, MCP tool execution, or data exfiltration.

Missing authorization check

The POST /chat workflow trigger should have required a valid auth token or signed receipt before executing any agent workflow. GET /agents should not have exposed agent configuration metadata to unauthenticated callers.

Would PP block it?

If PP wraps tool calls inside the PraisonAI workflow, those tool actions still require receipts regardless of how the workflow was triggered — providing coverage over what the agent does once running. However, PP's enforcement doesn't replace the missing API authentication layer. An unauthenticated POST /chat bypasses auth and enters the workflow directly. PP covers the tool-call surface inside the workflow; the workflow initiation itself requires API-layer authentication that PP doesn't provide.

Incident analysis

Timeline and technical read

Timeline

  1. 2026-05-11 13:56 UTC

    GitHub advisory GHSA-6rmh-7xcm-cpxj published, CVE-2026-44338 assigned. Affects PraisonAI 2.5.6–4.6.33 — every then-current PyPI release.

  2. 2026-05-11 17:32 UTC

    First contact from 146.190.133.49 (DigitalOcean): generic recon sweeping /.env, /admin, and common disclosure paths.

  3. 2026-05-11 17:40 UTC

    Scanner pivots to PraisonAI-specific endpoints. GET /agents returns 200 OK with agent configuration — auth bypass confirmed. Total time from advisory: 3h 44m 39s.

  4. 2026-05-11 17:41 UTC

    Second GET /agents probe from CVE-Detector/1.0. Scanner pattern: enumerate agent list, confirm bypass, log host as exploitable, move on.

  5. 2026-05-11

    PraisonAI 4.6.34 released, removing the legacy api_server.py entrypoint and introducing authentication protections.

Technical breakdown

  • The Flask api_server.py hardcoded AUTH_ENABLED = False and AUTH_TOKEN = None. check_auth() returned True unconditionally — the 'protected' routes failed open by design, not by accident.
  • POST /chat executed PraisonAI(agent_file='agents.yaml').run() for any caller. The message body was ignored; the configured workflow ran regardless of what the caller sent.
  • The real attack surface isn't the bypass — it's what the workflow is allowed to do. An agent with cloud credentials, file access, or MCP tool authority becomes fully accessible to any unauthenticated caller.
  • Sysdig observed a two-pass scanner pattern: pass 1 = generic recon, pass 2 = AI-agent endpoint enumeration including MCP paths. The pivot to AI-specific endpoints took under 10 minutes.
  • Sysdig TRT has observed this rapid exploitation pattern across multiple recent AI framework CVEs (Marimo, LMDeploy, Langflow) — 4-hour windows are now a baseline, not an outlier.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Tool execution / MCP. The relevant Permission Protocol gate is Runtime Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at
Tool-call authorization within agent workflow execution
Still needs
API server authentication layer — PP does not gate workflow initiation from unauthenticated HTTP callers
Receipt required for
Workflow execution trigger, any tool calls made by the agent during workflow execution

PP can gate individual tool calls executed within the running workflow, but does not sit at the HTTP API layer and cannot gate the workflow trigger itself if the API server has no authentication.

Start small

Put the relevant gate at this action boundary.

This incident maps to Runtime Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop