CVE-2026-70474 in Flowise
Summary
by MITRE • 08/04/2026
Flowise is a drag-and-drop user interface for building customized large language model (LLM) flows. Prior to 3.1.3, Flowise has three OAuth2 credential endpoints that look up credentials by id alone with no workspaceId filter. The authorize, callback, and refresh handlers query the Credential table by id only; callback and refresh are whitelisted from authentication. This allows any authenticated user to initiate OAuth2 flows against credentials belonging to other workspaces, allows an unauthenticated attacker to forge OAuth2 callbacks to overwrite tokens in any credential, and allows an unauthenticated attacker to refresh tokens for any credential. The affected routes include /api/v1/oauth2-credential/authorize/<VICTIM_CREDENTIAL_UUID>, /api/v1/oauth2-credential/callback?code=ATTACKER_AUTH_CODE&state=<VICTIM_CREDENTIAL_UUID>, and /api/v1/oauth2-credential/refresh/<VICTIM_CREDENTIAL_UUID>. This issue is fixed in version 3.1.3.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/04/2026
This vulnerability in Flowise versions prior to 3.1.3 represents a critical authorization flaw that undermines the security boundaries between user workspaces through improper credential handling in OAuth2 flows. The vulnerability stems from three specific endpoints - authorize, callback, and refresh - that retrieve credentials solely based on identifier without validating workspace ownership. This design flaw creates a path for privilege escalation where authenticated users can access credentials belonging to other workspaces, while unauthenticated attackers can exploit the lack of proper authentication checks to manipulate OAuth2 tokens across different credential instances. The issue specifically affects the credential lookup mechanism in the database layer, where the system performs queries against the Credential table using only the credential id parameter without any workspaceId filtering or ownership validation.
The technical implementation of this vulnerability exposes a fundamental breakdown in access control mechanisms within the application's authentication flow architecture. When the authorize endpoint processes requests, it accepts a credential UUID parameter and retrieves the corresponding credential record from the database without verifying that the requesting user has legitimate access to that specific credential. Similarly, the callback and refresh endpoints operate with the same dangerous pattern, where they accept credential identifiers in their URL paths or query parameters without validating the relationship between the credential and the requesting user's workspace context. The whitelisting of callback and refresh handlers from authentication requirements compounds this issue by removing any additional security layers that might otherwise prevent unauthorized token manipulation.
The operational impact of this vulnerability extends far beyond simple data exposure, creating a comprehensive attack surface that allows for token hijacking and cross-workspace credential theft. An authenticated attacker can leverage this flaw to initiate OAuth2 authorization flows against credentials in other workspaces, potentially gaining access to sensitive information or services protected by those credentials. Unauthenticated attackers can exploit the callback endpoint to forge OAuth2 responses with malicious authorization codes, effectively overwriting tokens in any credential within the system. The refresh endpoint provides another vector for attackers to silently update tokens across different credentials without requiring authentication, enabling persistent access to resources that should be restricted to specific workspace contexts. This vulnerability directly violates the principle of least privilege and creates opportunities for lateral movement within the application's user base.
The security implications of this vulnerability align with multiple CWE classifications including CWE-285 (Improper Authorization) and CWE-346 (Origin Validation Failure), as the system fails to properly validate the source and legitimacy of credential access requests. This issue also maps to several ATT&CK techniques, particularly those related to privilege escalation through credential manipulation and unauthorized access to resources. The vulnerability demonstrates a classic case of insufficient input validation combined with inadequate access control enforcement, where the application assumes that credential identifiers are sufficient for authorization decisions without proper context verification. Organizations using Flowise versions prior to 3.1.3 should immediately implement mitigations including immediate version upgrades to 3.1.3 or later, implementing additional authentication checks on credential endpoints, and conducting thorough audits of all OAuth2 integration points within their systems.
The fix implemented in version 3.1.3 addresses the root cause by introducing proper workspace context validation into the credential lookup mechanisms. This update ensures that all three vulnerable endpoints now verify that the requesting user has legitimate access to the specified credential before proceeding with any OAuth2 operations. The solution likely includes adding workspaceId parameters to the credential lookup queries, implementing role-based access controls for credential operations, and ensuring that authentication requirements are properly enforced on all OAuth2 handler endpoints. This remediation approach aligns with industry best practices for secure credential management and reinforces proper separation between user workspaces while maintaining functional OAuth2 capabilities within the application's legitimate use cases.