GHSA-m837-xvxr-vqwg: Hardcoded CORS Wildcard Enables Cross-Origin Credential Abuse in Flowise

Flowise is a visual AI agent builder that integrates various external APIs, including Text-to-Speech (TTS) engines. The application exposes specific HTTP endpoints to handle these integrations and facilitate frontend interactions. The vulnerability resides in the TTS generation endpoint, which is responsible for processing requests and returning audio data.

A security design flaw exists in the Cross-Origin Resource Sharing (CORS) configuration for this specific endpoint. The application implements a global CORS policy via the getCorsOptions() function, but the TTS endpoint overrides this configuration with a hardcoded wildcard. This explicit override nullifies the intended origin restrictions for TTS requests.

The flaw is tracked as GHSA-m837-xvxr-vqwg and affects all Flowise versions prior to 3.1.2. By explicitly permitting any origin to read HTTP responses, the application exposes active sessions to cross-origin abuse. This configuration violates standard web security practices regarding resource sharing and creates a significant localized security boundary failure.

The root cause is the manual injection of the Access-Control-Allow-Origin: * header directly within the controller logic for the TTS endpoint. Cross-Origin Resource Sharing (CORS) is a browser security mechanism that restricts how documents or scripts loaded from one origin interact with resources from another origin. When a server responds with a wildcard origin, it instructs the browser to permit any requesting domain to read the HTTP response.

The Flowise architecture includes a centralized global CORS configuration designed to manage access control consistently across the application. However, the developer implemented specific response headers in the TTS controller, completely bypassing the centralized policy. This isolated configuration choice created an unintended access vector.

While browsers typically restrict the transmission of credentials when a wildcard origin is combined with the withCredentials flag, this specific implementation flaw interacts poorly with other architectural decisions. The explicit wildcard permits malicious cross-origin execution of the TTS logic, providing a pathway for exploitation when combined with TTS credential abuse vulnerabilities.

The vulnerable implementation is located in the packages/server/src/controllers/text-to-speech/index.ts file. At approximately line 83, the controller explicitly modifies the HTTP response headers before returning the payload. This modification is hardcoded and executes unconditionally for every request hitting the endpoint.

The vulnerable code snippet demonstrates the direct manipulation of the response object. The developer instructed the server to append the wildcard origin and a specific cache control header, ignoring the global Express middleware configuration.

// packages/server/src/controllers/text-to-speech/index.ts:83
res.setHeader('Access-Control-Allow-Origin', '*')
res.setHeader('Access-Control-Allow-Headers', 'Cache-Control')

The patch completely removes these manual header injections. By deleting these two lines, the endpoint delegates CORS handling back to the global middleware configured for the Express application. The standard middleware correctly validates the incoming origin against the allowed list defined in the application's global state.

// Patched Code (packages/server/src/controllers/text-to-speech/index.ts)
- res.setHeader('Access-Control-Allow-Origin', '*')
- res.setHeader('Access-Control-Allow-Headers', 'Cache-Control')

Exploitation relies on a drive-by attack vector. An attacker must host a malicious webpage and convince a user with an active Flowise session to visit the site. Upon loading the page, embedded JavaScript executes a cross-origin HTTP request targeting the victim's Flowise instance's TTS endpoint.

Because the endpoint responds with the wildcard origin header, the victim's browser permits the malicious page to read the HTTP response. The advisory notes that this CORS bypass becomes critically exploitable when combined with a secondary vulnerability documented as "Finding 3" (TTS credential abuse). This combination allows the cross-origin request to execute successfully within the context of the user's application state.

The exploitation sequence does not require direct network access to the Flowise backend from the attacker's infrastructure. The attack is entirely client-side, leveraging the victim's browser as a confused deputy. The success of the exploit depends on the victim maintaining an authenticated session.

The primary impact of this vulnerability is unauthorized resource consumption. Flowise integrates with external, paid APIs for TTS generation, such as OpenAI and ElevenLabs. Exploitation allows an attacker to generate audio files using the victim's configured API keys and service quotas.

Continuous or automated exploitation leads to rapid API quota exhaustion and financial damage. The attacker consumes the credits associated with the Flowise instance without requiring direct access to the underlying API keys themselves. The system effectively acts as an open proxy for commercial TTS generation services.

The CVSS v4.0 score of 6.9 reflects the network attack vector, low attack complexity, and the impact on the integrity and availability of the system's external resources. While the vulnerability does not grant arbitrary code execution on the host server, the financial and operational impact on the application owner is substantial.

The vendor addressed the vulnerability in Flowise version 3.1.2. The recommended remediation is an immediate upgrade to this patched version or a later release. Upgrading ensures the centralized CORS middleware correctly protects the TTS endpoint.

System administrators using Docker must update their deployment configurations to pull the fixed image tag. Executing docker pull flowiseai/flowise:3.1.2 retrieves the secure version. Administrators must restart the container to apply the new image layer and flush any cached configurations.

Organizations unable to upgrade immediately can implement mitigation strategies at the reverse proxy layer. Configuring Nginx, HAProxy, or an API gateway to strip or overwrite the Access-Control-Allow-Origin header for the /api/v1/text-to-speech endpoint neutralizes the vulnerability. The proxy must enforce the organization's standard CORS policy.