CVE-2026-61429: PraisonAI SSRF bypass

CISO Take

PraisonAI's Crawl4AI/Chromium browsing backend can be tricked into fetching internal network resources even though it validates URLs before crawling: an attacker submits a URL that passes the initial SSRF check, then uses DNS rebinding or a crafted HTTP redirect so the headless browser actually connects to an internal service after validation has already passed. There is no EPSS score, CISA KEV entry, public exploit, or Nuclei template available yet, and downstream dependent counts for PraisonAI are unknown, so this isn't showing signs of mass exploitation today — but the CVSS 8.5 rating reflects a genuinely low-effort, no-user-interaction path to reading internal responses (including sensitive canary values), which is exactly the profile of confidentiality-only SSRF bugs that get weaponized quietly against cloud metadata endpoints and internal admin panels. Any deployment that lets a PraisonAI agent invoke its web-crawling/browsing tool on user- or model-supplied URLs should treat this as a live exposure, not a theoretical one, given attack complexity is low and only low privileges are required. Patch to PraisonAI 1.6.78 or later immediately; until then, restrict egress from the crawler's network segment (block RFC1918 ranges and 169.254.169.254) and re-validate the resolved IP at connection time on every redirect hop instead of trusting a single pre-fetch check. Watch crawler logs for requests resolving to internal IP ranges as a detection signal in the interim.

Sources: NVD GitHub Advisory vulncheck.com ATLAS

What is the risk?

High severity (CVSS 8.5, AV:N/AC:L/PR:L/UI:N) driven by a confidentiality-high impact — successful exploitation reads internal responses, including sensitive canary values, with no user interaction and low attacker privileges required. However, real-world urgency is currently tempered by the absence of EPSS scoring, CISA KEV listing, public exploit code, or a Nuclei template, and unknown downstream dependent counts limit blast-radius estimation. The exploit path itself (DNS rebinding + redirect-based validation bypass) requires moderate networking knowledge, not commodity script-kiddie tooling, but is well-documented and repeatable once understood. Organizations running PraisonAI with the Crawl4AI/Chromium browsing tool exposed to any untrusted input (user prompts, retrieved content, agent-to-agent handoffs) should treat this as immediately actionable given the low complexity and lack of required interaction, even though it is not yet an actively exploited-in-the-wild vulnerability.

How does the attack unfold?

Malicious URL Submission

Attacker submits a URL to the PraisonAI agent's crawling tool that points to an attacker-controlled domain, passing the initial SSRF allowlist validation.

AML.T0053

Validation Bypass

The domain's DNS record rebinds to an internal IP (or the attacker's server issues an HTTP redirect to an internal resource) after the SSRF check has already cleared the URL.

Internal Resource Access

The Crawl4AI/Chromium headless browser follows the rebound connection or redirect and fetches the internal service's response without re-validating the destination.

AML.T0049

Data Exfiltration

The internal response, including sensitive canary values, is returned to the attacker via the agent's tool output, confirming and completing the SSRF exploitation.

AML.T0086

Malicious URL Submission

Attacker submits a URL to the PraisonAI agent's crawling tool that points to an attacker-controlled domain, passing the initial SSRF allowlist validation.

AML.T0053

Validation Bypass

The domain's DNS record rebinds to an internal IP (or the attacker's server issues an HTTP redirect to an internal resource) after the SSRF check has already cleared the URL.

Internal Resource Access

The Crawl4AI/Chromium headless browser follows the rebound connection or redirect and fetches the internal service's response without re-validating the destination.

AML.T0049

Data Exfiltration

The internal response, including sensitive canary values, is returned to the attacker via the agent's tool output, confirming and completing the SSRF exploitation.

AML.T0086

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
PraisonAI	pip	—	No patch
1 dependents 74% patched ~0d to patch Full package profile →

Do you use PraisonAI? You're affected.

How severe is it?

CVSS 3.1

8.5 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Changed

C High

I Low

A None

What should I do?

1 step

1) Upgrade PraisonAI to version 1.6.78 or later, which fixes the SSRF validation bypass. 2) If immediate patching isn't possible, network-isolate the Crawl4AI/Chromium crawler process so it cannot reach RFC1918 private ranges, link-local addresses (169.254.169.254 and cloud metadata equivalents), or other internal-only hosts — enforce this at the network/firewall layer, not just in application code. 3) Re-validate the resolved IP address at actual connection time (and on every redirect hop the headless browser follows), rather than validating only the initial hostname/IP before the request is issued — this closes the DNS-rebinding TOCTOU gap. 4) Disable or cap automatic redirect-following in the crawling backend where feasible, or re-run SSRF checks against each redirect target. 5) For detection, monitor crawler/proxy logs for outbound requests resolving to internal or link-local IP ranges, and alert on any canary/honeytoken values appearing in crawler output. 6) Rotate any secrets or canary tokens that may have been exposed to internal services reachable by the crawler prior to patching.

How is it classified?

Data Leakage Auth Bypass Agent Plugin AML.T0049 - Exploit Public-Facing Application AML.T0053 - AI Agent Tool Invocation AML.T0086 - Exfiltration via AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

NIST AI RMF

MEASURE 2.7 - AI system security and resilience are evaluated and documented

OWASP LLM Top 10

LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-61429?

PraisonAI's Crawl4AI/Chromium browsing backend can be tricked into fetching internal network resources even though it validates URLs before crawling: an attacker submits a URL that passes the initial SSRF check, then uses DNS rebinding or a crafted HTTP redirect so the headless browser actually connects to an internal service after validation has already passed. There is no EPSS score, CISA KEV entry, public exploit, or Nuclei template available yet, and downstream dependent counts for PraisonAI are unknown, so this isn't showing signs of mass exploitation today — but the CVSS 8.5 rating reflects a genuinely low-effort, no-user-interaction path to reading internal responses (including sensitive canary values), which is exactly the profile of confidentiality-only SSRF bugs that get weaponized quietly against cloud metadata endpoints and internal admin panels. Any deployment that lets a PraisonAI agent invoke its web-crawling/browsing tool on user- or model-supplied URLs should treat this as a live exposure, not a theoretical one, given attack complexity is low and only low privileges are required. Patch to PraisonAI 1.6.78 or later immediately; until then, restrict egress from the crawler's network segment (block RFC1918 ranges and 169.254.169.254) and re-validate the resolved IP at connection time on every redirect hop instead of trusting a single pre-fetch check. Watch crawler logs for requests resolving to internal IP ranges as a detection signal in the interim.

Is CVE-2026-61429 actively exploited?

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

How to fix CVE-2026-61429?

1) Upgrade PraisonAI to version 1.6.78 or later, which fixes the SSRF validation bypass. 2) If immediate patching isn't possible, network-isolate the Crawl4AI/Chromium crawler process so it cannot reach RFC1918 private ranges, link-local addresses (169.254.169.254 and cloud metadata equivalents), or other internal-only hosts — enforce this at the network/firewall layer, not just in application code. 3) Re-validate the resolved IP address at actual connection time (and on every redirect hop the headless browser follows), rather than validating only the initial hostname/IP before the request is issued — this closes the DNS-rebinding TOCTOU gap. 4) Disable or cap automatic redirect-following in the crawling backend where feasible, or re-run SSRF checks against each redirect target. 5) For detection, monitor crawler/proxy logs for outbound requests resolving to internal or link-local IP ranges, and alert on any canary/honeytoken values appearing in crawler output. 6) Rotate any secrets or canary tokens that may have been exposed to internal services reachable by the crawler prior to patching.

What systems are affected by CVE-2026-61429?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, web crawling/browsing tools, tool invocation pipelines.

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

CVE-2026-61429 has a CVSS v3.1 base score of 8.5 (HIGH).

What is the AI security impact?

Affected AI Architectures

agent frameworksweb crawling/browsing toolstool invocation pipelines

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0053 AI Agent Tool Invocation

AML.T0086 Exfiltration via AI Agent Tool Invocation

Compliance Controls Affected

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM06:2025

What are the technical details?

Original Advisory

PraisonAI versions before 1.6.78 contain a server-side request forgery vulnerability in the Crawl4AI/Chromium backend that allows attackers to bypass SSRF validation by exploiting DNS rebinding and HTTP redirects. Attackers can craft URLs that resolve to internal services after the initial validation check, enabling the headless browser to follow redirects and read internal responses including sensitive canary values.

Exploitation Scenario

An attacker with low-privilege access to a PraisonAI-based agent (e.g., as an end user submitting a research/browsing task, or via content the agent is instructed to retrieve) supplies a URL to a domain they control that initially resolves to a public IP, satisfying the agent's SSRF allowlist check. Once validation passes, the attacker either lets the domain's DNS record rebind (via a very short TTL) to an internal IP address, or has their server respond with an HTTP redirect pointing to an internal resource such as a cloud metadata endpoint or an internal admin panel. The Crawl4AI/Chromium backend, having already cleared the initial check, follows the rebound connection or redirect without re-validating it, fetches the internal resource, and returns its contents (including sensitive canary/token values proving internal reachability) back through the agent's tool output to the attacker — effectively turning the agent's browsing capability into an internal network reconnaissance and data-exfiltration proxy.

Weaknesses (CWE)

CWE-918 Server-Side Request Forgery (SSRF) Primary

CWE-918 — Server-Side Request Forgery (SSRF): The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

Source: MITRE CWE corpus.