GHSA-63v4-w882-g4x2: PraisonAI: HTTPApproval dashboard renders tool arguments as raw HTML, allowing approval-page XSS to approve dangerous tools
HTTPApproval dashboard renders tool arguments as raw HTML, allowing approval-page XSS to approve dangerous toolsSummary`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 VersionsProposed 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.ImpactAn 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 BehaviorPraisonAI 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 CauseIn `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`.ReproductionThe 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.Expected affected output includes:The relevant injected argument shape is:The shell prefix demonstrates that the same argument can be executable shell
syntax after approval; the PoV stops before executing the tool.Suggested FixEscape every untrusted value before inserting it into the approval HTML:`tool_name``risk_level``agent_name`every argument keyevery argument valueFor 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: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.
CVSS v3.1: 8.8