Description

Flowise versions before 3.1.4 contain a server-side request forgery vulnerability in Cheerio, Playwright, and Puppeteer document loader nodes that bypass SSRF protection. Attackers can provide arbitrary URLs to fetch cloud metadata, internal services, and private network resources with response content returned as document text.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-15T16:17:45.317Z",
  "pubdate": "2026-09-15T16:17:45.317Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) vulnerability exists in Flowise versions prior to 3.1.4, affecting the Cheerio, Playwright, and Puppeteer document loader nodes. The flaw stems from an insufficient validation mechanism that fails to prevent the application from making unauthorized outbound requests to sensitive internal resources.\nBy manipulating the URL input parameters within these specific document loader nodes, an unauthenticated or low-privileged attacker can force the Flowise server to initiate HTTP requests on their behalf. This allows the adversary to bypass existing security controls and interact with internal network segments, cloud metadata services (e.g., AWS IMDS), and private applications that are otherwise unreachable from the public internet.\nThe successful exploitation of this vulnerability leads to unauthorized information disclosure, as the response content from the requested internal resources is returned directly as document text within the Flowise workflow. The risk is significant, as it enables lateral movement, internal network reconnaissance, and the potential exfiltration of sensitive configuration data or cloud credentials. Organizations utilizing Flowise should treat this as a high-priority risk and implement immediate remediation to prevent unauthorized data access.",
  "technicalDetails": "The vulnerability resides within the document loader implementation of the Flowise application, specifically affecting the nodes that leverage Cheerio, Playwright, and Puppeteer. These components are designed to fetch and parse external content, but they lack adequate server-side validation for the provided destination URLs. The root cause is an ineffective SSRF mitigation logic that allows the traversal of network security perimeters by failing to blacklist or strictly sanitize requests directed at reserved IP ranges (e.g., 169.254.169.254, 127.0.0.1) or internal domain names.\nThe exploitation flow begins when an attacker identifies a workflow node that accepts a URL as an input parameter for data scraping or document ingestion. By providing a malicious URL targeting internal infrastructure, the attacker induces the server to perform an arbitrary request. Because the underlying library (Cheerio, Playwright, or Puppeteer) processes the request server-side, the server acts as a proxy for the attacker. If the server is hosted within a cloud environment, the attacker can specifically target the cloud provider's metadata service to exfiltrate temporary security credentials, identity tokens, or instance-specific configuration details.\nBeyond metadata services, an attacker can conduct port scanning or interact with private REST APIs running on localhost or within the same VPC. Since the application returns the response content as document text, the attacker can read the output of these internal requests directly in the interface. This transforms the Flowise instance into an SSRF reflection engine, allowing the attacker to bypass firewall rules that restrict inbound traffic but implicitly trust traffic originating from the internal server's host.\nThe vulnerability is present in all Flowise versions prior to 3.1.4. No specific authentication is required to interact with the vulnerable document loader nodes if the flow is exposed or accessible to the attacker. The exposure is limited only by the outbound network reachability of the server hosting the Flowise instance. Post-exploitation, the attacker gains the ability to gather sensitive system information and potentially pivot to other internal services that require trust based on the server's identity or location, facilitating further unauthorized access within the enterprise infrastructure."
}