CVE-2026-57115 in Praisonai
Summary
by MITRE • 09/14/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified in PraisonAI prior to version 1.6.59 represents a critical server-side request forgery flaw rooted in improper validation of Uniform Resource Locators during web scraping operations. PraisonAI utilizes a multi-agent team architecture where automated agents perform various tasks, including fetching and processing content from external sources. The core technical deficiency lies within the SpiderTools.scrape_page function, which is responsible for retrieving webpage data. In versions preceding 1.6.59, this function performs validation checks exclusively on the initial URL provided by the user or agent. It fails to implement a similar re-validation mechanism after Hypertext Transfer Protocol redirects are processed. This oversight allows an attacker who can influence the input URL to bypass security controls that restrict access to internal network resources.
The operational mechanics of this vulnerability exploit the automatic redirect following behavior inherent in standard Python requests.Session objects. When SpiderTools.scrape_page initiates a request, it validates whether the starting address is permitted based on predefined allowlists or blocklists designed to prevent access to private IP ranges such as loopback addresses like 127.0.0.1, link-local addresses like 169.254.x.x, and metadata service endpoints commonly found at cloud provider specific IPs such as 169.254.169.254 for AWS or similar ranges in Azure and GCP. However, because the validation occurs only before the request is sent, an attacker can supply a public-facing domain that redirects to one of these restricted internal addresses. The underlying HTTP client follows this redirect transparently without triggering any secondary security checks, effectively circumventing the intended network isolation policies.
The impact of this vulnerability extends beyond simple access control bypasses and facilitates significant data disclosure from services that are typically inaccessible from external networks. Once the request reaches an internal service via the redirected path, the response body is returned through scrape_page to its callers, including extract_links, crawl, and extract_text functions. This means sensitive information hosted on internal infrastructure can be exfiltrated by malicious agents or users who have control over input parameters passed to these scraping tools. In cloud environments, this specifically enables attackers to retrieve instance metadata credentials, such as temporary security tokens and access keys, which could then be used to escalate privileges within the cloud account or lateral movement across the network. This aligns with Common Weakness Enumeration CWE-918, which describes Server-Side Request Forgery where a web server fetches a specified resource from a developer-supplied URL without validating whether that destination is safe.
From an offensive security perspective, this vulnerability maps directly to techniques observed in real-world attacks and documented in the MITRE ATT&CK framework. Specifically, it corresponds to T1598.002, which covers Phishing via Spearphishing Attachment if used for initial access, but more accurately aligns with T1071.004 Application Layer Protocol: Web Protocols when considering the method of communication and T1638 Cloud Service Discovery as a potential follow-on effect to gather information about the cloud environment using metadata services. The ability to probe internal network segments from an external-facing application component creates a significant attack surface expansion, allowing adversaries to map internal topologies or steal credentials that are not exposed through standard internet routes.
To mitigate this vulnerability and prevent similar issues in future implementations, it is imperative to enforce strict URL validation at every stage of the request lifecycle rather than solely on the initial input. Developers should configure HTTP clients to disable automatic redirect following by default, allowing for explicit control over each hop in a redirection chain. If redirects are necessary for legitimate functionality, each intermediate and final destination must be validated against allowlists or blocklists using the same rigorous standards applied to the original URL. Additionally, implementing network-level controls such as egress filtering can provide defense-in-depth by blocking outbound connections from application servers to private IP ranges regardless of how those requests were initiated within the application logic. Upgrading to PraisonAI version 1.6.59 or later resolves this issue by addressing these validation gaps and ensuring that redirected targets are subject to appropriate security checks before data is processed and returned.