GHSA-4jpm-cgx2-8h37
HIGHGHSA-4jpm-cgx2-8h37 is a high-severity (CVSS 7.5) vulnerability in flowise. O3 Security confirms whether GHSA-4jpm-cgx2-8h37 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Flowise: Sensitive Data Leak in public-chatbotConfig
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.
flowisenpmDescription
Summary
/api/v1/public-chatbotConfig/:id ep exposes sensitive data including API keys, HTTP authorization headers and internal configuration without any authentication. An attacker with knowledge just of a chatflow UUID can retrieve credentials stored in password type fields and HTTP headers, leading to credential theft and more.
Details
Knowledge of chatflow UUID can be obtained from embedded chat widgets, referrer headers or logs and it's the only prerequest.
getSinglePublicChatbotConfig function in packages/server/src/services/chatflows/index.ts returns the full flowData object without authorization check or data sanitization.
There is a comment as "Safe as public endpoint as chatbotConfig doesn't contain sensitive credential" but flowData does contain sensitive data such as:
type: 'password' fields are stored in plaintext (unstructuredAPIKey in S3File node).
HTTP Authorization headers in POST / GET Requests nodes.
Internal API endpoints and webhook URLs.
PoC
- Add an S3 File node, set "File Processing Method" to "Unstructured".
- Enter an API key in "Unstructured API KEY" field or add a Requests Post node with Authorization header.
- Save the chatflow.
curl -s "https://localhost/api/v1/public-chatbotConfig/{CHATFLOW_UUID}"
Response:
{
"flowData": "{...\"unstructuredAPIKey\":\"victim_key\"...\"requestsPostHeaders\":\"Bearer victim_token\"...}"
}
Impact
Impacts all Flowise Cloud users with chatflows containing password type fields or any HTTP headers. And self hosted Flowise instances exposed to the internet.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | flowise | all versions | 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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update flowise to 3.1.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4jpm-cgx2-8h37 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 pinpoints whether GHSA-4jpm-cgx2-8h37 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-4jpm-cgx2-8h37. 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-4jpm-cgx2-8h37 in your dependencies?
O3 detects GHSA-4jpm-cgx2-8h37 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.