Snyk has a proof-of-concept or detailed explanation of how to exploit this vulnerability.
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsLearn about Server-side Request Forgery (SSRF) vulnerabilities in an interactive lesson.
Start learningUpgrade flowise-components to version 3.1.0 or higher.
flowise-components is a Flowiseai Components
Affected versions of this package are vulnerable to Server-side Request Forgery (SSRF) through the URL-fetching tool in ExecuteFlow.ts, APILoader.ts, FireCrawl.ts, SpiderApp.ts, AzureRerank.ts, Jira/core.ts, MCP/core.ts, OpenAPIToolkit.ts, and Searxng.ts. An attacker can make the application send requests to arbitrary internal or external endpoints by supplying a crafted URL, redirect target, or API endpoint to these components. The vulnerable request handlers follow attacker-controlled URLs without consistently enforcing the deny list or pinning redirects, allowing malicious input to drive the server to protected network services, metadata endpoints, or other unintended hosts. In deployments that expose these tools to untrusted users or remote integrations, this can leak internal data and enable access to services reachable only from the Flowise host.
Notes
HTTP_DENY_LIST is only effective when requests go through packages/components/src/httpSecurity.ts; components that call raw node-fetch/axios bypass that centralized validation entirely, so deployments relying on the deny list for egress control did not get protection from those paths.Workarounds
OpenAPIToolkit, MCP, Jira, Searxng, ExecuteFlow, APILoader, FireCrawl, SpiderApp, and AzureRerank, when they can be reached by untrusted users or remote integrations; this prevents attacker-supplied URLs from being used to reach internal or metadata endpoints.