NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
📦
📦 npm
Not in CISA KEV
HIGH severity

CVE-2026-41272 — flowise

HIGH

CVE-2026-41272 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)

Also known asGHSA-2x8m-83vc-6wv4
Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Oct 27, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

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 CVE-2026-41272.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk-0.10%
Lower risk than most CVEs17th percentile — riskier than 17% of all scored CVEsHighest risk
0.00%0.28%0.57%0.85%0.0%0.3%May 26Aug 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

2 pkgs affected

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.

0other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
flowisenpm
2Kdownloads / week
flowise-componentsnpm
2Kdownloads / week

Description

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

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
📦npmflowiseall versions3.1.0npm install flowise@3.1.0
📦npmflowise-componentsall versions3.1.0npm install flowise-components@3.1.0

Affected Products

1 product · 1 configurations
Application
flowiseflowiseai
< 3.1.0
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. Fix

    Update flowise to 3.1.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-41272 is resolved across your whole dependency graph.

  3. Workarounds

    Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.

Frequently Asked Questions

### 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 funct
O3 Security · Impact-Aware SCA

Is CVE-2026-41272 in your dependencies?

Find it across npm, including transitive dependencies.

CVE-2026-41272: flowise SSRF — Fixed in 3.1.0