CVE-2026-41279: Flowise: unauth API key abuse via TTS endpoint IDOR
HIGH PoC AVAILABLEFlowise's text-to-speech endpoint is whitelisted without authentication and blindly trusts a caller-supplied credentialId to decrypt and invoke stored AI provider keys (OpenAI, ElevenLabs) — any unauthenticated party on the internet can trigger this with zero privileges. A public PoC already exists and EPSS places this in the top 83rd percentile for exploitation likelihood, meaning active abuse is plausible right now. The blast radius is financial and operational: attackers can silently drain AI API credits, exhaust provider rate limits, and disrupt production AI workflows without leaving any trace in Flowise auth logs since no login ever occurs. Upgrade to Flowise 3.1.0 immediately, rotate every stored third-party API credential as a precaution, and if patching is blocked, firewall POST /api/v1/text-to-speech/generate at the edge.
What is the risk?
High. Network-accessible with no authentication, no user interaction, and low attack complexity — combined with a public PoC and EPSS top-83rd-percentile ranking, this is effectively trivial for any attacker who can reach a Flowise instance. Flowise carries 58 prior CVEs in the same package, signaling systemic security debt rather than an isolated miss. Organizations running internet-facing Flowise deployments with stored AI provider credentials face immediate financial drain and potential service disruption with no authentication barrier in the way.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Flowise | npm | — | No patch |
Do you use Flowise? You're affected.
How severe is it?
What is the attack surface?
What should I do?
5 steps-
Upgrade to Flowise 3.1.0 immediately — the patch adds authentication to the TTS endpoint.
-
Rotate all stored third-party API credentials (OpenAI, ElevenLabs, etc.) in Flowise as a precaution, even post-patch, since there is no way to audit whether keys were abused prior to patching.
-
If immediate upgrade is blocked, restrict external access to POST /api/v1/text-to-speech/generate at your WAF or reverse proxy — allow only trusted internal IPs.
-
Enable spend alerts and usage anomaly notifications at your AI providers (OpenAI dashboard, ElevenLabs billing) to detect unauthorized TTS consumption.
-
Review Flowise audit logs for unexpected credentialId references and cross-reference with provider API call timestamps.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-41279?
Flowise's text-to-speech endpoint is whitelisted without authentication and blindly trusts a caller-supplied credentialId to decrypt and invoke stored AI provider keys (OpenAI, ElevenLabs) — any unauthenticated party on the internet can trigger this with zero privileges. A public PoC already exists and EPSS places this in the top 83rd percentile for exploitation likelihood, meaning active abuse is plausible right now. The blast radius is financial and operational: attackers can silently drain AI API credits, exhaust provider rate limits, and disrupt production AI workflows without leaving any trace in Flowise auth logs since no login ever occurs. Upgrade to Flowise 3.1.0 immediately, rotate every stored third-party API credential as a precaution, and if patching is blocked, firewall POST /api/v1/text-to-speech/generate at the edge.
Is CVE-2026-41279 actively exploited?
Proof-of-concept exploit code is publicly available for CVE-2026-41279, increasing the risk of exploitation.
How to fix CVE-2026-41279?
1. Upgrade to Flowise 3.1.0 immediately — the patch adds authentication to the TTS endpoint. 2. Rotate all stored third-party API credentials (OpenAI, ElevenLabs, etc.) in Flowise as a precaution, even post-patch, since there is no way to audit whether keys were abused prior to patching. 3. If immediate upgrade is blocked, restrict external access to POST /api/v1/text-to-speech/generate at your WAF or reverse proxy — allow only trusted internal IPs. 4. Enable spend alerts and usage anomaly notifications at your AI providers (OpenAI dashboard, ElevenLabs billing) to detect unauthorized TTS consumption. 5. Review Flowise audit logs for unexpected credentialId references and cross-reference with provider API call timestamps.
What systems are affected by CVE-2026-41279?
This vulnerability affects the following AI/ML architecture patterns: AI agent frameworks, LLM workflow orchestration, No-code/low-code LLM builders, Multi-tenant AI platforms.
What is the CVSS score for CVE-2026-41279?
CVE-2026-41279 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.26%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0034 Cost Harvesting AML.T0034.000 Excessive Queries AML.T0049 Exploit Public-Facing Application AML.T0055 Unsecured Credentials AML.T0083 Credentials from AI Agent Configuration Compliance Controls Affected
What are the technical details?
Original Advisory
Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.0, the text-to-speech generation endpoint (POST /api/v1/text-to-speech/generate) is whitelisted (no auth) and accepts a credentialId directly in the request body. When called without a chatflowId, the endpoint uses the provided credentialId to decrypt the stored credential (e.g., OpenAI or ElevenLabs API key) and generate speech. This vulnerability is fixed in 3.1.0.
Exploitation Scenario
An adversary scans the internet for publicly accessible Flowise instances — version disclosure is often available via UI headers or API responses. With the target confirmed as pre-3.1.0, they call POST /api/v1/text-to-speech/generate without any session token, iterating through credentialId values (sequential integers or UUIDs enumerable via IDOR). Each successful hit causes the Flowise server to decrypt and use the stored API key server-side to generate TTS output. The adversary automates bulk requests to exhaust OpenAI or ElevenLabs credits, potentially reselling TTS capacity or simply destroying availability of AI features for legitimate users — all while leaving zero footprint in authentication logs since no login ever occurred.
Weaknesses (CWE)
CWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
- [Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
- [Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Timeline
Related Vulnerabilities
CVE-2025-59528 10.0 Flowise: Unauthenticated RCE via MCP config injection
Same package: flowise CVE-2026-46442 9.9 Flowise: sandbox escape enables authenticated RCE
Same package: flowise CVE-2025-61913 9.9 Flowise: path traversal in file tools leads to RCE
Same package: flowise CVE-2026-40933 9.9 Flowise: RCE via MCP stdio command injection
Same package: flowise CVE-2026-56274 9.9 Flowise: RCE via MCP server command validation bypass
Same package: flowise