CVE-2026-41272

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();

Confidentiality: High (Access to internal services if protection is bypassed).

Integrity: Low/Medium (If internal services allow state changes via GET).

Availability: Low.

Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside. Typical impact: access to internal metadata services, internal APIs, or cloud credentials.

CVE-2026-41272 has a CVSS score of 7.1 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.1.0); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-41272? CVE-2026-41272 is a high-severity server-side request forgery (SSRF) vulnerability in flowise (npm), affecting versions <= 3.0.13. It is fixed in 3.1.0. Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside.
2. How severe is CVE-2026-41272? CVE-2026-41272 has a CVSS score of 7.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which packages are affected by CVE-2026-41272?
   • flowise (npm) (versions <= 3.0.13)
   • flowise-components (npm) (versions <= 3.0.13)
4. Is there a fix for CVE-2026-41272? Yes. CVE-2026-41272 is fixed in 3.1.0. Upgrade to this version or later.
5. Is CVE-2026-41272 exploitable, and should I be worried? Whether CVE-2026-41272 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-41272 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-41272?
   • Upgrade flowise to 3.1.0 or later
   • Upgrade flowise-components to 3.1.0 or later