Description

PraisonAI is a multi-agent teams system. Prior to praisonaiagents 1.6.59, SpiderTools.scrape_page validates only the initial URL and lets requests.Session.get follow redirects automatically, so a public-looking URL can redirect to a loopback, private, link-local, or metadata address without revalidation. The redirected response body is returned through scrape_page and its extract_links, crawl, and extract_text callers, allowing disclosure from otherwise blocked services. This issue is fixed in praisonaiagents 1.6.59.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-14T15:17:05.450Z",
  "pubdate": "2026-09-14T15:17:05.450Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) vulnerability exists in praisonaiagents prior to version 1.6.59. The vulnerability is located within the SpiderTools.scrape_page function, which fails to adequately validate URLs during the HTTP redirect process.\nBy leveraging the automatic redirect follow behavior of requests.Session.get, an attacker can bypass initial URL validation checks to access restricted internal network resources, including loopback (127.0.0.1), private network (RFC 1918), link-local, and cloud metadata services.\nThe vulnerability allows an unauthenticated remote attacker to perform unauthorized data extraction from internal services that are otherwise protected by network perimeters. The impact includes the potential disclosure of sensitive configuration data, environment variables, or internal service responses, significantly compromising the confidentiality of the host environment and associated infrastructure.\nExploitation does not require prior authentication, making it a high-risk vector for environments where the PraisonAI framework interacts with untrusted user input.",
  "technicalDetails": "The vulnerability resides in the implementation of the SpiderTools.scrape_page function within the praisonaiagents library. The root cause is an improper validation sequence where the application performs security checks exclusively on the initial target URL, failing to enforce these constraints during subsequent HTTP 3xx redirect cycles.\nWhen a request is initiated via requests.Session.get, the library is configured to automatically follow redirects. Because the session object maintains this state without re-invoking the validation logic for each hop, the redirect target is processed by the underlying HTTP client without verification.\nThe attack flow follows a structured trajectory: 1) The attacker provides a URL under their control to the scrape_page function. 2) The initial validation check confirms the attacker-controlled URL is permissible. 3) The server sends a 302 or 301 HTTP redirect response pointing to an internal target, such as http://169.254.169.254/latest/meta-data/ (cloud metadata) or http://localhost:8080/ (local management interfaces). 4) The requests.Session.get method automatically follows this redirect, fetching the content from the internal endpoint. 5) The sensitive response body is subsequently processed by extract_links, crawl, or extract_text functions, ultimately returning the extracted internal data to the attacker.\nThis SSRF vector effectively turns the PraisonAI agent into a proxy for internal network reconnaissance. Since the application returns the response body of the fetched resource, the attacker gains full visibility into the internal service's output. This bypasses typical perimeter defenses as the traffic originates from the server running the agent, granting the attacker the ability to interact with non-public APIs, database management interfaces, or administrative panels reachable from the host machine. The issue remains present in all versions of praisonaiagents prior to 1.6.59."
}