GHSA-w47f-j8rh-wx87 — flowise
HIGHGHSA-w47f-j8rh-wx87 is a high-severity (CVSS 7.5) Information Exposure vulnerability in flowise. A fix is available for flowise — see the affected versions and patch details below.
Flowise: Public chatflow endpoints return unsanitized flowData including plaintext API keys, passwords, and credential IDs
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-w47f-j8rh-wx87.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-w47f-j8rh-wx87 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,333 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
flowisenpmDescription
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-chatflowsandpublic-chatbotConfigare 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.tslines 209-236packages/server/src/utils/sanitizeFlowData.tslines 11-34 (exists only in unreleased HEAD)
Credits
- Shinobi Security - https://github.com/shinobisecurity
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | flowise | all versions | 3.1.0npm install flowise@3.1.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for flowise, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update flowise to 3.1.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w47f-j8rh-wx87 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-w47f-j8rh-wx87 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-w47f-j8rh-wx87. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-w47f-j8rh-wx87 in your dependencies?
O3 Security finds GHSA-w47f-j8rh-wx87 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.