CVE-2026-55537: PraisonAI SSRF via race condition

CISO Take

PraisonAI's multi-agent framework validates a job's webhook_url at submission time, but silently swallows DNS resolution failures (socket.gaierror) instead of rejecting the request, and then resolves the hostname again — separately — when it actually fires the webhook. An attacker who can submit a job (only low privileges required, no user interaction) registers a domain that initially fails to resolve or points to a benign address, waits for the internal validation to pass, then flips the DNS record to an internal IP before the webhook fires, redirecting the callback into the victim's internal network. With only 1 known downstream dependent and no listed EPSS score, public exploit, or CISA KEV entry, this isn't showing signs of mass exploitation, but the high attack complexity is exactly what makes it attractive to a patient, targeted attacker probing an AI agent deployment for internal service access. Any organization running PraisonAI job/webhook workflows should upgrade to 4.6.58 immediately, and in the interim block outbound webhook traffic to RFC1918/link-local ranges at the network layer rather than relying on application-side DNS checks.

Sources:NVDGitHub AdvisoryATLAS

What is the risk?

Medium-high risk despite the high CVSS base score. Exploitability is nontrivial (AC:H, requires winning a TOCTOU race between validation-time and send-time DNS resolution, and requires the attacker to control an authoritative DNS record), but the impact of a successful SSRF is significant in agentic environments: confidentiality impact is High (internal service responses can be exfiltrated back through the webhook payload) with limited integrity impact and no availability impact per the vector. No evidence of active exploitation (not in CISA KEV), no public PoC, and no Nuclei template exist yet, so this should be treated as an urgent-but-not-emergency patch — prioritize over routine backlog items but don't treat as an active-incident trigger unless internal telemetry shows anomalous DNS flips tied to webhook configs.

How does the attack unfold?

Initial Access

Attacker with low-privilege job submission access registers a webhook_url domain that resolves benignly or fails resolution at validation time.

AML.T0049

Race Condition Setup

validate_webhook_url() silently ignores the DNS resolution failure (socket.gaierror: pass) and approves the job submission.

DNS Rebind / Exploitation

Before JobExecutor._send_webhook() executes, attacker updates the domain's DNS record to point to an internal-only address such as a cloud metadata endpoint.

AML.T0053

Impact

The fresh DNS lookup at send-time resolves to the internal address, and PraisonAI delivers the webhook payload to that internal service, enabling SSRF and potential internal data exposure.

Initial Access

Attacker with low-privilege job submission access registers a webhook_url domain that resolves benignly or fails resolution at validation time.

AML.T0049

Race Condition Setup

validate_webhook_url() silently ignores the DNS resolution failure (socket.gaierror: pass) and approves the job submission.

DNS Rebind / Exploitation

Before JobExecutor._send_webhook() executes, attacker updates the domain's DNS record to point to an internal-only address such as a cloud metadata endpoint.

AML.T0053

Impact

The fresh DNS lookup at send-time resolves to the internal address, and PraisonAI delivers the webhook payload to that internal service, enabling SSRF and potential internal data exposure.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
PraisonAI	pip	< 4.6.58	`4.6.58`
1 dependents61% patched~23d to patchFull package profile →
PraisonAI	pip	—	No patch
1 dependents61% patched~23d to patchFull package profile →

How severe is it?

CVSS 3.1

7.1 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 19% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○CISA SSVC: Public PoC

○Public PoC indexed (trickest/cve)

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?

AVNetwork

ACHigh

PRLow

UINone

SChanged

CHigh

ILow

ANone

What should I do?

1 step

1) Patch: Upgrade PraisonAI to >= 4.6.58 immediately, which fixes validate_webhook_url() to properly handle socket.gaierror instead of silently passing. 2) Workaround if patching is delayed: enforce webhook_url allowlisting at the application layer (only permit pre-registered, known-good destinations) rather than relying on DNS validation alone. 3) Network-layer defense-in-depth: block egress from the PraisonAI host/container to RFC1918, link-local (169.254.0.0/16, including cloud metadata IPs), and loopback ranges regardless of application logic — this closes the TOCTOU gap structurally. 4) Detection: monitor for webhook_url values whose resolved IP changes between job submission and job execution (DNS TTL anomalies), and alert on any successful webhook delivery to a private IP range. 5) Re-validate resolution atomically at send-time immediately before the connection is made (single lookup, single use) rather than trusting an earlier check.

What does CISA's SSVC say?

DecisionTrack*

Exploitationpoc

AutomatableNo

Technical Impactpartial

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

How is it classified?

Code ExecutionData LeakageAgentFrameworkAML.T0049- Exploit Public-Facing Application AML.T0053- AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.4-AI system verification and validation

NIST AI RMF

MANAGE-4.1-Risk monitoring and response for third-party/AI system components

OWASP LLM Top 10

LLM06-Excessive Agency / Insecure Output Handling

Frequently Asked Questions

What is CVE-2026-55537?

PraisonAI's multi-agent framework validates a job's webhook_url at submission time, but silently swallows DNS resolution failures (socket.gaierror) instead of rejecting the request, and then resolves the hostname again — separately — when it actually fires the webhook. An attacker who can submit a job (only low privileges required, no user interaction) registers a domain that initially fails to resolve or points to a benign address, waits for the internal validation to pass, then flips the DNS record to an internal IP before the webhook fires, redirecting the callback into the victim's internal network. With only 1 known downstream dependent and no listed EPSS score, public exploit, or CISA KEV entry, this isn't showing signs of mass exploitation, but the high attack complexity is exactly what makes it attractive to a patient, targeted attacker probing an AI agent deployment for internal service access. Any organization running PraisonAI job/webhook workflows should upgrade to 4.6.58 immediately, and in the interim block outbound webhook traffic to RFC1918/link-local ranges at the network layer rather than relying on application-side DNS checks.

Is CVE-2026-55537 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-55537, increasing the risk of exploitation.

How to fix CVE-2026-55537?

1) Patch: Upgrade PraisonAI to >= 4.6.58 immediately, which fixes validate_webhook_url() to properly handle socket.gaierror instead of silently passing. 2) Workaround if patching is delayed: enforce webhook_url allowlisting at the application layer (only permit pre-registered, known-good destinations) rather than relying on DNS validation alone. 3) Network-layer defense-in-depth: block egress from the PraisonAI host/container to RFC1918, link-local (169.254.0.0/16, including cloud metadata IPs), and loopback ranges regardless of application logic — this closes the TOCTOU gap structurally. 4) Detection: monitor for webhook_url values whose resolved IP changes between job submission and job execution (DNS TTL anomalies), and alert on any successful webhook delivery to a private IP range. 5) Re-validate resolution atomically at send-time immediately before the connection is made (single lookup, single use) rather than trusting an earlier check.

What systems are affected by CVE-2026-55537?

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

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

CVE-2026-55537 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.27%.

What is the AI security impact?

Affected AI Architectures

agent frameworksmulti-agent orchestrationwebhook/callback integrations

MITRE ATLAS Techniques

AML.T0049Exploit Public-Facing Application

AML.T0053AI Agent Tool Invocation

Compliance Controls Affected

ISO 42001: A.6.2.4

NIST AI RMF: MANAGE-4.1

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.58, JobSubmitRequest.validate_webhook_url() accepts webhook_url when resolution raises socket.gaierror because the exception path uses except socket.gaierror: pass. JobExecutor._send_webhook() later performs a fresh lookup, allowing DNS changes to direct the request to an internal service. This issue is fixed in version 4.6.58.

Exploitation Scenario

An attacker with low-privilege access to submit jobs to a PraisonAI multi-agent deployment registers a domain (e.g., attacker-ctrl.example.com) and sets its DNS record to a non-resolving or public IP. They submit a JobSubmitRequest with webhook_url pointing to this domain; validate_webhook_url() attempts resolution, gets socket.gaierror (or a benign public IP), and passes validation because failures are silently ignored. Before JobExecutor._send_webhook() fires — potentially seconds to minutes later depending on job runtime — the attacker updates the DNS record for attacker-ctrl.example.com to point to an internal address such as 169.254.169.254 (cloud metadata service) or an internal admin API. When the webhook fires, PraisonAI performs a fresh DNS lookup, resolves to the attacker-controlled internal IP, and sends the job result payload (potentially including agent outputs, credentials, or internal data) to that internal service — achieving SSRF and potential secondary data exposure or unauthorized internal API calls.

Weaknesses (CWE)

CWE-367Time-of-check Time-of-use (TOCTOU) Race ConditionPrimary CWE-367Time-of-check Time-of-use (TOCTOU) Race ConditionPrimary CWE-705Incorrect Control Flow ScopingPrimary CWE-705Incorrect Control Flow ScopingPrimary CWE-918Server-Side Request Forgery (SSRF)Primary CWE-918Server-Side Request Forgery (SSRF)Primary CWE-367Time-of-check Time-of-use (TOCTOU) Race Condition CWE-705Incorrect Control Flow Scoping 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.