PraisonAI CVE-2026-56840

Requires the HTTPApproval (http) non-console approval backend to be configured and running (praisonai.bots.HTTPApproval) - this is not the documented default console backend. The attacker must be able to influence an agent task or prompt enough to make the agent emit a dangerous tool call (e.g. execute_command, execute_code, delete_file) whose argument carries the XSS payload. Exploitation only fires when a human approver opens the pending request's approval URL (UI:R) - the injected same-origin script derives the /approve/{request_id}/decide endpoint from location.pathname, so the unguessable request id does not stop it. Limiting factors: non-default http backend, dependence on attacker influence over agent inputs, and the requirement that an approver actually views the page; no dashboard authentication is required to deliver the payload. Fixed completely only by updating to 4.6.59 (the advisory also suggests html.escape on all untrusted values, avoiding inline JS, and a restrictive CSP).

The input CVSS of 8.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) rates this High: network-reachable, low complexity, no authentication to the dashboard, but requiring user interaction (UI:R) in the form of a human approver opening the approval page. The multi-source signals paint a more conditional picture than the raw score suggests. Positive priority signals: the vuln.today Decision label is 'this_week', a vendor patch exists (4.6.59), and the GHSA advisory ships a working local proof-of-vulnerability. Tempering signals: this is NOT in CISA KEV (no confirmed active exploitation), and no EPSS score was supplied, so exploitation-probability cannot be quantified from this data. Critically, exploitation is gated by three stacked preconditions - the HTTPApproval (http) backend must be deployed (console is the documented default), an attacker must be able to steer an agent task/prompt into emitting a dangerous tool call carrying the XSS payload, and a human must actually open the approval URL. This is therefore a genuine human-in-the-loop-bypass priority for anyone running the http approval backend, but closer to a targeted/conditional issue than a mass-exploitable internet-facing RCE. No SSVC exploitation/automatable/technical-impact decision values were provided to corroborate the 'this_week' label.

An attacker who can influence an agent's task or prompt causes the agent to emit a dangerous tool call (e.g. execute_command) whose argument embeds a short XSS payload. When a human approver opens the HTTPApproval dashboard URL to inspect the risky request, the injected script runs in the dashboard origin and auto-POSTs to /approve/{request_id}/decide, returning approved=True before the human clicks anything - bypassing the approval boundary. A local, non-executing proof-of-vulnerability is published in the GHSA advisory; given AV:N/AC:L, exploitation is low-complexity once the attacker controls a tool argument and an approver views the page.