GHSA-2x8m-83vc-6wv4 — flowise
HIGHGHSA-2x8m-83vc-6wv4 is a high-severity (CVSS 7.1) Server-Side Request Forgery (SSRF) vulnerability in flowise. A fix is available for flowise — see the affected versions and patch details below.
Flowise: SSRF Protection Bypass (TOCTOU & Default Insecure)
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-2x8m-83vc-6wv4.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-2x8m-83vc-6wv4 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,166 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
flowisenpmflowise-componentsnpmDescription
Summary
The core security wrappers (secureAxiosRequest and secureFetch) intended to prevent Server-Side Request Forgery (SSRF) contain multiple logic flaws. These flaws allow attackers to bypass the allow/deny lists via DNS Rebinding (Time-of-Check Time-of-Use) or by exploiting the default configuration which fails to enforce any deny list.
Details
The flaws exist in packages/components/src/httpSecurity.ts.
Default Insecure: If process.env.HTTP_DENY_LIST is undefined, checkDenyList returns immediately, allowing all requests (including localhost).
DNS Rebinding (TOCTOU): The function performs a DNS lookup (dns.lookup) to validate the IP, and then the HTTP client performs a new lookup to connect. An attacker can serve a valid IP first, then switch to an internal IP (e.g., 127.0.0.1) for the second lookup.
PoC
Ensure HTTP_DENY_LIST is unset (default behavior).
Use any node utilizing secureFetch to access http://127.0.0.1.
Result: Request succeeds.
Scenario 2: DNS Rebinding
Attacker controls domain attacker.com and a custom DNS server.
Configure DNS to return 1.1.1.1 (Safe IP) with TTL=0 for the first query.
Configure DNS to return 127.0.0.1 (Blocked IP) for subsequent queries.
Flowise validates attacker.com -> 1.1.1.1 (Allowed).
Flowise fetches attacker.com -> 127.0.0.1 (Bypass).
Run the following for manual verification
// PoC for httpSecurity.ts Bypasses
import * as dns from 'dns/promises';
// Mocking the checkDenyList logic from Flowise
async function checkDenyList(url: string) {
const deniedIPs = ['127.0.0.1', '0.0.0.0']; // Simplified deny list logic
if (!process.env.HTTP_DENY_LIST) {
console.log(\"⚠️ HTTP_DENY_LIST not set. Returning allowed.\");
return; // Vulnerability 1: Default Insecure
}
const { hostname } = new URL(url);
const { address } = await dns.lookup(hostname);
if (deniedIPs.includes(address)) {
throw new Error(`IP ${address} is denied`);
}
console.log(`✅ IP ${address} allowed check.`);
}
async function runPoC() {
console.log(\"--- Test 1: Default Configuration (Unset HTTP_DENY_LIST) ---\");
// Ensure env var is unset
delete process.env.HTTP_DENY_LIST;
try {
await checkDenyList('http://127.0.0.1');
console.log(\"[PASS] Default config allowed localhost access.\");
} catch (e) {
console.log(\"[FAIL] Blocked:\", e.message);
}
console.log(\"\
--- Test 2: 'private' Keyword Bypass (Logic Flaw) ---\");
process.env.HTTP_DENY_LIST = 'private'; // User expects this to block localhost
try {
await checkDenyList('http://127.0.0.1');
// In real Flowise code, 'private' is not expanded to IPs, so it only blocks the string \"private\"
console.log(\"[PASS] 'private' keyword failed to block localhost (Mock simulation).\");
} catch (e) {
console.log(\"[FAIL] Blocked:\", e.message);
}
}
runPoC();
Impact
Confidentiality: High (Access to internal services if protection is bypassed).
Integrity: Low/Medium (If internal services allow state changes via GET).
Availability: Low.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | flowise | all versions | 3.1.0npm install flowise@3.1.0 |
| 📦npm | flowise-components | all versions | 3.1.0npm install flowise-components@3.1.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for flowise, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update flowise to 3.1.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2x8m-83vc-6wv4 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-2x8m-83vc-6wv4 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-2x8m-83vc-6wv4. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-2x8m-83vc-6wv4 in your dependencies?
O3 Security finds GHSA-2x8m-83vc-6wv4 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.