Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.5",
  "pubDate": "2026-09-14T15:17:06.040Z",
  "pubdate": "2026-09-14T15:17:06.040Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) vulnerability exists in the praisonaiagents package prior to version 1.6.58.\nThe vulnerability resides in the SpiderTools._validate_url function, which fails to perform DNS resolution before validating the target host.\nBy providing a hostname that resolves to loopback, private, link-local, or cloud-metadata service addresses, an attacker can bypass existing security controls.\nSuccessful exploitation allows an attacker to exfiltrate internal system responses and interact with protected internal services accessible to the agent.\nThis represents a significant security risk, as it permits unauthorized access to internal network infrastructure or sensitive cloud environment metadata via the multi-agent system's request capabilities.\nNo authentication or specific privileges are required to exploit this flaw, as the vulnerability is inherent to the URL processing logic within the affected component.",
  "technicalDetails": "The vulnerability is caused by a flawed validation mechanism in the SpiderTools._validate_url function. The implementation relies exclusively on literal host string analysis to identify restricted IP ranges or loopback addresses, neglecting the necessary step of resolving the hostname to its underlying IP address prior to validation.\nIn the affected versions, the _host_is_blocked check is performed before the connection is established by functions such as scrape_page, crawl, extract_links, extract_text, or URL-mention fetches. Because the validation occurs on the literal input string rather than the resolved address, an attacker can provide a hostname—such as 'localhost.attacker.com' or a domain pointing to 169.254.169.254—which passes the literal string validation but resolves to a restricted network segment at the time of the actual network request.\nThe attack flow follows a sequential process: First, the attacker provides a malicious URL to the agent, potentially through a task definition or input string that the system is instructed to process. Second, the SpiderTools._validate_url method executes, checking the literal characters of the hostname against the blocklist; since the hostname is not an explicit loopback address or private IP literal, the check returns valid.\nThird, the downstream function (e.g., scrape_page) initiates a network request using the provided URL. At this stage, the system's DNS resolver translates the hostname into the target IP address. Fourth, the request is directed to the intended internal resource, such as the cloud instance metadata service (IMDS), a local management port, or an internal container network segment.\nFinally, the response from the internal service is returned to the agent and subsequently exposed back to the attacker. This bypasses the need for complex DNS rebinding race conditions because the application logic creates a static vulnerability via incomplete validation logic. The exposure allows the agent to act as a proxy, facilitating unauthorized access to non-public network services, potentially leading to sensitive data exfiltration, service degradation, or further internal reconnaissance."
}