Flowise CVE-2026-56277

Three concurrent conditions are required: (1) the victim must have an active authenticated session to a Flowise instance, (2) the victim must visit an attacker-controlled webpage while that session is live, and (3) the Flowise TTS endpoint must be reachable from the victim's browser - either via public internet or a shared network the victim accesses. Because the wildcard header is set unconditionally in the TTS controller regardless of server configuration, no non-default Flowise setting is needed - every Flowise deployment before 3.1.2 with an accessible TTS endpoint is vulnerable. Exploitation is strictly limited to browser-initiated requests: server-to-server and CLI callers are unaffected since CORS is a browser enforcement mechanism only. It should be noted that standard browser behavior prevents cookies from being sent cross-origin to wildcard CORS origins (Access-Control-Allow-Credentials: true is incompatible with *); the precise mechanism by which stored credentials are abused in this attack is not fully explained in the available advisory and warrants vendor clarification.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, score 6.9) rates this as network-exploitable with no prerequisites, but the UI:N designation is inconsistent with the described attack: drive-by CORS exploitation inherently requires a victim user to visit an attacker-controlled webpage, which maps to UI:P (passive) in CVSS 4.0 and UI:R in CVSS 3.1 - the provided score likely overstates exploitability as a result. The vulnerability is absent from CISA KEV, no EPSS data was provided, and no POC has been publicly identified, placing this firmly in the 'no public exploit identified at time of analysis' tier. Practical risk is most elevated for internet-facing Flowise instances where the TTS endpoint invokes billable third-party TTS APIs, as attackers could drain API quota or credits. The scope-unchanged vector confirms blast radius is limited to the Flowise application itself, not the underlying host. For internal-only deployments protected by network controls, exploitability is substantially reduced.

An attacker registers a public domain and serves a webpage containing JavaScript that issues a fetch() to a victim's Flowise TTS endpoint (e.g., https://flowise.example.com/api/v1/text-to-speech). When an authenticated Flowise user is socially engineered into visiting the attacker's page, the browser sends a cross-origin request; the hardcoded Access-Control-Allow-Origin: * permits the response to be read, and TTS generation is triggered using the victim's active session context, potentially abusing third-party TTS API credentials or quota. No POC exploit code has been publicly identified, but successful exploitation requires only standard fetch() API knowledge.