Loading vulnerability…
CVE-2026-67620 is a server-side request forgery vulnerability in Flowise through version 3.1.4. The flaw is in the SSRF guard implemented in httpSecurity.ts, where the default deny list fails to block certain cloud metadata service endpoints used by Oracle Cloud Infrastructure and Alibaba Cloud. As a result, an attacker can supply a crafted URL to the fetch-links API endpoint and cause the Flowise server to issue arbitrary outbound GET requests to those metadata services. The weakness also includes redirect-based bypass conditions, allowing deny-list validation to be circumvented in additional request flows. On affected deployments, successful exploitation can expose cloud instance metadata, including instance identity information and role-associated credentials.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
Small standalone Python exploit repository for CVE-2026-67620 targeting FlowiseAI/Flowise <= 3.1.2. The repo contains one code file (poc.py), a README advisory, requirements.txt, and two evidence logs showing inbound requests to local listeners. The exploit is not part of a larger framework. The core capability is SSRF through Flowise's GET /api/v1/fetch-links endpoint by supplying a user-controlled url parameter. The PoC demonstrates that Flowise's metadata protection deny-list blocks 169.254.169.254 but fails to block Oracle Cloud's 192.0.0.192 and Alibaba Cloud's 100.100.100.200, allowing server-side GET requests to those metadata services. The script supports three main actions: --check to run a control plus bypass validation, --imds to walk provider-specific metadata paths, and -f/--fetch to force a GET to any arbitrary URL through the vulnerable Flowise instance. It also supports session-cookie auth, proxying, verbosity, timeout control, and saving returned response bodies. Repository structure is straightforward: README.md documents the vulnerability, affected code path, exploitation route, impact, and mitigation; poc.py implements the exploit logic using requests.Session; evidence/*.log provide proof-of-concept listener output for OCI and Alibaba targets. The exploit is operational rather than weaponized: it contains a usable payload path and arbitrary fetch primitive, but customization is manual and limited to command-line arguments. Notable fingerprintable targets include the vulnerable Flowise endpoint /api/v1/fetch-links, the alternate public route POST /api/v1/prediction/:id, and cloud metadata endpoints 169.254.169.254, 192.0.0.192, and 100.100.100.200 with associated metadata paths. Overall, the repository's purpose is to validate and demonstrate a deny-list bypass SSRF condition in Flowise that can expose cloud instance metadata and potentially credentials when deployed on OCI or Alibaba Cloud.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
7 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.