AI Threat AlertCVE-2026-73603: Flowise: unauth TTS endpoint drains stored API keys
MEDIUMCISA: TRACK*This CVE exposes a missing authorization check (CWE-862) in Flowise's unauthenticated text-to-speech endpoint: any attacker who obtains a chatflow's UUID can invoke the owner's TTS credentials — including stored OpenAI or ElevenLabs API keys — without ever logging in. For CISOs, the real exposure isn't data theft but uncontrolled spend: this is a cost-harvesting vector that can run up unexpected charges on production API keys tied to customer-facing chatbots. Exploitability is trivial (no auth, no exploit chain, just a valid UUID) but overall risk stays contained — EPSS sits at a low 0.317% absolute probability, there's no public PoC or Nuclei template, it's not in CISA KEV, and CISA's SSVC decision is TRACK_STAR (monitor, no urgent action). Any org running Flowise chatflows with TTS enabled should upgrade to 3.1.4+, audit which chatflow UUIDs have been shared or are guessable, and set billing alerts on the OpenAI/ElevenLabs keys tied to those flows as a compensating control until patched.
What is the risk?
Medium severity per vendor rating, driven by low-complexity, no-auth exploitation offset by limited blast radius (0 tracked downstream dependents) and financial-only impact (no code execution, no data exfiltration). EPSS absolute probability is low (0.317%), no public exploit or scanner template exists, and CISA's SSVC verdict is TRACK_STAR — track but no urgent action required. The main risk driver is triviality: exploitation requires only a chatflow UUID and an HTTP request, so any exposed instance with a discoverable UUID is exploitable by unsophisticated actors.
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 should I do?
1 stepUpgrade Flowise to 3.1.4 or later, where the visibility check is enforced on the TTS endpoint. Until patched, treat any chatflow UUID as sensitive: avoid embedding UUIDs in public-facing pages/links, rotate OpenAI/ElevenLabs keys tied to chatflows with TTS enabled, and set hard spend caps/billing alerts on those provider accounts as a compensating control. Post-patch, audit provider billing dashboards for anomalous TTS usage spikes predating the upgrade, and review Flowise instance logs for repeated unauthenticated calls to the TTS endpoint from a small set of source IPs.
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-73603?
This CVE exposes a missing authorization check (CWE-862) in Flowise's unauthenticated text-to-speech endpoint: any attacker who obtains a chatflow's UUID can invoke the owner's TTS credentials — including stored OpenAI or ElevenLabs API keys — without ever logging in. For CISOs, the real exposure isn't data theft but uncontrolled spend: this is a cost-harvesting vector that can run up unexpected charges on production API keys tied to customer-facing chatbots. Exploitability is trivial (no auth, no exploit chain, just a valid UUID) but overall risk stays contained — EPSS sits at a low 0.317% absolute probability, there's no public PoC or Nuclei template, it's not in CISA KEV, and CISA's SSVC decision is TRACK_STAR (monitor, no urgent action). Any org running Flowise chatflows with TTS enabled should upgrade to 3.1.4+, audit which chatflow UUIDs have been shared or are guessable, and set billing alerts on the OpenAI/ElevenLabs keys tied to those flows as a compensating control until patched.
Is CVE-2026-73603 actively exploited?
No confirmed active exploitation of CVE-2026-73603 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-73603?
Upgrade Flowise to 3.1.4 or later, where the visibility check is enforced on the TTS endpoint. Until patched, treat any chatflow UUID as sensitive: avoid embedding UUIDs in public-facing pages/links, rotate OpenAI/ElevenLabs keys tied to chatflows with TTS enabled, and set hard spend caps/billing alerts on those provider accounts as a compensating control. Post-patch, audit provider billing dashboards for anomalous TTS usage spikes predating the upgrade, and review Flowise instance logs for repeated unauthenticated calls to the TTS endpoint from a small set of source IPs.
What systems are affected by CVE-2026-73603?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, conversational AI workflows, API-integrated LLM/TTS pipelines.
What is the CVSS score for CVE-2026-73603?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0034Cost HarvestingAML.T0034.000Excessive QueriesAML.T0049Exploit Public-Facing ApplicationAML.T0096AI Service APICompliance Controls Affected
What are the technical details?
Original Advisory
Flowise before 3.1.4 fails to validate chatflow visibility in the unauthenticated text-to-speech endpoint, allowing attackers to abuse private chatflow TTS credentials. Unauthenticated attackers can generate unlimited text-to-speech audio using stored OpenAI or ElevenLabs API keys by providing a valid chatflow UUID, incurring costs on the chatflow owner's account.
Exploitation Scenario
An attacker finds a Flowise chatflow UUID — for example via a leaked share link, a GitHub repo referencing the flow, or by scraping a customer-facing embed — and sends repeated requests to the unauthenticated TTS endpoint with that UUID and attacker-chosen text. Flowise fails to verify the chatflow's visibility (CWE-862) and serves the request using the owner's stored OpenAI or ElevenLabs API key, generating audio the attacker never pays for. Run at scale or via automation, this drives up the victim's API bill with no credentials, authentication, or interaction from the legitimate user required.
Weaknesses (CWE)
CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
- [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2025-7133810.0Flowise: unauthenticated file write enables RCE
Same package: flowiseCVE-2025-5952810.0Flowise: Unauthenticated RCE via MCP config injection
Same package: flowiseCVE-2026-464429.9Flowise: sandbox escape enables authenticated RCE
Same package: flowiseCVE-2025-619139.9Flowise: path traversal in file tools leads to RCE
Same package: flowiseCVE-2026-409339.9Flowise: RCE via MCP stdio command injection
Same package: flowise