CVE-2026-73603

Executive Summary

CVE-2026-73603 is a missing-authorization vulnerability in Flowise, an open-source visual builder for LLM applications, affecting versions before 3.1.4. The unauthenticated text-to-speech (TTS) endpoint does not validate chatflow visibility, allowing any remote, unauthenticated attacker who can supply a valid chatflow UUID to trigger TTS synthesis using the chatflow owner's stored OpenAI or ElevenLabs API keys. The primary impact is financial and operational: attackers can generate unlimited audio content on the victim's billing account, exhausting quotas and incurring real monetary costs, while no credentials are exfiltrated. The vulnerability is not listed in CISA KEV, has no public exploit code, and carries no assigned CVSS score; patch confirmation is currently limited to a single OSV source with low confidence.

Technical Analysis

The vulnerability belongs to the CWE-862 (Missing Authorization) class. Flowise enables users to build and expose "chatflows" — orchestrated LLM workflows — that may include text-to-speech capabilities. When a chatflow is configured with TTS, Flowise relies on stored service credentials for upstream providers such as OpenAI and ElevenLabs. The vulnerable component is the unauthenticated text-to-speech endpoint, which is reachable without any session, token, or API key of its own.

The root cause is an authorization omission, not a cryptographic or injection flaw. The endpoint is designed to service TTS requests for chatflows; however, prior to version 3.1.4, it fails to check whether the target chatflow is marked as public or visible. The only access control in place is the possession of a chatflow UUID — a globally unique identifier used to reference a specific chatflow. Because UUIDs are not secret by design (they are frequently exposed in client-side application code, shared chatflow URLs, browser history, proxy logs, or analytics data), an attacker who obtains or guesses a UUID referencing a private chatflow can impersonate legitimate TTS requests.

Once the request is accepted, the server-side logic retrieves the chatflow configuration, resolves the associated TTS provider credentials (OpenAI or ElevenLabs API keys), and performs audio synthesis using the attacker-supplied text input. The response, an audio stream, is returned to the attacker. No authentication or authorization boundary is enforced between the public endpoint and the private chatflow's credential store. The attack consumes API credits on the chatflow owner's account with each request; because there is no rate limiting or quota check described at the vulnerable endpoint level, the request volume is limited only by the attacker's intent and the provider's own API limits.

Technical detail is sparse: the NVD description does not disclose the exact URI path, request parameters, or the specific code functions involved. This report therefore describes the mechanism at the vulnerability-class level, which is sufficient for detection and remediation planning. The affected-version range ("before 3.1.4") is derived from the description; the OSV record lists the package state as "unfixed" (0→unfixed), which is consistent with the low (2/4) patch confidence — a single source claims a fix exists, but it has not been independently verified.

Exploitation Scenarios

No public proof-of-concept is available, and the attack chain below is inferred from the vulnerability class and the NVD description.

1. Reconnaissance / target identification. An attacker identifies internet-facing Flowise instances using search-engine and Shodan queries (http.title:"Flowise", product:"Flowise"). The attacker then needs a valid chatflow UUID. UUIDs are 128-bit identifiers (122 random bits), so blind brute force is computationally infeasible; instead, the attacker harvests UUIDs from sources such as publicly embedded chatflow widgets, shared/deployed chatflow URLs, client-side JavaScript bundles served by the application, indexable pages, or logs. Public chatflows provide an immediate UUID pool; private chatflows require prior exposure.

2. Flaw triggering. The attacker crafts an HTTP request to the unauthenticated text-to-speech endpoint, supplying the harvested chatflow UUID and a text payload to be spoken. Because the endpoint does not validate whether the referenced chatflow is public, the request is processed even when the target chatflow is marked private. The server resolves the chatflow's stored TTS configuration.

3. Payload / execution method. At the vulnerability-class level, the attacker submits the request with a valid chatflow UUID and arbitrary TTS input text. The server-side TTS handler retrieves the configured OpenAI or ElevenLabs API key from the chatflow's stored settings and performs a legitimate synthesis call to the upstream provider on the owner's behalf. The resulting audio is returned to the attacker. Repetition of this request constitutes the abuse loop: each request incurs upstream API cost and consumes the owner's quota. There is no indication that API keys themselves are returned in responses, so the attack is cost/quota abuse rather than credential theft.

4. Post-exploitation impact. Repeated TTS synthesis drains the chatflow owner's OpenAI or ElevenLabs credits, causing unexpected billing charges and potential service disruption for legitimate chatflow users when quotas are exhausted. The attacker gains continued unauthorized use of the TTS capability for the lifetime of the unpatched instance. Because the vulnerability is unauthenticated and network-reachable, any number of independent attackers can abuse the same chatflow simultaneously, amplifying the financial impact.

Impact Assessment

The business impact of CVE-2026-73603 is primarily financial and availability-related rather than confidentiality-related. Attackers do not exfiltrate API keys according to the NVD description; they abuse them at a distance. Affected systems are self-hosted Flowise deployments before 3.1.4 that have TTS integrations enabled (OpenAI or ElevenLabs) and that expose the vulnerable endpoint to untrusted networks. The blast radius is limited to chatflow owners whose TTS credentials are stored within the platform, but the abuse surface is global since the endpoint is unauthenticated by design.

No CVSS vector or score has been assigned (N/A), which limits quantitative severity benchmarking. Contextual signals indicate a low current exploitation likelihood: EPSS score is 0.00317 (24.5th percentile of exploited CVEs), the CVE is not present in CISA KEV, and no exploit code or Nuclei template has been published. However, the absence of a CVSS score should not be read as "no impact" — the financial-abuse model is a recognized and measurable harm class, and the attack is trivial to execute once a UUID is obtained. Organizations that bill by usage tier for OpenAI/ElevenLabs and run budget-unbounded API keys face the highest realized impact.

Detection Guidance

Important note on assumptions: The NVD description does not disclose the exact URI path or parameter names of the text-to-speech endpoint. The detection logic below assumes the endpoint appears in access logs with a URI containing the substring tts or text-to-speech, and that requests reference a chatflow UUID. Operators must adjust the URI pattern to match the actual deployed Flowise path observed in their environment.

Sigma Rule

title: Flowise Unauthenticated Text-to-Speech Endpoint Abuse
id: 4f1c8e6a-2c74-4a9d-b3f0-93d5f12a7e10
status: experimental
description: Detects unauthenticated HTTP requests to the Flowise text-to-speech endpoint containing a chatflow UUID, indicating potential CVE-2026-73603 abuse.
logsource:
  category: webserver
  product: apache
detection:
  selection_uri:
    cs-uri-query|contains|all:
      - 'tts'
  selection_uuid:
    cs-uri-query|re: '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}'
  filter_authenticated:
    cs-username|exists: true
  condition: selection_uri and selection_uuid and not filter_authenticated
falsepositives:
  - Legitimate public chatflow TTS usage (additionally filter on known public chatflow UUIDs)
  - Health checks or monitoring tools that reference UUIDs
level: medium
tags:
  - attack.initial_access
  - attack.t1190
  - cve.2026.73603

YARA Rule

rule flowise_tts_abuse_log_pattern
{
    meta:
        author = "Valters IT SOC"
        description = "Detects web access-log lines or exfiltrated log snippets referencing Flowise text-to-speech requests with a chatflow UUID (CVE-2026-73603)."
        reference = "CVE-2026-73603"
        date = "2026-01-01"
    strings:
        $tts1 = "tts" nocase
        $tts2 = "text-to-speech" nocase
        $flow = "chatflow" nocase
    condition:
        ($tts1 or $tts2) and $flow and
        # matches regex [0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12} in (1..4)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-73603 Flowise Unauthenticated Text-to-Speech Abuse"; flow:established,to_server; content:"tts"; http_uri; pcre:"/[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}/R"; http_uri; http.method; content:"POST"; http.method; reference:cve,2026-73603; classtype:attempted-dos; sid:20267360; rev:1;)

Note: the rule is intentionally broad on the URI substring; tune the content:"tts" pattern to the exact deployed path observed in your environment.

Elastic Detection

sequence with maxspan=5m
  [ network where event.category == "web" and http.request.method == "POST"
     and url.path like "*tts*"
     and url.query regex~ "[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"
     and not http.request.headers.authorization exists
  ] with runs=5

This EQL sequence flags five or more unauthenticated TTS requests within five minutes — consistent with the "unlimited generation" abuse pattern. Adjust the run count and time window to reduce false positives.

Splunk SPL Query

index=web* sourcetype=access_combined
| regex _raw="(?i)(tts|text-to-speech)"
| regex _raw="[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"
| where isnull(user) OR user=""
| stats count AS tts_requests, dc(uri) AS unique_uris, values(uri) AS sample_uris by src_ip, dest_host
| where tts_requests > 20
| sort - tts_requests

Run this against reverse-proxy or web access logs. The query groups repeat TTS requests by source IP, filtering out authenticated sessions to isolate the unauthenticated abuse pattern.

Wazuh OSSEC Rule

<group name="flowise,">
  <rule id="100736" level="10">
    <decoded_as>json</decoded_as>
    <field name="url">\.*tts.*</field>
    <regex>([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})</regex>
    <description>Flowise unauthenticated text-to-speech request abusing a chatflow UUID (CVE-2026-73603)</description>
    <group>flowise,tts_abuse,cve_2026_73603,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Deploy this rule where the Wazuh agent ingests Apache/nginx access logs via the JSON decoder. Correlate the rule with per-source-IP volume thresholds in the Wazuh manager to catch sustained abuse rather than a single request.

Mitigation & Patch Guidance

Patch confidence for this CVE is 2/4 — the patch is claimed by a single source (OSV) and is not independently confirmed. No vendor fix, workaround, or hardened version has been verified by a second source at the time of writing. Until 3.1.4 is confirmed, treat the instance as vulnerable.

1. Immediate mitigations. Place Flowise behind a reverse proxy or Web Application Firewall and block unauthenticated access to the text-to-speech endpoint (deny-by-default). Restrict network exposure of the Flowise management interface to trusted IP ranges/VPN. Set spend limits and quota caps on the OpenAI and ElevenLabs API keys used by Flowise so a single compromised chatflow cannot run unlimited billing. Monitor usage dashboards for abnormal TTS request volumes and set alert thresholds.

2. Patch / upgrade steps. Upgrade Flowise to version 3.1.4 or later once the fix is verified against the vendor's release notes. Because the OSV record still lists the package as unfixed (0→unfixed), validate the upgrade in a staging environment first, confirm that the TTS endpoint now enforces chatflow visibility, and only then roll out to production. Rotate OpenAI and ElevenLabs API keys after the upgrade in case they were abused prior to patching.

3. Long-term hardening. Enforce authentication on all Flowise API endpoints, not just the console. Disable TTS integrations for chatflows that do not require them. Implement rate limiting and per-chatflow usage quotas at the reverse proxy. Treat chatflow UUIDs as sensitive identifiers: stop exposing them in public pages and client-side bundles where possible. Establish a routine of reviewing OSV and NVD notifications for Flowise, since patch confidence for this CVE is low and verification is pending.

References

1. NVD Entry — CVE-2026-73603: https://nvd.nist.gov/vuln/detail/CVE-2026-73603
2. OSV Vulnerability Record — CVE-2026-73603 (patch source, confidence 2/4): https://osv.dev/vulnerability/CVE-2026-73603
3. CWE-862 — Missing Authorization: https://cwe.mitre.org/data/definitions/862.html
4. Flowise Project Repository (vendor reference — verify 3.1.4 release and advisory): https://github.com/FlowiseAI/Flowise
5. CISA KEV Catalog — CVE-2026-73603 is not listed; no known exploitations-in-the-wild or threat-actor campaigns were identified at the time of writing.

No in-the-wild exploitation evidence, ransomware campaign associations, or public exploit code (including Nuclei templates) have been reported for this CVE.