CVE-2026-57126: PraisonAI Agents SpiderTools SSRF

CISO Take

PraisonAI's web-scraping tool, SpiderTools, is supposed to enforce an SSRF policy but only checks the literal hostname string and never resolves DNS before connecting for scrape_page, crawl, extract_links, extract_text, or URL-mention fetches — so an attacker who controls a hostname resolving to loopback, private, link-local, or cloud-metadata addresses (e.g. 169.254.169.254) bypasses the filter outright, with no DNS-rebinding race required. This is a CVSS 8.5 (AV:N/AC:L/PR:L/UI:N/S:C/C:H) issue affecting any agent workflow that lets the crawler fetch attacker-influenced or attacker-supplied URLs, which is common in multi-agent research and browsing pipelines; there is no EPSS data, no known public exploit or scanner template, and it is not in CISA KEV, but the scope-changed vector means a successful hit can leak internal HTTP responses — including cloud instance-metadata credentials — back through the agent's output. Exploitation requires only low privileges and no user interaction, and downstream-dependent counts on `praisonaiagents` are currently unverified, so treat exposure as broad until confirmed. Patch to praisonaiagents 1.6.58 immediately, and in the interim add an egress control at the network layer (block RFC1918, loopback, link-local, and the cloud metadata IP) in front of any host running PraisonAI agents, since the application-layer check alone cannot be trusted. Monitor outbound requests from PraisonAI hosts to internal IP ranges and metadata endpoints as a detection signal for exploitation attempts.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

High risk from an exploitability standpoint: attack complexity is low, no user interaction is required, and only low privileges (ability to supply/influence a URL processed by the agent) are needed. The confidentiality impact is high and the vulnerability has a changed scope, meaning a successful exploit can expose data beyond the vulnerable component itself (internal services, cloud metadata). There is no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template, so there is no evidence of active exploitation today — but the trivial nature of the bypass (a single DNS record, no rebinding race) means weaponization requires minimal attacker effort once a vulnerable deployment is identified. Any PraisonAI deployment that lets agent tools fetch URLs derived from untrusted or semi-trusted input (user tasks, ingested documents, indirect prompt content) should be treated as exposed until patched.

How does the attack unfold?

Malicious URL delivery

Attacker gets a PraisonAI agent to process a URL they control, whose hostname resolves via DNS to a loopback, private, link-local, or cloud-metadata address.

AML.T0053

SSRF policy bypass

SpiderTools._validate_url checks only the literal hostname string against a blocklist and never resolves DNS, so the malicious hostname passes validation unchecked.

Internal resource fetch

The crawler connects using the resolved internal/metadata IP via scrape_page, crawl, extract_links, or extract_text, retrieving content the SSRF policy was meant to block.

AML.T0085.001

Data exposure to attacker

The fetched internal response (e.g., cloud metadata credentials or internal service data) is surfaced back through the agent's output, giving the attacker access to sensitive internal information or credentials for further compromise.

AML.T0024

Malicious URL delivery

Attacker gets a PraisonAI agent to process a URL they control, whose hostname resolves via DNS to a loopback, private, link-local, or cloud-metadata address.

AML.T0053

SSRF policy bypass

SpiderTools._validate_url checks only the literal hostname string against a blocklist and never resolves DNS, so the malicious hostname passes validation unchecked.

Internal resource fetch

The crawler connects using the resolved internal/metadata IP via scrape_page, crawl, extract_links, or extract_text, retrieving content the SSRF policy was meant to block.

AML.T0085.001

Data exposure to attacker

The fetched internal response (e.g., cloud metadata credentials or internal service data) is surfaced back through the agent's output, giving the attacker access to sensitive internal information or credentials for further compromise.

AML.T0024

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
PraisonAI Agents	pip	—	No patch
20 dependents 59% patched ~6d to patch Full package profile →

Do you use PraisonAI Agents? You're affected.

How severe is it?

CVSS 3.1

8.5 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 32% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

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

Upgrade to praisonaiagents 1.6.58 or later immediately, where DNS resolution is checked prior to connecting. Where immediate patching isn't possible, add network-layer SSRF protections: block outbound traffic from PraisonAI hosts to RFC1918 ranges, loopback, link-local addresses, and 169.254.169.254 (cloud metadata), ideally via an egress proxy that resolves and filters by destination IP rather than relying on hostname string checks. On cloud instances, enforce IMDSv2 with a hop limit of 1 to blunt metadata-theft attempts even if SSRF succeeds. Restrict which URLs SpiderTools is allowed to fetch to an allowlist where feasible, and add logging/alerting on crawler requests that resolve to internal or metadata IP ranges as a detection control.

How is it classified?

Data Leakage Data Extraction Agent Framework Plugin AML.T0053 - AI Agent Tool Invocation AML.T0085.001 - AI Agent Tools

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.8 - AI system operation and monitoring

NIST AI RMF

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

OWASP LLM Top 10

LLM06 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-57126?

PraisonAI's web-scraping tool, SpiderTools, is supposed to enforce an SSRF policy but only checks the literal hostname string and never resolves DNS before connecting for scrape_page, crawl, extract_links, extract_text, or URL-mention fetches — so an attacker who controls a hostname resolving to loopback, private, link-local, or cloud-metadata addresses (e.g. 169.254.169.254) bypasses the filter outright, with no DNS-rebinding race required. This is a CVSS 8.5 (AV:N/AC:L/PR:L/UI:N/S:C/C:H) issue affecting any agent workflow that lets the crawler fetch attacker-influenced or attacker-supplied URLs, which is common in multi-agent research and browsing pipelines; there is no EPSS data, no known public exploit or scanner template, and it is not in CISA KEV, but the scope-changed vector means a successful hit can leak internal HTTP responses — including cloud instance-metadata credentials — back through the agent's output. Exploitation requires only low privileges and no user interaction, and downstream-dependent counts on `praisonaiagents` are currently unverified, so treat exposure as broad until confirmed. Patch to praisonaiagents 1.6.58 immediately, and in the interim add an egress control at the network layer (block RFC1918, loopback, link-local, and the cloud metadata IP) in front of any host running PraisonAI agents, since the application-layer check alone cannot be trusted. Monitor outbound requests from PraisonAI hosts to internal IP ranges and metadata endpoints as a detection signal for exploitation attempts.

Is CVE-2026-57126 actively exploited?

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

How to fix CVE-2026-57126?

Upgrade to praisonaiagents 1.6.58 or later immediately, where DNS resolution is checked prior to connecting. Where immediate patching isn't possible, add network-layer SSRF protections: block outbound traffic from PraisonAI hosts to RFC1918 ranges, loopback, link-local addresses, and 169.254.169.254 (cloud metadata), ideally via an egress proxy that resolves and filters by destination IP rather than relying on hostname string checks. On cloud instances, enforce IMDSv2 with a hop limit of 1 to blunt metadata-theft attempts even if SSRF succeeds. Restrict which URLs SpiderTools is allowed to fetch to an allowlist where feasible, and add logging/alerting on crawler requests that resolve to internal or metadata IP ranges as a detection control.

What systems are affected by CVE-2026-57126?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, autonomous web crawling agents, RAG pipelines, cloud-hosted agent deployments.

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

CVE-2026-57126 has a CVSS v3.1 base score of 8.5 (HIGH). The EPSS exploitation probability is 0.38%.

What is the AI security impact?

Affected AI Architectures

agent frameworksautonomous web crawling agentsRAG pipelinescloud-hosted agent deployments

MITRE ATLAS Techniques

AML.T0053 AI Agent Tool Invocation

AML.T0085.001 AI Agent Tools

Compliance Controls Affected

ISO 42001: A.6.2.8

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

PraisonAI is a multi-agent teams system. Prior to praisonaiagents 1.6.58, SpiderTools._validate_url calls _host_is_blocked, which checks literal host encodings but does not resolve DNS names before scrape_page, crawl, extract_links, extract_text, or URL-mention fetches connect. An attacker-controlled hostname resolving to a loopback, private, link-local, or cloud-metadata address therefore bypasses the SSRF policy without a rebinding race and can expose internal responses to the agent. This issue is fixed in praisonaiagents 1.6.58.

Exploitation Scenario

An attacker registers a domain (e.g. evil-research.example) with a DNS A record pointing to 169.254.169.254 or an internal IP like 10.0.0.5. They then get this URL in front of the PraisonAI agent — for example by embedding it in a task description, a document the agent is asked to summarize, or content the agent is instructed to crawl as part of a research task (a classic indirect-injection delivery vector). SpiderTools._validate_url inspects only the literal hostname string 'evil-research.example', finds no match against its blocklist of literal internal hosts, and allows the request. When the HTTP client actually connects, DNS resolves the hostname to the internal or metadata address, and the crawler fetches it directly — no race condition or timing attack needed. The fetched response (e.g., temporary cloud credentials from the metadata service, or contents of an internal admin endpoint) flows back into the agent's context and is surfaced in its output, giving the attacker a straightforward internal reconnaissance and data-exfiltration primitive.

Weaknesses (CWE)

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

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.