Flowise has Authorization Bypass via Spoofed x-request-from Header

QFinch assessment

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.

Potential 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.

Technical context

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: 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.