CVE-2026-55537: Webhook Server-Side Request Forgery and TOCTOU Bypass in PraisonAI

The PraisonAI framework provides coordination capabilities for multi-agent AI teams. To support asynchronous execution, the framework allows clients to submit jobs with an optional callback webhook URL. When a background job completes, the executor sends an HTTP POST request to the specified callback address. This interface exposes a network attack surface that must be restricted to prevent unauthorized requests targeting internal infrastructure.

To secure this callback interface, PraisonAI implements a Pydantic-based validation method named JobSubmitRequest.validate_webhook_url(). The method resolves the target hostname and blocks loopback, private, link-local, or multicast IP addresses. This validation was introduced to address previous SSRF concerns registered under CVE-2026-40114.

However, the validation mechanism contains an exception handling logic flaw. If a DNS lookup fails during the validation phase, the code silences the exception instead of rejecting the input. This design introduces a fail-open state, allowing an attacker to bypass the validation phase and subsequently exploit a time-of-check time-of-use (TOCTOU) condition during execution.

The root cause of CVE-2026-55537 is an incorrect control flow scope (CWE-705) combined with a TOCTOU race condition (CWE-367). Inside models.py, the validation function resolves hostnames using socket.gethostbyname(). If the hostname does not have an active or valid DNS record during validation, the call raises a socket.gaierror exception.

The validation method handles this exception with an explicit pass statement. By executing pass on a resolution failure, the function accepts the input URL as valid and returns it unmodified. This fail-open logic allows unresolvable domains to bypass the validation step completely.

When the job executor later finishes executing the agent tasks, it invokes JobExecutor._send_webhook(). This subsystem performs a fresh DNS lookup to dispatch the HTTP payload. Since the hostname is resolved a second time, an attacker can manipulate DNS state between the validation phase (check time) and the invocation phase (use time).

The flaw resides within src/praisonai/praisonai/jobs/models.py. The vulnerable code executes a silent pass when resolving the hostname of the webhook URL fails. Below is the technical comparison showing the vulnerable validation pattern versus the hardened implementation.

Vulnerable Implementation (Before v4.6.58)

# Vulnerable code in models.py
def validate_webhook_url(cls, v: Optional[str]) -> Optional[str]:
    if not v:
        return v
    import urllib.parse
    import socket
    import ipaddress
 
    try:
        parsed = urllib.parse.urlparse(v)
        hostname = parsed.hostname
        if not hostname:
            return v
        
        # Resolve hostname to check CIDR ranges
        ip_str = socket.gethostbyname(hostname)
        ip_obj = ipaddress.ip_address(ip_str)
        
        if ip_obj.is_private or ip_obj.is_loopback or ip_obj.is_link_local or ip_obj.is_multicast:
            raise ValueError("Webhook URL resolves to a private network address")
            
    except socket.gaierror:
        # BUG: Fails open if DNS resolution fails
        pass
        
    return v

Patched Implementation (v4.6.58)

# Corrected code in models.py (Commit: 2f9677abb2ea68eab864ee8b6a828fd0141612e1)
def validate_webhook_url(cls, v: Optional[str]) -> Optional[str]:
    if not v:
        return v
    import urllib.parse
    import socket
    import ipaddress
 
    try:
        parsed = urllib.parse.urlparse(v)
        hostname = parsed.hostname
        if not hostname:
            return v
        
        ip_str = socket.gethostbyname(hostname)
        ip_obj = ipaddress.ip_address(ip_str)
        
        if ip_obj.is_private or ip_obj.is_loopback or ip_obj.is_link_local or ip_obj.is_multicast:
            raise ValueError("Webhook URL resolves to a private network address")
            
    except socket.gaierror:
        # FIX: Fail-closed logic. Reject unresolvable hostnames.
        raise ValueError("Webhook URL hostname could not be resolved")
        
    return v

The patch replaces the passive pass handler with an explicit ValueError. This change ensures that any hostname that cannot be resolved immediately at registration is rejected, preventing the insertion of dynamic DNS bypass payloads.

To exploit this vulnerability, an attacker must control an authoritative DNS server and have job submission privileges on the PraisonAI server. The attack requires precise timing to control the response of the DNS resolver.

First, the attacker registers a domain name and configures their DNS server to return a failure status, such as a timeout or an empty NXDOMAIN response, for a specific subdomain like trigger.attacker.com.

Second, the attacker submits a job request payload containing the unresolvable webhook target:

POST /jobs HTTP/1.1
Host: praisonai-server:8000
Content-Type: application/json
Authorization: Bearer <valid_token>
 
{
  "agent_file": "agents.yaml",
  "webhook_url": "http://trigger.attacker.com/api/callback"
}

Third, the validation check executes. Because the DNS server returns an error, socket.gethostbyname() raises a socket.gaierror, the code triggers pass, and the system registers the job successfully.

Fourth, immediately after registration, the attacker updates the DNS records on their server to point to an internal resource, such as 127.0.0.1 or the AWS metadata endpoint 169.254.169.254. When the job completes, the background executor performs a new DNS request, resolves the domain to the internal IP, and sends the HTTP POST request, successfully achieving Server-Side Request Forgery.

A successful exploit allows authenticated attackers to make arbitrary HTTP requests originating from the PraisonAI container or host. This access bypasses boundary protections and allows communication with internal resources that are otherwise isolated from external networks.

The target systems can include local host admin panels, internal microservices, databases, and container metadata endpoints. On cloud systems, access to endpoints like 169.254.169.254 can allow the attacker to retrieve temporary IAM security credentials, leading to broader environment compromise.

The CVSS v3.1 score is 7.1 (High). The high complexity modifier reflects the requirement to orchestrate DNS server states during the timing gap between check and use. The modified scope parameter (S:C) indicates that the vulnerability allows an attacker to pivot from the application container to adjacent network services.

To fully remediate CVE-2026-55537, upgrade PraisonAI to version 4.6.58 or higher. The update implements a fail-closed policy that prevents the registration of unresolvable webhooks.

If immediate software upgrades are not possible, administrators should implement local mitigations:

1. Egress Filtering: Configure the firewall or security group on the PraisonAI host to drop outbound traffic originating from the server process that targets private IP ranges, specifically RFC 1918 subnets (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and cloud metadata endpoints (169.254.169.254).

2. DNS Cache Pinning: Configure a local recursive resolver that enforces a minimum Time-to-Live (TTL) for resolved queries. This configuration prevents rapid DNS record changes and neutralizes DNS rebinding techniques.