CVE-2026-70478: 
Flowise vulnerability analysis and mitigation

CVE-2026-70478 is a missing authentication vulnerability in FlowiseAI Flowise that allows unauthenticated attackers to steal OAuth2 access tokens for any connected third-party service. The POST /api/v1/oauth2-credential/refresh/:credentialId endpoint is included in WHITELIST_URLS, bypassing all authentication checks, and returns a freshly issued access_token directly in the response body. All Flowise versions up to and including 3.1.2 (npm package flowise) are affected; the issue is fixed in version 3.1.3. It carries a CVSS v4.0 base score of 9.2 (Critical) (GitHub Advisory). The advisory was first published on July 29, 2026, and added to the GitHub Advisory Database on August 4, 2026 (GitHub Advisory).

The root cause is classified as CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor): the OAuth2 token refresh route (packages/server/src/routes/oauth2/index.ts, lines 393–402) is explicitly listed in WHITELIST_URLS (packages/server/src/utils/constants.ts, line 40), exempting it from Flowise's authentication middleware (GitHub Advisory). When called, the server decrypts the stored credential (which contains clientId, clientSecret, and refresh_token), forwards a refresh request to the configured OAuth provider, and returns the resulting access_token in the JSON response body under tokenInfo. An attacker only needs a valid credentialId — obtainable via enumeration or a separate public chatflow information-disclosure issue — to trigger the full token refresh cycle without any session or API key. The NVD SSVC assessment marks this vulnerability as automatable, meaning it can be exploited at scale with no human interaction (GitHub Advisory).

Successful exploitation grants an attacker a valid OAuth2 access_token for the victim's connected third-party service (e.g., Google, Microsoft, GitHub), enabling full unauthorized access to that account's data and actions. Because the server uses the stored clientSecret during the refresh, the OAuth provider issues a legitimate token indistinguishable from one obtained by the real user, making detection difficult. Additionally, repeated calls to the endpoint can exhaust the OAuth provider's refresh-token quota, causing a denial-of-service condition for the legitimate user. Both the vulnerable Flowise system and all downstream (subsequent) systems connected via OAuth are impacted at high confidentiality and low integrity levels (GitHub Advisory).

A proof-of-concept attack chain is publicly documented in the GitHub Security Advisory, and the NVD SSVC classification confirms PoC availability (GitHub Advisory). The vulnerability requires no authentication, no privileges, and no user interaction, making it trivially automatable at scale. The EPSS score is approximately 0.38% (31st percentile), indicating a moderate near-term exploitation probability (GitHub Advisory). No confirmed in-the-wild exploitation campaigns or specific threat actor attribution have been reported as of the time of this report, and the vulnerability is not currently listed in the CISA KEV catalog.

1. Reconnaissance: Identify internet-facing Flowise instances (versions ≤ 3.1.2) using Shodan, Censys, or similar tools by searching for the Flowise web UI or API banner.
2. Obtain a credential ID: Acquire a valid credentialId either through enumeration of UUID-format IDs, exploitation of a separate public chatflow information-disclosure issue that leaks credential references, or by observing network traffic if partial access to the UI is available.
3. Call the unauthenticated endpoint: Send an unauthenticated HTTP POST request to the target:

   POST /api/v1/oauth2-credential/refresh/<credentialId> HTTP/1.1
   Host: <flowise-host>
   Content-Type: application/json

4. Receive the access token: The server decrypts the stored credential, contacts the OAuth provider using the victim's clientSecret and refresh_token, and returns the new access_token in the JSON response body under tokenInfo.access_token.
5. Access the victim's connected service: Use the stolen access_token as a Bearer token to authenticate against the victim's Google, Microsoft, GitHub, or other connected OAuth service and perform unauthorized actions.
6. Optional — DoS via token exhaustion: Repeatedly call the endpoint to exhaust the OAuth provider's refresh-token quota, locking the legitimate user out of their connected service (GitHub Advisory).

• Network: Repeated unauthenticated POST requests to /api/v1/oauth2-credential/refresh/<uuid> from external or unexpected IP addresses; absence of a session cookie or Authorization header in these requests.
• Network: Outbound OAuth token refresh requests from the Flowise server to OAuth provider endpoints (e.g., accounts.google.com/o/oauth2/token, login.microsoftonline.com/*/oauth2/token) at unusual times or frequencies not correlated with legitimate user activity.
• Logs: Flowise access logs showing POST /api/v1/oauth2-credential/refresh/ with HTTP 200 responses from unauthenticated sources (no session or API key present).
• Logs: High-frequency refresh calls to the same credentialId within a short time window, potentially indicating token quota exhaustion attempts.
• Logs: OAuth provider audit logs showing token issuance events from the Flowise server IP at times inconsistent with legitimate user sessions (GitHub Advisory).

Upgrade Flowise to version 3.1.3 or later, which removes the OAuth2 refresh endpoint from WHITELIST_URLS and enforces authentication on the route (GitHub Advisory). As an interim workaround for deployments that cannot immediately upgrade, restrict network access to the Flowise API (e.g., via firewall rules or reverse-proxy ACLs) so that only authenticated internal clients can reach the /api/v1/oauth2-credential/refresh/ path. Additionally, consider revoking and rotating all OAuth credentials stored in Flowise if the instance was publicly accessible while running a vulnerable version, and audit OAuth provider logs for unexpected token issuance events.

The vulnerability was discovered and reported by Shinobi Security (GitHub: shinobisecurity) and credited to DeathsPirate in the advisory (GitHub Advisory). The Flowise repository was archived by its owner on August 13, 2026, shortly after the advisory was published, which may signal a broader project status change. Security monitoring services including Tenable Cloud Security (plugin 445667), VulDB, and Offseq Radar picked up the advisory shortly after publication. A post on Infosec.Exchange noted the issue, and aggregators such as OSV.dev and GitLab Advisories also indexed the vulnerability (GitHub Advisory).