Flowise Credential API Incomplete Redaction Exposes Plaintext Secrets

Technical Analysis

The GET /api/v1/credentials/:id endpoint decrypts stored credential data server-side and returns it in a plainDataObj field; the redactCredentialWithPasswordType() function only redacts fields where the component schema declares type: 'password', leaving type: 'string' fields (e.g., mongoDBConnectUrl, googleApplicationCredential, postgresUrl, redisUrl, awsKey) fully exposed in the API response. Because Flowise credentials back tool integrations used by agents/chains (databases, cloud APIs, vector stores), an attacker with limited workspace access (credentials:view) can escalate from viewing agent tool configuration to obtaining live secrets for external systems, crossing the boundary from the agent framework's tool layer into the underlying infrastructure it orchestrates. This is a data exposure/authorization design flaw rather than a memory- or prompt-based attack, but it directly threatens the confidentiality of the credential store that underpins agentic tool use in Flowise deployments.

Affected Systems

Flowise

Detection Signatures

• GET requests to /api/v1/credentials/:id followed by response bodies containing plainDataObj with non-REDACTED values for known secret-bearing fields (mongoDBConnectUrl, googleApplicationCredential, postgresUrl, redisUrl, awsKey, etc.)
• Audit logs showing credentials:view-scoped users enumerating credential IDs sequentially
• API responses where plainDataObj retains full string values instead of REDACTED_CREDENTIAL_VALUE for fields storing URLs, keys, or JSON blobs

Remediation Steps

1. 1

   Upgrade Flowise

   Update to a patched Flowise version (post 3.1.2) once available that fixes credential redaction for all sensitive field types.

2. 2

   Expand redaction logic

   Modify redactCredentialWithPasswordType() (or replace with an allowlist approach) to redact any field containing secrets regardless of declared type ('string', 'password', etc.), using field-name heuristics or an explicit 'sensitive: true' schema flag.

3. 3

   Restrict credentials:view permission

   Limit which roles/users are granted credentials:view and audit existing grants; treat this permission as equivalent to secret access.

4. 4

   Rotate exposed secrets

   Rotate all credentials (DB connection strings, service account keys, AWS keys) stored in affected Flowise instances, since they may have already been exposed via the API.

5. 5

   Add response-layer monitoring

   Monitor and alert on API responses from /api/v1/credentials/:id containing unredacted secret patterns (connection URIs, PEM/RSA keys, AKIA-prefixed AWS keys).