AI Threat AlertPraisonAI's agent web-scraping tool checks hostnames as strings before fetching a URL, but never resolves them first — so an attacker can hand it something like 127.0.0.1.nip.io, which reads as an external hostname but resolves straight to loopback (or, with a similar trick, to cloud metadata endpoints like 169.254.169.254). Any deployment where an agent's scrape_page tool accepts attacker-influenced URLs — directly from a user, or indirectly via prompt injection from scraped content — can be coerced into reaching internal services, admin panels, or cloud IMDS endpoints that should never be network-reachable from outside. There's no CISA KEV listing, no public exploit or Nuclei template yet, and EPSS data isn't available, so this isn't under active mass exploitation today, but the technique (nip.io/sslip.io wildcard-DNS SSRF) is well-known and trivial to weaponize once someone points it at a live agent. With 20 downstream dependents and a CVSS of 8.5 driven by a scope change and high confidentiality impact, this is a patch-now item, not a watch-and-wait one. Upgrade to praisonaiagents 1.6.58+, which resolves hostnames via socket.getaddrinfo and fails closed on DNS errors, and in the meantime block outbound agent traffic to RFC1918/loopback/link-local ranges at the network layer.
What is the risk?
High severity (CVSS 8.5) with network attack vector, low complexity, and no user interaction required beyond low privileges to invoke the tool. The scope-changed rating reflects that exploitation lets the agent reach resources outside its intended trust boundary (internal network/cloud metadata) rather than just affecting the PraisonAI process itself. No active exploitation, KEV listing, or public PoC/scanner exists today, which lowers immediate urgency, but the bypass technique is a commodity SSRF trick (wildcard DNS services resolving to internal IPs) that requires no novel research to reproduce. Real-world risk is concentrated in any deployment that exposes the spider_tools/scrape_page capability to untrusted input — end users, or content the agent itself retrieves and then acts on.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| PraisonAI Agents | pip | < 1.6.58 | 1.6.58 |
Do you use PraisonAI Agents? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 stepUpgrade praisonaiagents to 1.6.58 or later, where _host_is_blocked() resolves hostnames via socket.getaddrinfo before validation and fails closed on DNS resolution errors. Until patched, place agents that use scrape_page behind an egress proxy or firewall rule that blocks outbound requests to RFC1918 private ranges, loopback (127.0.0.0/8), and link-local addresses (169.254.0.0/16, including 169.254.169.254 cloud metadata). Disable or restrict the spider/scrape tool to a strict domain allowlist where feasible. For detection, monitor agent outbound HTTP logs for requests to loopback/private/link-local IPs, or to wildcard-DNS domains such as *.nip.io, *.sslip.io, and *.xip.io, which are common SSRF bypass vectors.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-55526?
PraisonAI's agent web-scraping tool checks hostnames as strings before fetching a URL, but never resolves them first — so an attacker can hand it something like 127.0.0.1.nip.io, which reads as an external hostname but resolves straight to loopback (or, with a similar trick, to cloud metadata endpoints like 169.254.169.254). Any deployment where an agent's scrape_page tool accepts attacker-influenced URLs — directly from a user, or indirectly via prompt injection from scraped content — can be coerced into reaching internal services, admin panels, or cloud IMDS endpoints that should never be network-reachable from outside. There's no CISA KEV listing, no public exploit or Nuclei template yet, and EPSS data isn't available, so this isn't under active mass exploitation today, but the technique (nip.io/sslip.io wildcard-DNS SSRF) is well-known and trivial to weaponize once someone points it at a live agent. With 20 downstream dependents and a CVSS of 8.5 driven by a scope change and high confidentiality impact, this is a patch-now item, not a watch-and-wait one. Upgrade to praisonaiagents 1.6.58+, which resolves hostnames via socket.getaddrinfo and fails closed on DNS errors, and in the meantime block outbound agent traffic to RFC1918/loopback/link-local ranges at the network layer.
Is CVE-2026-55526 actively exploited?
No confirmed active exploitation of CVE-2026-55526 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-55526?
Upgrade praisonaiagents to 1.6.58 or later, where _host_is_blocked() resolves hostnames via socket.getaddrinfo before validation and fails closed on DNS resolution errors. Until patched, place agents that use scrape_page behind an egress proxy or firewall rule that blocks outbound requests to RFC1918 private ranges, loopback (127.0.0.0/8), and link-local addresses (169.254.0.0/16, including 169.254.169.254 cloud metadata). Disable or restrict the spider/scrape tool to a strict domain allowlist where feasible. For detection, monitor agent outbound HTTP logs for requests to loopback/private/link-local IPs, or to wildcard-DNS domains such as *.nip.io, *.sslip.io, and *.xip.io, which are common SSRF bypass vectors.
What systems are affected by CVE-2026-55526?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, web browsing/scraping agent tools, autonomous multi-agent systems.
What is the CVSS score for CVE-2026-55526?
CVE-2026-55526 has a CVSS v3.1 base score of 8.5 (HIGH). The EPSS exploitation probability is 0.36%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0049Exploit Public-Facing ApplicationAML.T0053AI Agent Tool InvocationAML.T0084.001Tool DefinitionsCompliance Controls Affected
What are the technical details?
Original Advisory
PraisonAI is a multi-agent teams system. Prior to praisonaiagents 1.6.58, spider_tools._host_is_blocked() does not resolve ordinary hostnames before scrape_page fetches them. A hostname such as 127.0.0.1.nip.io passes validation and resolves to loopback, permitting internal HTTP access. The fix uses socket.getaddrinfo and fails closed on DNS errors. This issue is fixed in version 1.6.58.
Exploitation Scenario
An attacker interacts with an application built on PraisonAI that exposes a research/browsing agent capable of fetching arbitrary URLs via the scrape_page tool — either directly as a user-supplied URL parameter, or indirectly by getting the agent to visit a page containing a crafted link (prompt injection). The attacker submits a hostname such as 169.254.169.254.nip.io, which the string-based _host_is_blocked() check treats as an ordinary external domain since it doesn't match any blocked literal, but which DNS resolves to the cloud provider's instance metadata service. The agent's HTTP client fetches the internal endpoint, retrieves temporary cloud credentials or internal service data, and returns the content within its response to the attacker, who now has a foothold for further lateral movement or credential abuse.
Weaknesses (CWE)
CWE-350Reliance on Reverse DNS Resolution for a Security-Critical ActionPrimaryCWE-350Reliance on Reverse DNS Resolution for a Security-Critical ActionPrimaryCWE-918Server-Side Request Forgery (SSRF)PrimaryCWE-918Server-Side Request Forgery (SSRF)PrimaryCWE-350Reliance on Reverse DNS Resolution for a Security-Critical ActionCWE-918Server-Side Request Forgery (SSRF)CWE-350 — Reliance on Reverse DNS Resolution for a Security-Critical Action: The product performs reverse DNS resolution on an IP address to obtain the hostname and make a security decision, but it does not properly ensure that the IP address is truly associated with the hostname.
- [Architecture and Design] Use other means of identity verification that cannot be simply spoofed. Possibilities include a username/password or certificate.
- [Implementation] Perform proper forward and reverse DNS lookups to detect DNS spoofing.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:NReferences
Timeline
Related Vulnerabilities
CVE-2026-3493810.0praisonaiagents: sandbox bypass enables full host RCE
Same package: praisonaiagentsCVE-2026-3988810.0praisonaiagents: sandbox escape enables host RCE
Same package: praisonaiagentsCVE-2026-6144710.0PraisonAI: RCE via unsandboxed LLM code execution
Same package: praisonaiagentsCVE-2026-473929.9praisonaiagents: RCE via Python sandbox bypass
Same package: praisonaiagentsGHSA-vc46-vw85-3wvm9.8PraisonAI: RCE via malicious workflow YAML execution
Same package: praisonaiagents