CVE-2026-70478 in Flowise
Summary
by MITRE • 08/04/2026
Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, the POST /api/v1/oauth2-credential/refresh/:credentialId endpoint is included in WHITELIST_URLS and requires no authentication. The endpoint decrypts the stored credential, sends a refresh request to the configured OAuth provider with the client secret and refresh token, and returns the refreshed access_token in the response body. An attacker with a credential ID can use the token to access the victim's connected service and can also exhaust refresh-token quota. This issue is fixed in 3.1.3.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/04/2026
The vulnerability in Flowise versions prior to 3.1.3 represents a critical authentication bypass flaw that directly impacts the security of OAuth2 credential management within the application. The affected endpoint POST /api/v1/oauth2-credential/refresh/:credentialId exists in the WHITELIST_URLS configuration without requiring any form of authentication, creating an unauthorized access vector for malicious actors. This design flaw allows attackers to exploit the endpoint using only a valid credential ID, bypassing the normal authentication mechanisms that should protect sensitive credential operations.
The technical implementation of this vulnerability stems from improper access control enforcement within the application's API routing system. When an attacker accesses the vulnerable endpoint with a known credential ID, the system automatically decrypts the stored OAuth2 credentials without verifying the requester's identity or authorization status. The endpoint then proceeds to contact the configured OAuth provider using the client secret and refresh token contained in the decrypted credentials, executing a refresh request that would normally require proper authentication. The response body contains the newly issued access_token, which can be immediately utilized by the attacker to gain unauthorized access to the victim's connected service.
The operational impact of this vulnerability extends beyond simple unauthorized access, creating significant risk for users who have integrated third-party services through Flowise. An attacker with knowledge of a credential ID can effectively impersonate the legitimate user and access their connected applications, potentially leading to data breaches, unauthorized transactions, or privilege escalation within those services. Additionally, the vulnerability enables resource exhaustion attacks where an attacker repeatedly invokes the refresh endpoint, consuming the victim's allocated refresh token quota and potentially causing service disruption for legitimate users.
This issue manifests as a clear violation of several cybersecurity principles including authentication enforcement and least privilege access control, aligning with CWE-285 which addresses improper authorization in security-critical functions. The vulnerability also maps to ATT&CK technique T1566.002 related to credential harvesting through phishing or other means, as attackers can leverage this flaw to extract usable credentials without requiring complex social engineering or exploitation techniques. The lack of authentication requirements for credential refresh operations directly contradicts the principle of secure API design where sensitive operations must be properly authenticated before execution.
The fix implemented in version 3.1.3 addresses this vulnerability by removing the endpoint from the WHITELIST_URLS configuration and enforcing proper authentication checks before allowing access to the OAuth2 credential refresh functionality. This remediation ensures that only authorized users with appropriate credentials can invoke the endpoint, preventing unauthorized access to sensitive OAuth2 tokens and protecting against both immediate exploitation and long-term credential abuse. Organizations using Flowise should immediately upgrade to version 3.1.3 or later to mitigate this risk and should also conduct thorough audits of their OAuth2 integrations to ensure proper access controls are maintained throughout their application infrastructure.