PraisonAI EUVD-2026-108873

Requires all of the following: the deployment uses praisonai.bots.DiscordApproval as the human-approval control for dangerous tools (e.g. shell commands, file writes/deletes, deployments); a high-risk tool call is pending and the approval prompt has already been posted to the configured channel; and the attacker has write access to that specific configured Discord approval channel. The attacker then posts any message classified as approval (such as 'yes') that is NOT a reply, thread message, interaction callback, or request-bound token. LIMITING FACTORS: this only affects installs using the Discord messaging approval backend (versions >= 4.5.2 and <= 4.6.58) where channel membership is broader than approval authority; it needs a pending request and channel-post permission (so it is not anonymous/unauthenticated); and the realized confidentiality/integrity/availability impact is bounded by which tools the agent actually exposes behind approval. The advisory also notes the Slack and Telegram backends lack an explicit approver allowlist, but those are better request-scoped (Slack via conversations.replies thread, Telegram via callback/reply message_id); the report-grade issue is the Discord unthreaded channel cross-talk.

Signals point to a genuine but scope-limited priority rather than a widespread emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, 8.8) is internally consistent with the advisory's own rationale: a networked Discord channel (AV:N), trivial action of posting 'yes' (AC:L), low privilege of channel-post permission (PR:L), and no victim interaction (UI:N). PR:L confirms this is an authenticated issue - the attacker must be able to post in the configured approval channel, so it is not fully unauthenticated. CWE-863 (incorrect authorization) / CWE-345 (insufficient authenticity verification) correctly frame this as an authorization-binding design flaw, not memory corruption. No EPSS score was provided and the issue is NOT in CISA KEV, so there is no evidence of active exploitation; a public PoC reference exists in the advisory but it is a local, mock-based proof-of-vulnerability, not verified as a working remote exploit. The vuln.today Decision label is 'this_week' (not act_now/emergency), aligning with a patch-promptly posture. Real-world risk is gated by three conditions that must all hold: the deployment must use the DiscordApproval backend for dangerous tools, an approval request must be pending, and the approval channel must have membership broader than approval authority - which makes exploitation opportunistic/targeted rather than internet-wide. EPSS is absent, so probability of broad exploitation cannot be quantified; treat the niche footprint as the main mitigating factor.

An organization runs a PraisonAI agent that gates shell commands or file operations behind DiscordApproval in a shared team channel. When the agent posts an approval request for a dangerous command, any member of that channel - not just a designated approver - replies 'yes', and the backend accepts this unrelated, unbound message as the approval decision, causing the privileged tool to execute. The advisory includes a local mock-based PoV demonstrating that an intruder's later 'yes' message is accepted (approver='D_INTRUDER'); it stops at the approval decision and does not run the tool.