CVE-2026-60091: PraisonAI SSRF — HIGH

CISO Take

PraisonAI's Jobs API lets any unauthenticated caller submit a job with a webhook_url that is checked once at request time but re-resolved via DNS at connection time, so an attacker with a short-TTL DNS record can point the callback at an internal address after the initial check passes — classic TOCTOU SSRF via DNS rebinding. It requires no credentials, no user interaction, and only network access (CVSS 7.2, AV:N/AC:L/PR:N/UI:N), so the barrier to attempt exploitation is essentially zero for any PraisonAI Jobs API endpoint reachable from outside its trust boundary. There's no EPSS score, no CISA KEV listing, no public exploit code, and no Nuclei template yet, so this looks pre-weaponized rather than under active attack today — but blind SSRF against agent orchestration hosts is a well-worn technique to reach cloud metadata services (e.g. AWS IMDS) and internal admin APIs. Upgrade to PraisonAI 4.6.78 or later immediately; until then, block egress from the PraisonAI host to link-local (169.254.169.254) and RFC1918 ranges at the network layer, since an in-app allowlist check alone can be bypassed by rebinding. Detection: flag outbound connections from the Jobs API process to internal IP ranges or metadata endpoints that don't match the originally-validated webhook_url hostname.

Sources: NVD GitHub Advisory VulnCheck CISA KEV ATLAS

What is the risk?

High exploitability (unauthenticated, network-reachable, low complexity, no user interaction) but currently blind/low-signal impact (CVSS scope changed with only low confidentiality/integrity, no availability impact) since there's no confirmed data-exfiltration path documented, no EPSS score, no CISA KEV entry, and no public exploit or scanner template. Real-world risk hinges heavily on deployment exposure: any organization running the PraisonAI Jobs API on a network-reachable host (especially in cloud environments with an accessible instance metadata service) faces meaningful pivot risk despite the 'blind' label, because SSRF against cloud metadata endpoints routinely escalates to full credential theft. Treat as high-priority patch-now given the trivial attacker effort, even though there is no evidence of in-the-wild exploitation yet.

How does the attack unfold?

Entry point

Attacker submits a job via the unauthenticated POST /api/v1/runs endpoint with a webhook_url pointing to an attacker-controlled domain configured with a short DNS TTL.

AML.T0049

Initial validation bypass

PraisonAI validates the webhook_url at request time, when the domain still resolves to a benign, allowed IP address.

DNS rebinding

The attacker flips the domain's DNS record to an internal address (e.g. cloud metadata service or internal admin API) before the job completes.

Blind SSRF impact

When PraisonAI fires the webhook callback, it connects to the newly-resolved internal address instead, giving the attacker a blind channel to internal services and potential credential exposure.

Entry point

Attacker submits a job via the unauthenticated POST /api/v1/runs endpoint with a webhook_url pointing to an attacker-controlled domain configured with a short DNS TTL.

AML.T0049

Initial validation bypass

PraisonAI validates the webhook_url at request time, when the domain still resolves to a benign, allowed IP address.

DNS rebinding

The attacker flips the domain's DNS record to an internal address (e.g. cloud metadata service or internal admin API) before the job completes.

Blind SSRF impact

When PraisonAI fires the webhook callback, it connects to the newly-resolved internal address instead, giving the attacker a blind channel to internal services and potential credential exposure.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
PraisonAI	pip	—	No patch
1 dependents 69% patched ~12d to patch Full package profile →

Do you use PraisonAI? You're affected.

How severe is it?

CVSS 3.1

7.2 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 22% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Changed

C Low

I Low

A None

What should I do?

1 step

1) Upgrade to PraisonAI >= 4.6.78 immediately. 2) Until patched, restrict network egress from the host running the Jobs API so it cannot reach 169.254.169.254 (cloud metadata), RFC1918 private ranges, or other internal-only services — this defeats rebinding regardless of app-level validation timing. 3) If feasible, disable or gate the webhook_url feature (require it be pre-registered/allowlisted out-of-band rather than user-supplied per request). 4) Monitor outbound connection logs from the Jobs API process for destination IPs that don't match the originally validated hostname's first-resolved IP — a mismatch is a strong rebinding indicator. 5) Consider a forward proxy that resolves DNS once and pins the IP for the lifetime of the webhook connection (resolve-and-pin), which is the structural fix for TOCTOU SSRF.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable Yes

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data Leakage Auth Bypass Agent API AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

MEASURE 2.7 - AI system security and resilience are evaluated and documented

OWASP LLM Top 10

LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-60091?

PraisonAI's Jobs API lets any unauthenticated caller submit a job with a webhook_url that is checked once at request time but re-resolved via DNS at connection time, so an attacker with a short-TTL DNS record can point the callback at an internal address after the initial check passes — classic TOCTOU SSRF via DNS rebinding. It requires no credentials, no user interaction, and only network access (CVSS 7.2, AV:N/AC:L/PR:N/UI:N), so the barrier to attempt exploitation is essentially zero for any PraisonAI Jobs API endpoint reachable from outside its trust boundary. There's no EPSS score, no CISA KEV listing, no public exploit code, and no Nuclei template yet, so this looks pre-weaponized rather than under active attack today — but blind SSRF against agent orchestration hosts is a well-worn technique to reach cloud metadata services (e.g. AWS IMDS) and internal admin APIs. Upgrade to PraisonAI 4.6.78 or later immediately; until then, block egress from the PraisonAI host to link-local (169.254.169.254) and RFC1918 ranges at the network layer, since an in-app allowlist check alone can be bypassed by rebinding. Detection: flag outbound connections from the Jobs API process to internal IP ranges or metadata endpoints that don't match the originally-validated webhook_url hostname.

Is CVE-2026-60091 actively exploited?

No confirmed active exploitation of CVE-2026-60091 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-60091?

1) Upgrade to PraisonAI >= 4.6.78 immediately. 2) Until patched, restrict network egress from the host running the Jobs API so it cannot reach 169.254.169.254 (cloud metadata), RFC1918 private ranges, or other internal-only services — this defeats rebinding regardless of app-level validation timing. 3) If feasible, disable or gate the webhook_url feature (require it be pre-registered/allowlisted out-of-band rather than user-supplied per request). 4) Monitor outbound connection logs from the Jobs API process for destination IPs that don't match the originally validated hostname's first-resolved IP — a mismatch is a strong rebinding indicator. 5) Consider a forward proxy that resolves DNS once and pins the IP for the lifetime of the webhook connection (resolve-and-pin), which is the structural fix for TOCTOU SSRF.

What systems are affected by CVE-2026-60091?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, agent orchestration/job pipelines, webhook/callback integrations.

What is the CVSS score for CVE-2026-60091?

CVE-2026-60091 has a CVSS v3.1 base score of 7.2 (HIGH). The EPSS exploitation probability is 0.30%.

What is the AI security impact?

Affected AI Architectures

agent frameworksagent orchestration/job pipelineswebhook/callback integrations

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

PraisonAI before 4.6.78 contains an unauthenticated server-side request forgery vulnerability in the Jobs API /api/v1/runs endpoint. The webhook_url parameter is validated at request time but re-resolved at connection time, allowing attackers to use DNS rebinding to reach internal services with a blind SSRF attack.

Exploitation Scenario

An attacker submits a job to POST /api/v1/runs with webhook_url set to a domain they control, configured with a very short DNS TTL. At request time, that domain resolves to a benign/allowed public IP, so PraisonAI's validation passes. Before the job completes and the actual webhook callback fires, the attacker flips the DNS record to resolve to an internal address such as the cloud provider's instance metadata endpoint (169.254.169.254) or an internal admin service. When PraisonAI issues the callback, it connects to the newly-resolved internal IP instead of the originally-validated one, sending its callback payload (and potentially reflecting response data back through job status/logs) to the internal target — giving the attacker a blind but reliable channel into the internal network, including potential IAM credential theft from cloud metadata.

Weaknesses (CWE)

CWE-918 Server-Side Request Forgery (SSRF) Primary CWE-918 Server-Side Request Forgery (SSRF)

CWE-918 — Server-Side Request Forgery (SSRF): The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

Source: MITRE CWE corpus.