Skip to content

GHSA-w47f-j8rh-wx87 CVE-2026-41278

Flowise: Public chatflow endpoints return unsanitized flowData including plaintext API keys, passwords, and credential IDs

High npm
Severity
0.0 / 10
High · CVSS 4.0
Exploit chance (EPSS)
0.42%
Chance of exploitation in the next 30 days. Higher than 36.43% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
Fix
3.1.0
Upgrade flowise to this version or later

Description

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

// 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:

{
  "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:

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

Affected versions

npm

PackageVulnerableFixed in
flowise
< 3.1.0
3.1.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

flowise npm → 3.1.0

npm
npm install flowise@3.1.0
yarn
yarn add flowise@3.1.0
pnpm
pnpm add flowise@3.1.0

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Attack vector
Network
Attack complexity
Low
Attack requirements
None
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
High
Integrity (vulnerable system)
None
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

CVSS 3.1 7.5

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

Weakness

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

How to prevent it
  • Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-w7x8-q2gp-5cgg
Flowise Prompt Injection to RCE and SSRF via CSV/Airtable Agent Python Validator Bypass
Critical Also affects flowise
GHSA-9gvv-qjj3-2p6g
Flowise NodeVM sandbox escape via puppeteer allowlist - authenticated RCE and arbitrary file read via Chromium
High Also affects flowise
GHSA-qgvm-j2hm-6m38
Flowise: Unauthenticated OAuth2 token refresh endpoint returns access tokens — enables token theft for any connected service
Critical Also affects flowise
GHSA-5xvg-pmgg-3mxr
Flowise: CSV Agent Prompt Injection Remote Code Execution Vulnerability
Critical Also affects flowise
GHSA-gmmw-qg98-6j6p
Flowise: Broken Access Control in Stripe Subscription Endpoints Allows Cross-Tenant Billing Manipulation
High Also affects flowise
GHSA-8gj2-2cvc-6xx7
Flowise: Unauthenticated Credential Abuse via Text-to-Speech Endpoint Allows Unauthorized Use of Private Chatflow TTS Credentials
Medium Also affects flowise
GHSA-fm2f-4339-4p2f
Flowise: Missing Authorization on Execution Update Endpoint
Medium Also affects flowise
GHSA-wch5-xp77-fxg4
Flowise: Cross-Workspace OAuth2 Credential Metadata Leak
High Also affects flowise
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor