AI Threat AlertCVE-2026-70474: Flowise: missing workspace auth in OAuth2 credential routes
GHSA-wch5-xp77-fxg4HIGHPoC AVAILABLECISA: ATTENDFlowise versions up to 3.1.2 expose three OAuth2 credential endpoints (authorize, callback, refresh) that look up credentials by ID alone, with no workspace check, and the callback and refresh routes require no authentication at all. An unauthenticated attacker who knows or obtains a credential UUID can overwrite the stored OAuth2 tokens with their own or force token refreshes, and any logged-in user can start OAuth2 flows against other tenants' credentials. This matters because Flowise credentials typically unlock downstream SaaS, data, and LLM provider accounts, so token hijacking can pivot into connected business systems. Exploitation likelihood is moderate (EPSS 0.48%, top 61%), but a public PoC exists, CISA SSVC rates it ATTEND, and it is not in KEV; the main barrier is learning a victim credential UUID. Upgrade to Flowise 3.1.3 or later, and until then block /api/v1/oauth2-credential/* at the reverse proxy and rotate any OAuth2 tokens held by multi-tenant instances.
What is the risk?
High. The flaw is an incorrect authorization issue (CWE-863) reachable over the network, with unauthenticated access to the callback and refresh routes. A public PoC exists and CISA SSVC says ATTEND, but EPSS is low (0.48%, top 61%) and there is no KEV listing or Nuclei template. Exploitation requires the target credential's UUID, which is a random identifier and so reduces opportunistic mass exploitation. Risk is highest for multi-workspace or internet-exposed Flowise deployments, where credentials guard sensitive third-party integrations. Impact is mainly confidentiality and integrity of stored OAuth2 credentials; the CVSS score was not provided, so severity is taken from the vendor's high rating.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Flowise | npm | <= 3.1.2 | 3.1.3 |
Do you use Flowise? You're affected.
How severe is it?
What should I do?
1 step1) Upgrade Flowise (npm package flowise) to 3.1.3 or later. 2) Until patched, block or restrict /api/v1/oauth2-credential/authorize, /callback, and /refresh at the reverse proxy or WAF, or restrict Flowise to trusted networks and VPN. 3) Rotate and re-authorize OAuth2 credentials in multi-tenant instances, and revoke tokens at the identity providers if tampering is suspected. 4) Review access logs for unauthenticated requests to the callback and refresh routes, especially with unfamiliar code values or state parameters containing credential UUIDs. 5) Check OAuth provider audit logs for unexpected token grants or new authorized sessions tied to Flowise client IDs. 6) Apply least privilege to scopes granted to Flowise integrations.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-70474?
Flowise versions up to 3.1.2 expose three OAuth2 credential endpoints (authorize, callback, refresh) that look up credentials by ID alone, with no workspace check, and the callback and refresh routes require no authentication at all. An unauthenticated attacker who knows or obtains a credential UUID can overwrite the stored OAuth2 tokens with their own or force token refreshes, and any logged-in user can start OAuth2 flows against other tenants' credentials. This matters because Flowise credentials typically unlock downstream SaaS, data, and LLM provider accounts, so token hijacking can pivot into connected business systems. Exploitation likelihood is moderate (EPSS 0.48%, top 61%), but a public PoC exists, CISA SSVC rates it ATTEND, and it is not in KEV; the main barrier is learning a victim credential UUID. Upgrade to Flowise 3.1.3 or later, and until then block /api/v1/oauth2-credential/* at the reverse proxy and rotate any OAuth2 tokens held by multi-tenant instances.
Is CVE-2026-70474 actively exploited?
Proof-of-concept exploit code is publicly available for CVE-2026-70474, increasing the risk of exploitation.
How to fix CVE-2026-70474?
1) Upgrade Flowise (npm package flowise) to 3.1.3 or later. 2) Until patched, block or restrict /api/v1/oauth2-credential/authorize, /callback, and /refresh at the reverse proxy or WAF, or restrict Flowise to trusted networks and VPN. 3) Rotate and re-authorize OAuth2 credentials in multi-tenant instances, and revoke tokens at the identity providers if tampering is suspected. 4) Review access logs for unauthenticated requests to the callback and refresh routes, especially with unfamiliar code values or state parameters containing credential UUIDs. 5) Check OAuth provider audit logs for unexpected token grants or new authorized sessions tied to Flowise client IDs. 6) Apply least privilege to scopes granted to Flowise integrations.
What systems are affected by CVE-2026-70474?
This vulnerability affects the following AI/ML architecture patterns: Agent frameworks, LLM orchestration platforms, Multi-tenant AI workflow builders, Tool-integrated agents using OAuth2 connectors.
What is the CVSS score for CVE-2026-70474?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0049Exploit Public-Facing ApplicationAML.T0083Credentials from AI Agent ConfigurationAML.T0091.000Application Access TokenAML.T0106Exploitation for Credential AccessCompliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
An attacker finds an internet-exposed Flowise instance and obtains a victim credential UUID, for example from a leaked flow export, shared link, or a low-privileged account on the same instance. They send a forged request to /api/v1/oauth2-credential/callback with their own authorization code and the victim UUID as state, which overwrites the stored tokens with tokens tied to the attacker's account. Agent flows that use that credential now read from or write to the attacker's account, which exposes data and lets the attacker influence flow behavior. They can also call the refresh endpoint to manipulate or disrupt token state without authenticating.
Weaknesses (CWE)
CWE-863Incorrect AuthorizationPrimaryCWE-863Incorrect AuthorizationPrimaryCWE-863Incorrect AuthorizationCWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
- [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2025-7133810.0Flowise: unauthenticated file write enables RCE
Same package: flowiseCVE-2025-5952810.0Flowise: Unauthenticated RCE via MCP config injection
Same package: flowiseCVE-2025-619139.9Flowise: path traversal in file tools leads to RCE
Same package: flowiseCVE-2026-409339.9Flowise: RCE via MCP stdio command injection
Same package: flowiseCVE-2026-464429.9Flowise: sandbox escape enables authenticated RCE
Same package: flowise