Flowise: information disclosure
Summary
The GET /api/v1/public-chatflows/:id endpoint returns the full chatflow object without sanitization for public chatflows. Docker validation revealed this is worse than initially assessed: the sanitizeFlowDataForPublicEndpoint function does NOT exist in the released v3.0.13 Docker image. Both public-chatflows AND public-chatbotConfig return completely raw flowData including credential IDs, plaintext API keys, and password-type fields.
Root Cause
```typescript
// packages/server/src/controllers/chatflows/index.ts:218-220
const chatflow = await chatflowsService.getChatflowById(req.params.id)
if (!chatflow) return res.status(StatusCodes.NOT_FOUND).json(...)
if (chatflow.isPublic) return res.status(StatusCodes.OK).json(chatflow) // ← NO sanitization!
`
Docker Validation (v3.0.13)
Created public chatflow with credential IDs and passwords in flowData:
```json
{
"flowData": "{\"nodes\":[{\"data\":{\"credential\":\"e92a39bf-...\",\"inputs\":{\"password\":\"sk-supersecretkey123\",\"apiKey\":\"should-not-leak\"}}}]}"
}
`
The sanitizeFlowDataForPublicEndpoint function only exists in unreleased HEAD, and even there, only public-chatbotConfig calls it , public-chatflows never does.
Impact
- Credential IDs leaked , enables OAuth2 token theft chain (Finding 1)
- Plaintext API keys and passwords leaked , direct third-party...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| flowise npm | < 3.1.0 | 3.1.0 |
Details and references
### Summary The `GET /api/v1/public-chatflows/:id` endpoint returns the full chatflow object **without sanitization** for public chatflows. Docker validation revealed this is worse than initially assessed: the `sanitizeFlowDataForPublicEndpoint` function does NOT exist in the released v3.0.13 Docker image. Both `public-chatflows` AND `public-chatbotConfig` return completely raw flowData including credential IDs, plaintext API keys, and password-type fields. ### Root Cause ```typescript // packages/server/src/controllers/chatflows/index.ts:218-220 const chatflow = await chatflowsService.getChatflowById(req.params.id) if (!chatflow) return res.status(StatusCodes.NOT_FOUND).json(...) if (chatflow.isPublic) return res.status(StatusCodes.OK).json(chatflow) // ← NO sanitization! ``` ### Docker Validation (v3.0.13) Created public chatflow with credential IDs and passwords in flowData: ```json { "flowData": "{\"nodes\":[{\"data\":{\"credential\":\"e92a39bf-...\",\"inputs\":{\"password\":\"sk-supersecretkey123\",\"apiKey\":\"should-not-leak\"}}}]}" } ``` The `sanitizeFlowDataForPublicEndpoint` function only exists in unreleased HEAD, and even there, only `public-chatbotConfig` calls it , `public-chatflows` never does. ### Impact - **Credential IDs** leaked , enables OAuth2 token theft chain (Finding 1) - **Plaintext API keys and passwords** leaked , direct third-party account compromise - **Node configurations** leaked , reveals internal architecture and endpoint URLs - Both `public-chatflows` and `public-chatbotConfig` are affected in the released version ### Suggested Fix Apply sanitization to both public endpoints: ```typescript const sanitized = sanitizeFlowDataForPublicEndpoint(chatflow) return res.status(StatusCodes.OK).json(sanitized) ``` Ensure the sanitization function strips all `credential`, `password`, `apiKey`, and `secretKey` fields from `flowData`. --- ## References - `packages/server/src/controllers/chatflows/index.ts` lines 209-236 - `packages/server/src/utils/sanitizeFlowData.ts` lines 11-34 (exists only in unreleased HEAD) ## Credits - Shinobi Security - https://github.com/shinobisecurity
- CVSS 3.1
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
- Severity from
- GitHub (reviewed advisory)
- Weakness
- CWE-200
- Also known as
- CVE-2026-41278