Monitor vulnerabilities like this one. Sign up free to get alerted when software you use is affected.
7.7

Flowise: Unauthenticated Access to Sensitive Chatflow Data

GHSA-6f7g-v4pp-r667
Summary

Flowise, a chatbot platform, allows unauthenticated access to chatflow configurations, which can reveal internal workflow data and OAuth credential identifiers. This can be used to obtain valid OAuth 2.0 access tokens without authentication. To fix this, Flowise needs to implement proper authentication and authorization for all endpoints that return sensitive data.

What to do
  • Update henryheng flowise to version 3.1.0.
Affected software
Ecosystem VendorProductAffected versions
npm henryheng flowise <= 3.0.13
Fix: upgrade to 3.1.0
Original title
Flowise: Unauthenticated OAuth 2.0 Access Token Disclosure via Public Chatflow in Flowise
Original description
### Summary
Flowise contains an authentication bypass vulnerability that allows an unauthenticated attacker to obtain OAuth 2.0 access tokens associated with a public chatflow.

By accessing a public chatflow configuration endpoint, an attacker can retrieve internal workflow data, including OAuth credential identifiers, which can then be used to refresh and obtain valid OAuth 2.0 access tokens without authentication.

### Details
Flowise is designed to allow public chatflows to be accessed by unauthenticated end users via public URLs or embedded widgets. As a result, `chatflowId` values are intentionally exposed to unauthenticated clients and must not be treated as secrets.

However, the endpoint `GET /api/v1/public-chatbotConfig/<chatflowId>` returns internal `flowData` without authentication. The returned `flowData` includes workflow node definitions containing OAuth credential identifiers (`credential` field).

Separately, the endpoint `POST /api/v1/oauth2-credential/refresh/<credentialId>` allows OAuth. 2.0 tokens to be refreshed without authentication or authorization checks.

Because credential identifiers can be obtained from the unauthenticated public chatflow configuration endpoint, these two behaviors can be combined to allow unauthenticated OAuth 2.0 access token disclosure.

### PoC
**Prerequisites**
- Self-hosted Flowise instance
- A public chatflow configured with an OAuth 2.0 credential (e.g., Gmail OAuth2)

#### Step 1: Obtain `chatflowId`
The `chatflowId` is exposed to unauthenticated users via public chatflow URLs, embedded widgets, or browser network requests when accessing a public chatflow.

Example: `d37b9812-72c1-4c64-b152-665f307f755e`

#### Step 2: Retrieve internal `flowData` without authentication

```bash
curl -s \
http://localhost:3000/api/v1/public-chatbotConfig/d37b9812-72c1-4c64-b152-665f307f755e
```

The response includes flowData containing an OAuth credential identifier, for example:

```
"credential": "6efe0e20-ba6f-4fbb-9960-658feffa0542"
```

#### Step 3: Refresh OAuth 2.0 token without authentication

```bash
curl -X POST \
http://localhost:3000/api/v1/oauth2-credential/refresh/6efe0e20-ba6f-4fbb-9960-658feffa0542
```

The response returns valid OAuth 2.0 access token data, including an `access_token`.

### Impact
An unauthenticated attacker can obtain OAuth 2.0 access tokens for third-party services configured in Flowise, potentially leading to unauthorized data access, API abuse, or account compromise.

This vulnerability affects self-hosted deployments because public chatflows are commonly exposed to the internet and require unauthenticated access by design. Treating `chatflowId` as a secret does not mitigate the issue.
ghsa CVSS4.0 7.7
Vulnerability type
CWE-306 Missing Authentication for Critical Function
Published: 16 Apr 2026 · Updated: 16 Apr 2026 · First seen: 16 Apr 2026