PraisonAI vulnerable to Server-Side Request Forgery via DNS rebinding bypass in webhook_url validationGHSA-hmfx-4v44-9qw9
MEDIUMFix: MervinPraison/PraisonAI@2f9677aGHSA-hmfx-4v44-9qw9 is a medium-severity (CVSS 6.8) CWE-367 vulnerability in praisonai. A fix is available for praisonai — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-hmfx-4v44-9qw9.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-hmfx-4v44-9qw9 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 384,993 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
praisonaiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The webhook_url field in the Jobs API silently passes validation when DNS resolution fails (socket.gaierror), enabling DNS rebinding attacks. An attacker's domain can initially resolve to a public IP (passing validation) then switch to an internal IP before the server makes the HTTP request.
Details
The validator catches socket.gaierror and silently allows the URL:
# src/praisonai/praisonai/jobs/models.py:55
try:
ip = socket.gethostbyname(hostname)
ip_obj = ipaddress.ip_address(ip)
if ip_obj.is_private or ip_obj.is_loopback:
raise ValueError("private address")
except socket.gaierror:
pass # BUG: DNS failure silently ignored → SSRF bypass
The HTTP call is made later with no re-validation:
# src/praisonai/praisonai/jobs/executor.py:402
async with httpx.AsyncClient() as client:
await client.post(job.webhook_url, ...) # no second IP check
Proof of Concept
DNS rebinding flow:
- Register
attacker.comwith TTL=1s → resolves to1.2.3.4(public IP) - Submit job:
webhook_url=http://attacker.com/callback - Validation passes (public IP)
- Switch DNS:
attacker.com→127.0.0.1 - Job completes → server POSTs to
127.0.0.1→ internal SSRF
Unresolvable domain bypass (no DNS rebinding required):
curl -X POST http://:8005/api/v1/runs \
-d '{"prompt":"run","webhook_url":"http://unresolvable.internal/cb","agent_yaml":"..."}'
# Validation: gaierror → pass → URL accepted
Impact
SSRF to internal HTTP services: admin panels, databases, and cloud metadata APIs (e.g., http://169.254.169.254/). Exploitable without authentication.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | praisonai | all versions | 4.6.58pip install --upgrade 'praisonai==4.6.58' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for praisonai, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update praisonai to 4.6.58 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hmfx-4v44-9qw9 is resolved across your whole dependency graph.
Workarounds
Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.
Frequently Asked Questions
Is GHSA-hmfx-4v44-9qw9 in your dependencies?
Find it across PyPI, including transitive dependencies.