PraisonAI EUVD-2026-108890

The attacker must be able to reach the PraisonAI Async Jobs API (POST /api/v1/runs) and supply a chosen webhook_url, and must control authoritative DNS for that hostname so it resolves to a public, allowed IP during JobSubmitRequest/Job Pydantic validation and to a loopback/private/cloud-metadata address during the later _send_webhook() delivery (classic DNS-rebinding TOCTOU; the gethostbyname check is never bound to the httpx connection). The advisory states the Jobs API requires no authentication by default, so no credentials are needed unless the operator added deployment-level auth. Limiting factors that reduce real-world risk: the Jobs API must actually be exposed to the attacker; the attacker needs a controllable low-TTL DNS name; useful impact depends on internal/metadata services being reachable from the host and accepting POST requests; and the primitive is blind (no guaranteed response-body exfiltration).

This is a genuine but moderate-priority issue, not a drop-everything emergency. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N) describes an unauthenticated, network-reachable scope-changing flaw, and the vuln.today Decision label is 'this_week' rather than act_now/emergency. A full working local proof-of-concept is embedded in the GHSA-rjvw-7vvw-549v advisory (it prints 'PRAI-CAND-005 CONFIRMED'), so exploit knowledge is public, but there is no CISA KEV listing and no EPSS score in the supplied data, so widespread automated exploitation cannot be asserted. No SSVC decision record (exploitation/automatable/technical-impact) was provided. Two tempering factors matter: the impact is a blind SSRF primitive with only Low confidentiality and Low integrity (the reporter explicitly disclaims response-body disclosure, RCE, and credential theft absent deployment-specific internal services), and successful exploitation requires the attacker to control DNS for the webhook hostname and to perform a rebinding transition between Pydantic validation and httpx delivery. One data note: the stated score of 7.2 is slightly lower than the ~8.2 that the provided scope-changed vector normally computes - treat the numeric score as approximate and rely on the vector. Because this is an incomplete fix / patch bypass of the earlier GHSA-8frj-8q3m-xhgm SSRF, deployments that believed themselves patched remain exposed, which raises practical urgency for anyone exposing the Jobs API.

An attacker who can reach a PraisonAI Async Jobs API submits a job via POST /api/v1/runs with a webhook_url on a hostname they control. At validation time socket.gethostbyname() returns a benign public IP, passing the SSRF guard; by the time the job finishes and _send_webhook() calls httpx.AsyncClient.post(), the hostname re-resolves to loopback, a private address, or 169.254.169.254, so the PraisonAI host POSTs the job-result payload to internal or cloud-metadata endpoints. A full local proof-of-concept demonstrating this DNS-rebinding bypass is published in the GHSA advisory.