CVE-2026-69250: Flowise unauthenticated SSRF leaks

Q: Is CVE-2026-69250 actively exploited?

No confirmed active exploitation of CVE-2026-69250 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-69250?

1) Upgrade to Flowise 3.1.3 or later immediately — this is the primary and only complete fix. 2) If upgrading is delayed, restrict network access to the `/api/v1/oauth2-credential/refresh/:credentialId` path via reverse proxy/WAF rule or require authentication at the network layer. 3) Rotate all OAuth2 client secrets and refresh tokens configured in any internet-reachable Flowise instance, since they may have already been exfiltrated. 4) Review outbound HTTP logs from Flowise hosts for POST requests to unexpected external domains, particularly around timestamps of unauthenticated hits to the refresh endpoint. 5) Where feasible, restrict the accessTokenUrl configuration to an allowlist of known-good OAuth provider domains to reduce SSRF blast radius even post-patch.

Q: What systems are affected by CVE-2026-69250?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, OAuth2/third-party integrations, low-code AI workflow builders.

Q: What is the CVSS score for CVE-2026-69250?

No CVSS score has been assigned yet.

CISO Take

Flowise's OAuth2 token refresh endpoint lets any unauthenticated caller force the server to make an outbound HTTP request to a URL the attacker fully controls, then reflects the full response back to them while also sending the stored client_id, client_secret, and refresh_token in the outbound request body. Any Flowise instance exposed to the internet or an untrusted network is affected regardless of user privileges, since the endpoint requires no authentication at all — this is a design flaw, not an edge case. The package has 158 other CVEs on record and this specific flaw has no CISA KEV listing, no public exploit, and no Nuclei template yet, but EPSS places it in the top 73% most-likely-to-be-exploited bracket, and CISA's SSVC decision is ATTEND, meaning it warrants timely remediation rather than emergency response. Patch to Flowise 3.1.3 immediately; if you can't patch now, block external access to `/api/v1/oauth2-credential/refresh/:credentialId` at the reverse proxy or firewall and rotate any OAuth2 credentials stored in affected Flowise instances since they may already be compromised. Detection teams should hunt for outbound POST requests from Flowise hosts to unfamiliar external domains around the time of any unauthenticated hits on that refresh path.

Sources: NVD GitHub Advisory EPSS ATLAS

What is the risk?

High practical risk despite the absence of a CVSS score: the flaw combines missing authentication, SSRF (attacker-controlled URL), and direct credential exfiltration (client_secret, refresh_token) in a single unauthenticated request — a low-complexity, no-privilege, no-user-interaction attack chain. The EPSS top-73%-percentile ranking indicates meaningful real-world exploitation interest even though no public PoC or scanner template exists yet, and Flowise's track record of 158 prior CVEs suggests it is a frequent target for opportunistic scanning. Exposure is highest for self-hosted or misconfigured multi-tenant Flowise deployments reachable from the internet, where any OAuth2-integrated credential (Google, Slack, GitHub, custom APIs, etc.) configured in the platform is at risk of theft.

How does the attack unfold?

Initial Access

Attacker locates an internet-exposed Flowise instance and identifies an existing OAuth2 credential ID configured for a third-party integration.

AML.T0049

Exploitation

Attacker sends an unauthenticated POST to the OAuth2 token refresh endpoint, causing the server to make an SSRF request to an attacker-controlled accessTokenUrl.

AML.T0049

Credential Theft

The server sends client_id, client_secret, and refresh_token to the attacker's server and reflects the attacker's crafted response back to the caller.

AML.T0055

Impact

Attacker uses the stolen OAuth2 credentials to access the connected third-party service (email, storage, repos, etc.) as if they were the legitimate integration.

AML.T0083

Initial Access

Attacker locates an internet-exposed Flowise instance and identifies an existing OAuth2 credential ID configured for a third-party integration.

AML.T0049

Exploitation

Attacker sends an unauthenticated POST to the OAuth2 token refresh endpoint, causing the server to make an SSRF request to an attacker-controlled accessTokenUrl.

AML.T0049

Credential Theft

The server sends client_id, client_secret, and refresh_token to the attacker's server and reflects the attacker's crafted response back to the caller.

AML.T0055

Impact

Attacker uses the stolen OAuth2 credentials to access the connected third-party service (email, storage, repos, etc.) as if they were the legitimate integration.

AML.T0083

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?

CVSS 3.1

N/A

EPSS

0.4%

chance of exploitation in 30 days

Higher than 34% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What should I do?

1 step

1) Upgrade to Flowise 3.1.3 or later immediately — this is the primary and only complete fix. 2) If upgrading is delayed, restrict network access to the /api/v1/oauth2-credential/refresh/:credentialId path via reverse proxy/WAF rule or require authentication at the network layer. 3) Rotate all OAuth2 client secrets and refresh tokens configured in any internet-reachable Flowise instance, since they may have already been exfiltrated. 4) Review outbound HTTP logs from Flowise hosts for POST requests to unexpected external domains, particularly around timestamps of unauthenticated hits to the refresh endpoint. 5) Where feasible, restrict the accessTokenUrl configuration to an allowlist of known-good OAuth provider domains to reduce SSRF blast radius even post-patch.

What does CISA's SSVC say?

Decision Attend

Exploitation poc

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Data Leakage Agent Framework AML.T0049 - Exploit Public-Facing Application AML.T0055 - Unsecured Credentials AML.T0083 - Credentials from AI Agent Configuration

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

GOVERN 6.1 - Third-party risks are addressed

OWASP LLM Top 10

LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-69250?

Flowise's OAuth2 token refresh endpoint lets any unauthenticated caller force the server to make an outbound HTTP request to a URL the attacker fully controls, then reflects the full response back to them while also sending the stored client_id, client_secret, and refresh_token in the outbound request body. Any Flowise instance exposed to the internet or an untrusted network is affected regardless of user privileges, since the endpoint requires no authentication at all — this is a design flaw, not an edge case. The package has 158 other CVEs on record and this specific flaw has no CISA KEV listing, no public exploit, and no Nuclei template yet, but EPSS places it in the top 73% most-likely-to-be-exploited bracket, and CISA's SSVC decision is ATTEND, meaning it warrants timely remediation rather than emergency response. Patch to Flowise 3.1.3 immediately; if you can't patch now, block external access to `/api/v1/oauth2-credential/refresh/:credentialId` at the reverse proxy or firewall and rotate any OAuth2 credentials stored in affected Flowise instances since they may already be compromised. Detection teams should hunt for outbound POST requests from Flowise hosts to unfamiliar external domains around the time of any unauthenticated hits on that refresh path.

Is CVE-2026-69250 actively exploited?

No confirmed active exploitation of CVE-2026-69250 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-69250?

1) Upgrade to Flowise 3.1.3 or later immediately — this is the primary and only complete fix. 2) If upgrading is delayed, restrict network access to the `/api/v1/oauth2-credential/refresh/:credentialId` path via reverse proxy/WAF rule or require authentication at the network layer. 3) Rotate all OAuth2 client secrets and refresh tokens configured in any internet-reachable Flowise instance, since they may have already been exfiltrated. 4) Review outbound HTTP logs from Flowise hosts for POST requests to unexpected external domains, particularly around timestamps of unauthenticated hits to the refresh endpoint. 5) Where feasible, restrict the accessTokenUrl configuration to an allowlist of known-good OAuth provider domains to reduce SSRF blast radius even post-patch.

What systems are affected by CVE-2026-69250?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, OAuth2/third-party integrations, low-code AI workflow builders.

What is the CVSS score for CVE-2026-69250?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksOAuth2/third-party integrationslow-code AI workflow builders

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0055 Unsecured Credentials

AML.T0083 Credentials from AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: GOVERN 6.1

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, the OAuth2 token refresh endpoint POST /api/v1/oauth2-credential/refresh/:credentialId is unauthenticated by design and performs a server-side HTTP request to the credential-controlled accessTokenUrl without SSRF protections. Runtime validation confirmed that the endpoint was reachable without authentication, triggered outbound POST requests to an attacker-controlled server, reflected the full remote response body to the caller through tokenInfo, and sent client_id, client_secret, grant_type=refresh_token, and refresh_token in the request body. This issue is fixed in version 3.1.3.

Exploitation Scenario

An attacker scans the internet for exposed Flowise instances (a common target given its popularity as a self-hosted LLM app builder) and identifies one with an existing OAuth2 credential configured for an integration such as Google or Slack. Without authenticating, the attacker sends a POST request to `/api/v1/oauth2-credential/refresh/:credentialId`, having first set (or guessed/enumerated) the credential's accessTokenUrl to point at a server they control. Flowise's backend dutifully makes the outbound request, sending the real client_id, client_secret, and refresh_token to the attacker's server, and reflects whatever response the attacker's server sends back through tokenInfo. The attacker now holds live OAuth2 credentials for whatever service was integrated, which they can use to access connected mailboxes, drives, repositories, or other systems as if they were the legitimate Flowise-integrated application — all without ever authenticating to Flowise itself.

Weaknesses (CWE)

CWE-639 Authorization Bypass Through User-Controlled Key Primary CWE-639 Authorization Bypass Through User-Controlled Key Primary CWE-639 Authorization Bypass Through User-Controlled Key

CWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

[Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
[Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Source: MITRE CWE corpus.