CVE-2026-55537: PraisonAI SSRF Vulnerability

CVE-2026-55537 Overview

CVE-2026-55537 affects PraisonAI, a multi-agent teams orchestration framework. The vulnerability exists in JobSubmitRequest.validate_webhook_url() in versions prior to 4.6.58. The validator accepts a webhook_url when DNS resolution raises socket.gaierror, because the exception handler silently passes. JobExecutor._send_webhook() later performs a fresh DNS lookup at send time. This time-of-check to time-of-use (TOCTOU) gap enables DNS rebinding, allowing attackers to redirect webhook requests toward internal services. The issue is classified under CWE-367: Time-of-check Time-of-use Race Condition.

Critical Impact
An authenticated attacker can trigger server-side requests to internal infrastructure by controlling DNS responses between validation and execution, bypassing intended webhook URL restrictions.

Affected Products

PraisonAI versions prior to 4.6.58
Deployments exposing the PraisonAI job submission API
Multi-agent workflows using webhook callbacks

Discovery Timeline

2026-08-25 - CVE-2026-55537 published to NVD
2026-08-25 - Last updated in NVD database

Technical Details for CVE-2026-55537

Vulnerability Analysis

The vulnerability is a Server-Side Request Forgery (SSRF) enabled by a time-of-check to time-of-use flaw. PraisonAI attempts to validate that webhook_url resolves to a permitted destination before accepting a job. The validation logic in JobSubmitRequest.validate_webhook_url() wraps the DNS resolution in a try block with except socket.gaierror: pass. When resolution fails, the exception is swallowed and the URL is accepted as valid.

Later, JobExecutor._send_webhook() performs a second DNS lookup when the outbound request is actually issued. An attacker controlling the domain's authoritative DNS server can return NXDOMAIN or a resolution error during validation, then return an internal IP address such as 169.254.169.254 or 127.0.0.1 during the send step. The result is a webhook delivered to cloud metadata endpoints, internal admin APIs, or other services reachable from the PraisonAI host.

Root Cause

The root cause is the silent handling of socket.gaierror combined with two independent DNS lookups against attacker-controlled records. Validation and use are not bound to the same resolved address, violating the assumption that the destination inspected at check time will match the destination contacted at use time.

Attack Vector

Exploitation requires network access to the job submission endpoint and low privileges to submit a job. The attacker hosts a domain whose DNS responses vary between requests, either by returning errors, low TTLs, or rotating answers. Successful exploitation causes internal HTTP requests to be issued by the PraisonAI server with confidentiality impact on any service that trusts source-local requests.

The upstream fix in commit 2f9677a hardens input validation and query parameterization across the codebase. Related defensive changes include stricter identifier sanitization:

python

@staticmethod
def _sanitise_user_id(user_id: str) -> str:
    """Reject path traversal in user_id before using it as a directory name."""
    if not user_id or not isinstance(user_id, str):
        return "default"
    if ".." in user_id or "/" in user_id or "\\" in user_id:
        raise ValueError("user_id must not contain path separators or parent references")
    safe = user_id.strip()
    return safe or "default"

Source: PraisonAI commit 2f9677a

Detection Methods for CVE-2026-55537

Indicators of Compromise

Outbound HTTP requests from PraisonAI hosts to link-local or private address ranges such as 169.254.169.254, 127.0.0.0/8, 10.0.0.0/8, or 172.16.0.0/12.
Job submissions containing webhook_url values whose domains resolve with unusually low TTLs or return NXDOMAIN on repeat queries.
Repeated webhook deliveries to the same hostname resolving to different IP families or address classes within short intervals.

Detection Strategies

Log every DNS resolution performed by validate_webhook_url() and _send_webhook() and alert when the two lookups for the same job return different addresses.
Inspect application logs for stack traces or handled socket.gaierror events tied to webhook validation.
Correlate PraisonAI outbound traffic with the destination approved at job submission time to identify divergence.

Monitoring Recommendations

Enforce egress filtering that blocks PraisonAI workers from reaching RFC1918 ranges, link-local addresses, and cloud metadata endpoints.
Capture and retain webhook delivery logs including the resolved IP address at send time.
Alert on any attempt by the PraisonAI process to establish connections to loopback or metadata IPs.

How to Mitigate CVE-2026-55537

Immediate Actions Required

Upgrade PraisonAI to version 4.6.58 or later, which contains the fix referenced in GHSA-rg5q-pp8p-f7jm.
Restrict who can submit jobs to the PraisonAI API and require authentication on all endpoints.
Deploy egress network controls that prevent PraisonAI hosts from contacting internal management planes and cloud metadata services.

Patch Information

The fix is available in PraisonAI v4.6.58. The corresponding commit 2f9677a hardens input validation across memory and server modules. Review the security advisory for full remediation details.

Workarounds

Deploy an outbound proxy that resolves DNS once and enforces an allowlist of external webhook destinations.
Configure host firewalls to block connections from the PraisonAI process to private, loopback, and link-local networks.
Disable webhook functionality entirely until the patched version can be deployed.

bash

# Pin PraisonAI to the patched release
pip install --upgrade 'praisonai>=4.6.58'

# Verify installed version
python -c "import praisonai; print(praisonai.__version__)"

# Example egress restriction using iptables to block metadata endpoint
iptables -A OUTPUT -m owner --uid-owner praisonai -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner praisonai -d 127.0.0.0/8 -j REJECT