Flowise Unauthenticated TTS Credential Abuse via Missing Chatflow Ownership Check
First seen Aug 5, 2026 · Updated Aug 5, 2026
Flowise's text-to-speech generation endpoint is whitelisted to bypass authentication and fails to verify whether the referenced chatflow is public, allowing anyone who knows or guesses a chatflow UUID to invoke that chatflow's stored OpenAI or ElevenLabs credential. This lets an unauthenticated attacker generate unlimited TTS audio at the chatflow owner's expense, resulting in financial abuse and indirect credential misuse. This is a genuine broken-access-control vulnerability in an AI agent orchestration platform, not a prompt injection or model-level attack.
Technical Analysis
The `/api/v1/text-to-speech/generate` endpoint is exempted from authentication middleware, and when no `req.user` context exists, the controller calls `getChatflowById(chatflowId)` without a workspace scope, retrieving any chatflow regardless of its public/private status. The controller then parses the chatflow's `textToSpeech` config, extracts the active provider's `credentialId`, and uses it to decrypt and call the underlying OpenAI/ElevenLabs API on behalf of the request. The entry point is a single HTTP call requiring only a valid chatflow UUID (no secret), and the attacker gains indirect, repeatable use of a victim-owned API credential to generate arbitrary-length audio, crossing the boundary between an unauthenticated caller and a privileged, credential-backed tool/agent action. This is a resource/financial abuse and credential-boundary failure rather than a model-manipulation attack, but it demonstrates how agent-adjacent tool endpoints without per-object authorization become a foothold for credential exfiltration/misuse.
Affected Systems
Flowise
Detection Signatures
- Repeated or high-volume POST requests to /api/v1/text-to-speech/generate from unauthenticated or unfamiliar clients
- Requests referencing chatflowId values not owned by the requesting session/workspace
- Unusually large 'text' payloads in TTS generate requests
- Spikes in OpenAI/ElevenLabs TTS API usage/billing uncorrelated with authenticated chatflow traffic
- Absence of req.user context combined with successful chatflow credential resolution in server logs
Remediation Steps
- 1
Enforce isPublic check on unauthenticated access
Modify the TTS controller to reject requests for chatflows where isPublic is false when no authenticated user/workspace context is present.
- 2
Require workspace-scoped lookups
Always pass workspaceId (or an equivalent authorization scope) into getChatflowById and refuse to fall back to unscoped queries.
- 3
Rate-limit and monitor unauthenticated endpoints
Apply strict per-IP/per-chatflow rate limiting and cost-anomaly alerting on the TTS generate endpoint and other whitelisted routes.
- 4
Rotate and scope credentials
Rotate any OpenAI/ElevenLabs credentials that may have been exposed to this endpoint and use provider-side spend caps/key restrictions.
- 5
Audit whitelisted route list
Review all endpoints exempted from authentication in constants.ts to ensure none expose owner-scoped credentials or data without object-level authorization checks.
- 6
Upgrade Flowise
Apply the vendor patch/upgrade beyond version 3.1.3 once available and track GHSA-8gj2-2cvc-6xx7 for the official fix.
CVE / Advisory IDs
Industries Most Exposed
Respond to this threat
Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.