CVE-2026-57114: PraisonAI: SSRF via webhook DNS rebinding bypass

HIGH

Published October 23, 2026

CISO Take

PraisonAI's Async Jobs API validates the webhook URL when a job is submitted, but not when the webhook is actually sent, so an attacker can use a hostname that resolves to a public IP at validation time and to loopback, private, or cloud-metadata addresses at delivery time (DNS rebinding, a TOCTOU flaw). This bypasses the earlier SSRF fix (GHSA-8frj-8q3m-xhgm), so deployments that patched that issue are still exposed. It is rated high (CVSS 7.2) and needs no authentication or user interaction, which matters for any instance that exposes the jobs API to untrusted networks. There is no EPSS score, no KEV listing, no public exploit and no Nuclei template, so current exploitation likelihood looks low, but DNS rebinding is a well-understood technique and agent hosts often run with cloud credentials. Upgrade PraisonAI to 4.6.59 or later, and restrict egress from agent hosts to the metadata service and internal ranges until you have done so.

Sources:NVDGitHub AdvisoryATLAS

What is the risk?

Rated high (CVSS 7.2) with scope change: the vulnerable component is the PraisonAI job service, but the impact lands on other internal services. The network attack vector, low complexity and no required privileges or user interaction make it simple to trigger against any exposed instance. Confidentiality and integrity impacts are rated low because the webhook is a POST with limited response visibility, but reaching cloud metadata endpoints (e.g. 169.254.169.254) or internal admin APIs could still lead to credential exposure or internal state changes. No known in-the-wild exploitation, no public PoC, and no EPSS data are available (confidence: MEDIUM, based on the vendor advisory and NVD description only). The patch bypass nature means previously 'fixed' systems may be wrongly assumed safe. Real exposure depends on whether the Async Jobs API is reachable by untrusted callers.

How does the attack unfold?

Initial Access

Attacker submits an async job to an exposed PraisonAI instance with a webhook_url on a domain they control that resolves to a public IP.

AML.T0049

Validation Bypass

The URL passes both parse-time and Job-construction validation because the hostname resolves to a public address at that moment.

DNS Rebinding

When the job completes, _send_webhook() re-resolves the hostname, which now points to loopback, private, or metadata IPs.

Impact

The agent host sends the request to internal services or cloud metadata, enabling internal probing and potential credential exposure.

AML.T0075

Initial Access

Attacker submits an async job to an exposed PraisonAI instance with a webhook_url on a domain they control that resolves to a public IP.

AML.T0049

Validation Bypass

The URL passes both parse-time and Job-construction validation because the hostname resolves to a public address at that moment.

DNS Rebinding

When the job completes, _send_webhook() re-resolves the hostname, which now points to loopback, private, or metadata IPs.

Impact

The agent host sends the request to internal services or cloud metadata, enabling internal probing and potential credential exposure.

AML.T0075

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
PraisonAI	pip	—	No patch
1 dependents61% patched~23d to patchFull 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 18% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AVNetwork

ACLow

PRNone

UINone

SChanged

CLow

ILow

ANone

What should I do?

1 step

1) Upgrade PraisonAI to 4.6.59 or later. 2) If you cannot upgrade, disable or block access to the Async Jobs API, or require authentication in front of it via a reverse proxy. 3) Enforce egress filtering on agent hosts to deny access to loopback, RFC1918, link-local (169.254.0.0/16) and metadata addresses. 4) Enforce IMDSv2 with hop limit 1 on cloud instances, or disable the metadata service where not needed. 5) Detect: review job submissions for webhook_url hostnames with very short DNS TTLs or that resolve differently over time, and alert on outbound requests from the PraisonAI process to internal or metadata IPs. 6) Review GHSA-rjvw-7vvw-549v for the vendor guidance.

How is it classified?

Auth BypassData LeakageFrameworkAgentAPIAML.T0049- Exploit Public-Facing Application AML.T0055- Unsecured Credentials AML.T0075- Cloud Service Discovery

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Responses to previously unknown risks are followed

OWASP LLM Top 10

LLM06-Excessive Agency

Frequently Asked Questions

What is CVE-2026-57114?

Is CVE-2026-57114 actively exploited?

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

How to fix CVE-2026-57114?

1) Upgrade PraisonAI to 4.6.59 or later. 2) If you cannot upgrade, disable or block access to the Async Jobs API, or require authentication in front of it via a reverse proxy. 3) Enforce egress filtering on agent hosts to deny access to loopback, RFC1918, link-local (169.254.0.0/16) and metadata addresses. 4) Enforce IMDSv2 with hop limit 1 on cloud instances, or disable the metadata service where not needed. 5) Detect: review job submissions for webhook_url hostnames with very short DNS TTLs or that resolve differently over time, and alert on outbound requests from the PraisonAI process to internal or metadata IPs. 6) Review GHSA-rjvw-7vvw-549v for the vendor guidance.

What systems are affected by CVE-2026-57114?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-agent orchestration, async job/webhook pipelines, cloud-hosted AI agent deployments.

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

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

What is the AI security impact?

Affected AI Architectures

agent frameworksmulti-agent orchestrationasync job/webhook pipelinescloud-hosted AI agent deployments

MITRE ATLAS Techniques

AML.T0049Exploit Public-Facing Application

AML.T0055Unsecured Credentials

AML.T0075Cloud Service Discovery

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

PraisonAI is a multi-agent teams system. From version 4.5.126 to before version 4.6.59, PraisonAI's Async Jobs API validates webhook_url when a job request is parsed and again when the internal Job object is constructed. That validation blocks direct loopback/private targets, but it is not bound to the later network request. When a job completes, _send_webhook() passes the original hostname to httpx.AsyncClient.post() with no send-time validation, IP pinning, or guarded transport. An attacker-controlled hostname can therefore resolve to a public IP during Pydantic validation and later resolve to loopback/private/cloud-metadata infrastructure during webhook delivery. This bypasses the intended SSRF guard in current supported releases. This appears to be an incomplete fix / patch bypass for GHSA-8frj-8q3m-xhgm. This issue has been patched in version 4.6.59.

Exploitation Scenario

An attacker controls a domain with an authoritative DNS server that answers with a public IP and a very short TTL on the first lookup. They submit an async job to an exposed PraisonAI instance with webhook_url pointing to that domain. Validation passes because the hostname resolves to a public address. When the job completes, PraisonAI's _send_webhook() resolves the hostname again, and the attacker's DNS now returns 169.254.169.254 or an internal service address. The agent host sends the webhook POST to the internal target, letting the attacker probe internal services or trigger actions on cloud metadata or admin endpoints reachable from the host.

Weaknesses (CWE)

CWE-367Time-of-check Time-of-use (TOCTOU) Race ConditionPrimary CWE-918Server-Side Request Forgery (SSRF)Primary CWE-367Time-of-check Time-of-use (TOCTOU) Race Condition CWE-918Server-Side Request Forgery (SSRF)

CWE-367 — Time-of-check Time-of-use (TOCTOU) Race Condition: The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check.

[Implementation] The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check.
[Implementation] When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement.

Source: MITRE CWE corpus.