GHSA-w47f-j8rh-wx87: Flowise: credential exposure via public chatflow API

### 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

An attacker targeting an organization's AI-powered customer service chatbot identifies the underlying Flowise instance via Shodan, Censys, or by inspecting the chatbot widget's network requests, which typically reveal the Flowise base URL. The attacker navigates to the public chat interface, observes that it loads configuration via `/api/v1/public-chatbotConfig/{uuid}`, and makes a parallel request to `/api/v1/public-chatflows/{uuid}` using the same UUID. The response contains the full flowData JSON including the OpenAI API key used for the LLM node, a credential ID referencing stored OAuth tokens for a connected Google Drive or Slack integration, and the connection string for a PostgreSQL vector database. The attacker immediately begins using the exfiltrated OpenAI API key to run inference at the victim's expense (cost harvesting) while simultaneously using the OAuth credential ID — if Flowise's credential decryption endpoint is also accessible — to retrieve a live OAuth token for lateral movement into the victim's Google Workspace or Slack environment. The entire attack from discovery to credential exfiltration takes under five minutes and leaves no abnormal application errors in the Flowise logs.