CVE-2026-69250: Flowise Authentication Bypass Vulnerability

CVE-2026-69250 Overview

CVE-2026-69250 affects Flowise, a drag-and-drop interface for building large language model workflows. The vulnerability exists in the OAuth2 token refresh endpoint POST /api/v1/oauth2-credential/refresh/:credentialId. This endpoint is unauthenticated by design and issues a server-side HTTP request to a credential-controlled accessTokenUrl without Server-Side Request Forgery (SSRF) protections. Runtime testing confirmed attackers can reach the endpoint without authentication, force outbound POST requests to attacker-controlled servers, and receive the full remote response body reflected through tokenInfo. Requests include client_id, client_secret, grant_type=refresh_token, and refresh_token values. The issue is fixed in Flowise 3.1.3.

Critical Impact
Unauthenticated attackers can trigger arbitrary outbound HTTP requests from the Flowise server and exfiltrate stored OAuth2 client credentials to attacker-controlled endpoints.

Affected Products

Flowise versions prior to 3.1.3
Flowise OAuth2 credential subsystem
Deployments exposing /api/v1/oauth2-credential/refresh/:credentialId

Discovery Timeline

2026-08-04 - CVE-2026-69250 published to the National Vulnerability Database (NVD)
2026-08-04 - Last updated in NVD database

Technical Details for CVE-2026-69250

Vulnerability Analysis

The flaw is an authorization issue classified under [CWE-639] (Authorization Bypass Through User-Controlled Key) combined with an SSRF condition. The refresh endpoint accepts a credentialId path parameter and loads the associated credential record from storage. It then performs a server-side POST request to the accessTokenUrl stored in that credential without verifying the caller's identity or validating the destination.

The server forwards client_id, client_secret, grant_type=refresh_token, and refresh_token in the request body. The full HTTP response from the destination is reflected back to the caller in the tokenInfo field. An attacker who can create or influence a credential record controls both the outbound destination and the returned data.

Root Cause

The endpoint was designed to be unauthenticated to support token refresh flows. It lacks two controls: authentication or an authorization check binding the caller to the credential, and an allowlist restricting accessTokenUrl to trusted OAuth2 provider domains. The patched configuration introduces OAUTH2_SECURITY_CHECK and OAUTH2_ALLOWED_TOKEN_DOMAINS to enforce domain-level restrictions.

Attack Vector

An attacker sends a POST request to /api/v1/oauth2-credential/refresh/:credentialId referencing a credential whose accessTokenUrl points to attacker-controlled infrastructure. The Flowise server issues an outbound POST containing the stored client secret and refresh token. The attacker receives the credentials at their endpoint and can also read the reflected tokenInfo response, enabling both credential theft and SSRF probing of internal services.

text

# Patch excerpt: docker/.env.example - Fix FLOWISE 566 OAuth2 (#6276)
 # CUSTOM_MCP_SECURITY_CHECK=true
 # CUSTOM_MCP_PROTOCOL=sse #(stdio | sse)
 # TRUST_PROXY=true #(true | false | 1 | loopback| linklocal | uniquelocal | IP addresses | loopback, IP addresses)
+# OAUTH2_SECURITY_CHECK=true
+# OAUTH2_ALLOWED_TOKEN_DOMAINS= #(comma-separated list of additional OAuth2 provider domains to allow, e.g. keycloak.mycompany.com,auth.custom-idp.com)

Source: FlowiseAI/Flowise commit da8b251

Detection Methods for CVE-2026-69250

Indicators of Compromise

Inbound HTTP requests to /api/v1/oauth2-credential/refresh/ originating from unauthenticated sources or unusual IP ranges.
Outbound POST requests from the Flowise server to unexpected domains not matching known OAuth2 providers such as Google, Microsoft, or approved identity providers.
Newly created or modified OAuth2 credential records with accessTokenUrl values pointing to non-provider domains, IP literals, or internal RFC1918 ranges.

Detection Strategies

Inspect Flowise application logs for calls to the refresh endpoint that lack a corresponding authenticated session or originate outside expected client networks.
Correlate credential-record changes with subsequent outbound requests to identify suspicious accessTokenUrl values introduced before exploitation.
Deploy egress traffic inspection on the Flowise host and alert on POSTs to domains outside an approved OAuth2 provider allowlist.

Monitoring Recommendations

Enable request logging on the reverse proxy or ingress fronting Flowise and retain path, source IP, and response size for /api/v1/oauth2-credential/* routes.
Monitor for HTTP responses from the refresh endpoint that contain OAuth2 error payloads referencing unknown token URLs.
Track configuration drift and alert when OAUTH2_SECURITY_CHECK is disabled or OAUTH2_ALLOWED_TOKEN_DOMAINS is expanded to include untrusted domains.

How to Mitigate CVE-2026-69250

Immediate Actions Required

Upgrade Flowise to version 3.1.3 or later, which introduces domain validation for OAuth2 token URLs.
Rotate any OAuth2 client_secret and refresh_token values stored in Flowise credential records, treating them as potentially disclosed.
Restrict network access to the Flowise management interface so the OAuth2 endpoints are not reachable from untrusted networks.

Patch Information

The fix ships in Flowise 3.1.3 and is implemented in commit da8b251. See GHSA-r745-8hwv-h473 for the full advisory. The patch adds OAUTH2_SECURITY_CHECK and OAUTH2_ALLOWED_TOKEN_DOMAINS environment variables to enforce a domain allowlist for outbound token requests.

Workarounds

Block or gateway-filter requests to /api/v1/oauth2-credential/refresh/:credentialId at a reverse proxy until the upgrade is applied.
Configure host-level egress filtering to allow outbound HTTPS only to approved OAuth2 provider domains.
Audit existing credential records and remove or correct any accessTokenUrl values that do not point to sanctioned identity providers.

bash

# Configuration example - enable OAuth2 domain enforcement in Flowise 3.1.3+
OAUTH2_SECURITY_CHECK=true
OAUTH2_ALLOWED_TOKEN_DOMAINS=keycloak.mycompany.com,auth.custom-idp.com