GHSA-7g73-99r4-m4mj — HIGH

Q: Is GHSA-7g73-99r4-m4mj actively exploited?

No confirmed active exploitation of GHSA-7g73-99r4-m4mj has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-7g73-99r4-m4mj?

1) Upgrade to Flowise 3.1.2 immediately—the patch adds `omit(credential, ['encryptedData'])` to the filtered code path. 2) Treat all credentials stored in Flowise as compromised: rotate API keys for OpenAI, AWS, Azure, and any other configured services. 3) Audit logs for the `/api/v1/credentials?credentialName=*` endpoint for unauthorized queries prior to patching. 4) Harden `~/.flowise/encryption.key` permissions to 600 (owner read/write only) and ensure it is owned by the flowise service account exclusively. 5) Revoke and re-issue all Flowise API bearer tokens. 6) If immediate patching is blocked, apply a WAF rule or reverse proxy ACL to block GET requests to `/api/v1/credentials` containing query parameters from untrusted principals.

Q: What systems are affected by GHSA-7g73-99r4-m4mj?

This vulnerability affects the following AI/ML architecture patterns: AI agent frameworks, LLM orchestration platforms, No-code AI workflow builders, Self-hosted AI service hubs, Multi-service AI pipelines.

Q: What is the CVSS score for GHSA-7g73-99r4-m4mj?

No CVSS score has been assigned yet.

CISO Take

Flowise versions up to 3.1.1 contain a logic flaw in the credentials API: when querying with a `credentialName` filter, the `encryptedData` field is not stripped from the response—unlike the unfiltered code path that correctly omits it. Any authenticated user, regardless of privilege level, can extract AES-encrypted credentials for all integrated services (OpenAI, AWS, Azure, databases) with a single HTTP request. In most self-hosted Flowise deployments, the `~/.flowise/encryption.key` file is created with default filesystem permissions, meaning an attacker who also has local read access can decrypt the exfiltrated ciphertext and obtain plaintext API keys—enabling full compromise of every connected AI service and cloud account in the organization's AI stack. Flowise has 69 CVEs in its history, indicating a pattern of security debt; treat all credentials stored in affected instances as compromised. Upgrade to Flowise 3.1.2 immediately and rotate all stored credentials; if patching is not possible today, restrict the `/api/v1/credentials` endpoint at the network layer and audit `~/.flowise/encryption.key` permissions.

Sources: GitHub Advisory ATLAS

What is the risk?

HIGH risk in practice despite requiring authentication. The exploit is trivial: a single authenticated GET request with a credentialName query parameter. The authentication barrier is low because Flowise API keys are frequently shared across teams or embedded in automation pipelines, increasing the attack surface for insider threats or token leakage. The compounding factor—default-permission encryption key file—elevates this from encrypted-data exposure to full plaintext credential theft in the majority of self-hosted deployments. Flowise typically acts as a credential vault for an organization's entire AI service portfolio, meaning blast radius extends well beyond the Flowise instance itself to OpenAI billing accounts, AWS IAM credentials, and any other secret stored in the platform.

Attack Kill Chain

Initial Access

Attacker obtains a valid Flowise bearer token via phishing, leaked CI/CD secret, or compromised service account.

AML.T0012

Credential Extraction

Attacker sends GET /api/v1/credentials?credentialName=<target> with the bearer token; logic flaw returns encryptedData field containing AES-encrypted API keys and passwords.

AML.T0106

Key Recovery

Attacker reads ~/.flowise/encryption.key (default world-readable permissions) and decrypts the exfiltrated ciphertext to obtain plaintext credentials for OpenAI, AWS, and other services.

AML.T0055

Impact

Attacker uses stolen credentials to run unauthorized LLM workloads (financial harm via billing), exfiltrate data from AI services, or pivot to cloud infrastructure via stolen IAM credentials.

AML.T0048.000

Initial Access

Attacker obtains a valid Flowise bearer token via phishing, leaked CI/CD secret, or compromised service account.

AML.T0012

Credential Extraction

Attacker sends GET /api/v1/credentials?credentialName=<target> with the bearer token; logic flaw returns encryptedData field containing AES-encrypted API keys and passwords.

AML.T0106

Key Recovery

Attacker reads ~/.flowise/encryption.key (default world-readable permissions) and decrypts the exfiltrated ciphertext to obtain plaintext credentials for OpenAI, AWS, and other services.

AML.T0055

Impact

Attacker uses stolen credentials to run unauthorized LLM workloads (financial harm via billing), exfiltrate data from AI services, or pivot to cloud infrastructure via stolen IAM credentials.

AML.T0048.000

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
flowise	npm	<= 3.1.1	`3.1.2`

Do you use flowise? You're affected.

Severity & Risk

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

1 step

1) Upgrade to Flowise 3.1.2 immediately—the patch adds omit(credential, ['encryptedData']) to the filtered code path. 2) Treat all credentials stored in Flowise as compromised: rotate API keys for OpenAI, AWS, Azure, and any other configured services. 3) Audit logs for the /api/v1/credentials?credentialName=* endpoint for unauthorized queries prior to patching. 4) Harden ~/.flowise/encryption.key permissions to 600 (owner read/write only) and ensure it is owned by the flowise service account exclusively. 5) Revoke and re-issue all Flowise API bearer tokens. 6) If immediate patching is blocked, apply a WAF rule or reverse proxy ACL to block GET requests to /api/v1/credentials containing query parameters from untrusted principals.

Classification

Data Leakage Data Extraction Agent Framework API AML.T0048.000 - Financial Harm AML.T0049 - Exploit Public-Facing Application AML.T0055 - Unsecured Credentials AML.T0083 - Credentials from AI Agent Configuration AML.T0106 - Exploitation for Credential Access

Compliance Impact

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.10.1.1 - Policy on the use of cryptographic controls A.9.4.1 - Information access restriction

NIST AI RMF

MANAGE 2.2 - Mechanisms to sustain oversight of AI risks

OWASP LLM Top 10

LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is GHSA-7g73-99r4-m4mj?

Flowise versions up to 3.1.1 contain a logic flaw in the credentials API: when querying with a `credentialName` filter, the `encryptedData` field is not stripped from the response—unlike the unfiltered code path that correctly omits it. Any authenticated user, regardless of privilege level, can extract AES-encrypted credentials for all integrated services (OpenAI, AWS, Azure, databases) with a single HTTP request. In most self-hosted Flowise deployments, the `~/.flowise/encryption.key` file is created with default filesystem permissions, meaning an attacker who also has local read access can decrypt the exfiltrated ciphertext and obtain plaintext API keys—enabling full compromise of every connected AI service and cloud account in the organization's AI stack. Flowise has 69 CVEs in its history, indicating a pattern of security debt; treat all credentials stored in affected instances as compromised. Upgrade to Flowise 3.1.2 immediately and rotate all stored credentials; if patching is not possible today, restrict the `/api/v1/credentials` endpoint at the network layer and audit `~/.flowise/encryption.key` permissions.

Is GHSA-7g73-99r4-m4mj actively exploited?

No confirmed active exploitation of GHSA-7g73-99r4-m4mj has been reported, but organizations should still patch proactively.

How to fix GHSA-7g73-99r4-m4mj?

1) Upgrade to Flowise 3.1.2 immediately—the patch adds `omit(credential, ['encryptedData'])` to the filtered code path. 2) Treat all credentials stored in Flowise as compromised: rotate API keys for OpenAI, AWS, Azure, and any other configured services. 3) Audit logs for the `/api/v1/credentials?credentialName=*` endpoint for unauthorized queries prior to patching. 4) Harden `~/.flowise/encryption.key` permissions to 600 (owner read/write only) and ensure it is owned by the flowise service account exclusively. 5) Revoke and re-issue all Flowise API bearer tokens. 6) If immediate patching is blocked, apply a WAF rule or reverse proxy ACL to block GET requests to `/api/v1/credentials` containing query parameters from untrusted principals.

What systems are affected by GHSA-7g73-99r4-m4mj?

This vulnerability affects the following AI/ML architecture patterns: AI agent frameworks, LLM orchestration platforms, No-code AI workflow builders, Self-hosted AI service hubs, Multi-service AI pipelines.

What is the CVSS score for GHSA-7g73-99r4-m4mj?

No CVSS score has been assigned yet.

Technical Details

NVD Description

**Severity**: HIGH (CVSS ~7.5) **Type**: CWE-200 (Exposure of Sensitive Information) **File**: `packages/server/src/services/credentials/index.ts:62-71` **Description**: When credentials are fetched with a `credentialName` filter parameter, the `encryptedData` field is NOT stripped from the response. The code properly omits `encryptedData` when NO filter is used (line 102) but fails to do so when a filter IS used (lines 62-63, 70-71). Credential Data Leak **Evidence**: ```typescript // Lines 62-63: WITH filter - encryptedData LEAKED const credentials = await appServer.AppDataSource.getRepository(Credential).findBy(searchOptions) dbResponse.push(...credentials) // encryptedData NOT removed! // Lines 100-102: WITHOUT filter - encryptedData properly omitted for (const credential of credentials) { dbResponse.push(omit(credential, ['encryptedData'])) // Correctly omitted } ``` **Impact**: Authenticated users can extract encrypted credential data (API keys, passwords, tokens for services like OpenAI, AWS, etc.). Combined with access to the encryption key file (`~/.flowise/encryption.key` written with default permissions), this enables full credential theft. **Reproduction**: ```bash curl https://TARGET/api/v1/credentials?credentialName=openAIApi \ -H "Authorization: Bearer API_KEY" # Response includes encryptedData field with AES-encrypted credentials ```

Exploitation Scenario

An attacker with any valid Flowise bearer token—obtained via a phishing attack on a developer, a leaked CI/CD secret, or a compromised low-privilege service account—sends `GET /api/v1/credentials?credentialName=openAIApi` with the token as an Authorization header. The response includes the `encryptedData` field containing the AES-256-CBC encrypted OpenAI API key. The attacker then reads `~/.flowise/encryption.key` (world-readable in a default Linux deployment) and decrypts the ciphertext offline, obtaining the plaintext API key. The attacker now has full OpenAI API access billed to the victim, can exfiltrate training data via the API, and repeats the credential extraction for AWS credentials stored in Flowise—enabling pivot to the victim's cloud infrastructure.