CVE-2026-56268 — flowise
CVE-2026-56268 is a CWE-863 vulnerability in flowise. A fix is available for flowise — see the affected versions and patch details below.
Flowise - Cross-Workspace Information Disclosure via chatflows/apikey Endpoint
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-56268.
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.
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 /api/v1/chatflows/apikey/:apikey endpoint (whitelisted, accessible with API key auth only) returns all chatflows bound to the provided API key AND all chatflows across the entire system that have no API key assigned. This crosses workspace boundaries, allowing a user in Workspace A who has a valid API key to read the full configuration (including flowData, chatbotConfig, system prompts, and node configurations) of chatflows from Workspace B, Workspace C, and all other workspaces, as long as those chatflows have no API key assigned.
Details
The controller at packages/server/src/controllers/chatflows/index.ts:90-107 validates the API key and calls the service:
const getChatflowByApiKey = async (req: Request, res: Response, next: NextFunction) => {
try {
const apikey = await apiKeyService.getApiKey(req.params.apikey)
if (\!apikey) {
return res.status(401).send("Unauthorized")
}
const apiResponse = await chatflowsService.getChatflowByApiKey(apikey.id, req.query.keyonly)
return res.json(apiResponse) // Returns full chatflow objects with flowData
} catch (error) {
next(error)
}
}
The service at packages/server/src/services/chatflows/index.ts:223-245 builds the database query:
const getChatflowByApiKey = async (apiKeyId: string, keyonly?: unknown): Promise<any> => {
const appServer = getRunningExpressApp()
let query = appServer.AppDataSource.getRepository(ChatFlow)
.createQueryBuilder("cf")
.where("cf.apikeyid = :apikeyid", { apikeyid: apiKeyId })
if (keyonly === undefined) {
// When keyonly is not set (default), also return ALL chatflows with no API key
query = query.orWhere("cf.apikeyid IS NULL").orWhere("cf.apikeyid = ''")
}
const dbResponse = await query.orderBy("cf.name", "ASC").getMany()
return dbResponse // Returns full ChatFlow entities including flowData
}
When keyonly is not provided as a query parameter (which is the default case), the query expands to include:
- All chatflows bound to the provided API key (same workspace, expected behavior)
- ALL chatflows with
apikeyid IS NULL(any workspace, no workspace filter) - ALL chatflows with empty
apikeyid(any workspace, no workspace filter)
There is NO workspaceId filter in this query. The response includes the full ChatFlow entity, which contains:
flowData- the complete workflow graph including system prompts, model names, internal URLs, custom codechatbotConfig- chatbot configuration including allowed originsapiConfig- API configuration and override settingstextToSpeech/speechToText- TTS/STT configuration including credential IDsanalytic- analytics configuration
PoC
# Step 1: Attacker has a valid API key for Workspace A
API_KEY="<attacker-workspace-a-api-key>"
# Step 2: Query the chatflows/apikey endpoint WITHOUT keyonly parameter
# Returns the attacker chatflows PLUS all chatflows without API keys from ALL workspaces
curl -s "http://localhost:3000/api/v1/chatflows/apikey/" | jq ".[].workspaceId"
# Step 3: With keyonly parameter, only chatflows bound to the API key are returned
curl -s "http://localhost:3000/api/v1/chatflows/apikey/?keyonly=true" | jq ".[].workspaceId"
Impact
- Cross-Workspace Information Disclosure: A user in any workspace can read the full configuration of chatflows from all other workspaces that do not have an API key assigned. This breaks workspace isolation.
- Intellectual Property Exposure: System prompts, custom function code, and workflow architecture of chatflows from other workspaces/organizations are exposed.
- Credential Reference Leakage: The
textToSpeechandspeechToTextfields include credential IDs, which can be abused via the TTS generate endpoint. - Amplified by Default: Most chatflows are created without an API key assigned (API keys are opt-in), so the majority of chatflows in a multi-workspace deployment are affected.
Recommended Fix
Add workspace scoping to the getChatflowByApiKey query by passing the API key workspace ID and filtering the OR clause:
// packages/server/src/services/chatflows/index.ts
const getChatflowByApiKey = async (apiKeyId: string, keyonly?: unknown, workspaceId?: string): Promise<any> => {
const appServer = getRunningExpressApp()
let query = appServer.AppDataSource.getRepository(ChatFlow)
.createQueryBuilder("cf")
.where("cf.apikeyid = :apikeyid", { apikeyid: apiKeyId })
if (keyonly === undefined && workspaceId) {
// Only include unprotected chatflows from the SAME workspace
query = query.orWhere(
"(cf.apikeyid IS NULL OR cf.apikeyid = :empty) AND cf.workspaceId = :workspaceId",
{ empty: "", workspaceId }
)
}
const dbResponse = await query.orderBy("cf.name", "ASC").getMany()
return dbResponse
}
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | flowise | all versions | 3.1.2npm install flowise@3.1.2 |
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.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-56268 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 CVE-2026-56268 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-56268. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-56268 in your dependencies?
O3 Security finds CVE-2026-56268 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.