GHSA-7G73-99R4-M4MJ: Credential Data Leak in FlowiseAI API Responses

FlowiseAI operates as a visual UI tool designed to build customized Large Language Model (LLM) workflows. In order to function, the platform stores and manages highly sensitive third-party API keys and authentication tokens. These tokens allow the Flowise platform to authenticate with upstream providers like OpenAI, Anthropic, or local vector databases.

The application exposes REST API endpoints that allow users and the frontend interface to query the system for stored credentials. The vulnerability resides in how the server-side code processes these retrieval requests. Specifically, the API fails to filter sensitive internal fields before serializing database records into HTTP responses.

This behavior results in a CWE-200 Information Exposure vulnerability. When a user requests the list of credentials, the server responds with a JSON array that includes the encryptedData field. This field contains the actual sensitive information in an encrypted format, exposing the raw ciphertext to the requester.

The vulnerability originates in the data access layer of the Flowise application, specifically within the getAllCredentials function. The application utilizes an Object-Relational Mapper (ORM) to retrieve credential entities from the underlying database. The AppDataSource.getRepository(Credential).findBy(searchOptions) call returns raw instances of the Credential entity class.

The Credential entity is defined with an encryptedData property, which maps to the database column storing the ciphertext. After retrieval, the application pushes these entity objects directly into the response array without passing them through a Data Transfer Object (DTO) or applying a serialization filter.

When the Express web framework finalizes the HTTP response, it implicitly calls JSON.stringify() on the provided array. Because JavaScript object serialization processes all enumerable properties, the sensitive encryptedData field is converted to JSON and transmitted to the client. The absence of an explicit field exclusion mechanism constitutes the core technical failure.

The flaw existed within packages/server/src/services/credentials/index.ts. The vulnerable implementation fetched the credentials and appended the raw objects directly to the response array.

const credentials = await appServer.AppDataSource.getRepository(Credential).findBy(searchOptions)
// Vulnerable: Pushes the whole object including encryptedData
dbResponse.push(...credentials)

The remediation introduced in Pull Request #6042 implements a mapping function utilizing the omit utility. This ensures the encryptedData key is stripped from each credential object prior to being pushed into the response array.

const credentials = await appServer.AppDataSource.getRepository(Credential).findBy(searchOptions)
// Patched: Explicitly removes the encryptedData field
dbResponse.push(...credentials.map((c) => omit(c, ['encryptedData'])))

To prevent regressions, the maintainers introduced a dedicated test suite in packages/agentflow/src/infrastructure/api/credentials.test.ts. This test asserts that the encryptedData property is absent from the objects returned by the API client, ensuring future architectural changes do not inadvertently reintroduce the leak.

Exploitation requires the attacker to issue an HTTP GET request to the /api/v1/credentials endpoint. The attacker must possess the necessary network access and authorization required to reach and query this specific API route.

Upon receiving the request, the vulnerable Flowise instance executes the database query and serializes the complete entity records. The application returns an HTTP 200 OK response containing a JSON array. Each element in this array represents a distinct credential and contains the encryptedData field populated with a base64-encoded or hex-encoded ciphertext string.

The attacker parses the JSON response and extracts the ciphertexts. While the tokens are not immediately usable in their encrypted state, the attacker can store these blobs offline. The exploitation phase concludes with the attacker possessing the encrypted representation of all configured third-party integrations.

The primary impact is the unauthorized exposure of highly sensitive ciphertext. This vulnerability completely undermines the abstraction layer of the API, which is designed to identify the existence of credentials without revealing the underlying secrets in any format.

The exposure of ciphertext significantly amplifies the severity of secondary vulnerabilities. If an attacker leverages a separate flaw—such as Local File Inclusion (LFI) or Server-Side Request Forgery (SSRF)—to read the application's environment variables, they can obtain the encryption key. With both the key and the leaked ciphertext, the attacker can systematically decrypt every token stored in the Flowise database.

In multi-tenant or enterprise environments, this flaw facilitates horizontal privilege escalation. Users who are granted restricted access to view certain workflows or credential names can harvest the underlying ciphertext. This data can be subjected to offline cryptographic analysis or held until a key compromise occurs, resulting in the total loss of confidentiality for the configured LLM API keys.

The vulnerability is fundamentally resolved in FlowiseAI version 3.1.2. Administrators must upgrade their flowise npm package and redeploy the application to ensure the patched serialization logic is active. The updated code explicitly drops the encryptedData field, neutralizing the threat vector.

Organizations running affected versions prior to 3.1.2 must assume the ciphertext has been exposed if the API was accessible to untrusted entities. As a direct consequence, all API keys, database passwords, and third-party tokens stored within Flowise should be considered compromised and rotated immediately.

For environments where immediate patching is not feasible, administrators can deploy web application firewall (WAF) rules or reverse proxy filters to inspect HTTP responses originating from the /credentials endpoints. Modifying the response payloads in transit to strip the encryptedData key provides a temporary stopgap until the application is upgraded.