GHSA-RWRP-9823-P2XQ: Incomplete Credential Redaction in Flowise API

Flowise is an open-source visual tool for building and orchestrating large language model applications. To integrate with third-party APIs, databases, and cloud services, Flowise manages credentials via its backend service layer. Users save database connection strings, API keys, and service account files within dedicated configurations, which the application encrypts before writing them to the database.

The vulnerability lies in the API endpoint responsible for retrieving these saved credentials. Specifically, the GET /api/v1/credentials/:id endpoint retrieves, decrypts, and exposes raw secrets in its HTTP response body under certain conditions. The exposure stems from a selective redaction mechanism that only flags and sanitizes variables explicitly categorized under the 'password' data type.

This architecture creates a broad attack surface. Any authenticated user possessing low-privilege access, such as viewer permissions (credentials:view), can call the affected API endpoint directly. If the target credential contains fields configured as standard strings rather than passwords, the backend transmits the sensitive secrets in plaintext, resulting in unauthorized information disclosure.

The root cause of this exposure is an incomplete sanitization routine within the credential redaction function. In the Flowise backend, when a user requests a credential by ID, the application invokes decryptCredentialData() to recover the plaintext values from database storage. Once decrypted, the backend attaches these secrets to the plainDataObj attribute within the API response object.

To prevent exposing these secrets to the client browser, the application pipes the response object through a sanitization helper named redactCredentialWithPasswordType(). This function iterates through each credential field defined in the component's metadata schema. However, the function relies on a strict filtering constraint, checking only for fields where the parameter type equals 'password'.

If a credential component developer defines a secret-carrying field using the 'string' type, the sanitizer bypasses it entirely. The helper function fails to match the field against its hardcoded sanitization rule and returns the variable unmodified. Consequently, the backend returns the database connection strings, RSA private keys, and master access tokens in plaintext within the JSON response payload.

The vulnerability is localized within the credential retrieval services and utility modules. In packages/server/src/utils/index.ts, the validation routine only matches input parameters with the explicit type designation of 'password'. Below is the vulnerable logic path:

// Vulnerable utility logic in packages/server/src/utils/index.ts
export const redactCredentialWithPasswordType = (
    componentCredentialName: string,
    decryptedCredentialObj: ICredentialDataDecrypted,
    componentCredentials: IComponentCredentials
): ICredentialDataDecrypted => {
    const plainDataObj = cloneDeep(decryptedCredentialObj)
    for (const cred in plainDataObj) {
        const inputParam = componentCredentials[componentCredentialName].inputs?.find(
            (inp) => inp.type === 'password' && inp.name === cred // Only redacts if type is 'password'
        )
        if (inputParam) {
            plainDataObj[cred] = REDACTED_CREDENTIAL_VALUE
        }
    }
    return plainDataObj
}

This logic fails when processing component configurations that use standard string declarations for sensitive values. For instance, the PostgreSQL credential component (postgresUrl) defines its connection string as follows:

{
    "label": "PostgreSQL Connection URL",
    "name": "postgresUrl",
    "type": "string",
    "placeholder": "postgresql://dbuser:password@localhost:5432/dbname"
}

Because the type is 'string', the find condition in the sanitization loop evaluates to undefined. The field is not sanitized, and the raw connection string, including the embedded database username and password, is written directly to the API response.

Exploitation of this vulnerability requires network access to the Flowise API and a valid user session token. An authenticated attacker starts by identifying credential records associated with database nodes or cloud service integrations. Since the system exposes unique identifiers for credential objects, the attacker can retrieve specific credential records directly.

The attacker issues a standard HTTP GET request to the /api/v1/credentials/:id endpoint, appending the targeting credential identifier. No special tools or exploit payloads are required. A simple request tool or command-line client like curl can perform the operation:

curl -X GET "http://localhost:3000/api/v1/credentials/<credential_uuid>" \
  -H "x-request-from: internal" \
  -H "Cookie: token=<jwt_token>"

If the targeted credential is a PostgreSQL connection string, a MongoDB URL, or a Google Cloud Service Account JSON file, the response payload will contain the raw credentials inside the plainDataObj attribute. The client interface typically filters or hides these values, but direct API interaction bypasses the UI constraints entirely.

The impact of this credential exposure is significant. Attackers who extract connection strings can directly access internal database servers (such as MongoDB, PostgreSQL, and Redis databases). This access permits arbitrary data exfiltration, database structure modification, and complete loss of confidentiality and integrity of application data stored in those repositories.

Furthermore, the exposure of Google Cloud Service Account JSON structures exposes RSA private keys. Attackers can utilize these keys to authenticate directly to GCP services, potentially accessing Google Vertex AI models, cloud storage buckets, or Kubernetes clusters. This exposure can lead to lateral movement within the victim's broader enterprise cloud infrastructure.

From a privilege escalation perspective, any user with basic workspace viewing rights can extract administrative credentials. In multi-tenant or shared Flowise environments, this allows low-privileged operators to elevate their actual operational capabilities to match those of the organization's cloud administrators, fully compromising the trust boundary.

To address this vulnerability, administrators must upgrade their Flowise deployments to version 3.1.3 or higher. The fixed release updates the input configurations and ensures that sensitive fields are categorized properly, preventing exposure through the API responses. The patch release can be accessed from the official repository at https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.3.

If immediate software upgrades are not feasible, organizations must restrict network access to the Flowise administrative interface using network access control lists or firewalls. Implement strict network segmentation to ensure the application server cannot reach sensitive destination networks unless explicitly required. Additionally, administrators should audit user accounts and limit access to trusted personnel.

For custom self-hosted codebases, developers should manually override the sanitization logic. Replace the reliance on 'password' types with a more robust property matching mechanism, or audit all credentials schemas in packages/components/credentials/ to verify that sensitive attributes explicitly use secure types. The application should avoid returning raw values inside plainDataObj to client-side endpoints whenever possible.