GHSA-7G73-99R4-M4MJ: Root-Cause Patch Removes encryptedData from FlowiseAI Credential Responses

Vulnerability

FlowiseAI exposed the encryptedData property in credential-related API responses prior to 3.1.2. Per the advisory, this leaked encrypted credential material to API consumers, creating a credential-compromise path if the master encryption key was later obtained or otherwise exposed. The vulnerable server logic directly propagated credential records into the response object without redacting the sensitive field, as shown in the patch diff from the official fix official patch reference and described by the GitHub Security Advisory.

dbResponse.push(...credentials)
dbResponse = [...credentials]

This is an API serialization/data minimization failure: encrypted secrets were treated as ordinary response fields instead of internal-only persistence data.

Patch

The patch modifies the credential service to omit encryptedData before appending or assigning credential objects into dbResponse. It also adds a regression test asserting that the API client result does not contain the leaked property. The relevant changes are documented in the official patch reference.

dbResponse.push(...credentials.map((c) => omit(c, ['encryptedData'])))
dbResponse = credentials.map((c) => omit(c, ['encryptedData'])))

Regression coverage was added with a test that verifies returned credentials do not expose the field:

it('should not expose encryptedData in the response', async () => {
    const mockCredentials = [{ id: '1', name: 'My OpenAI Key', credentialName: 'openAIApi' }]
    ;(mockClient.get as jest.Mock).mockResolvedValue({ data: mockCredentials })

    const result = await api.getCredentialsByName('openAIApi')
    for (const credential of result) {
        expect(credential).not.toHaveProperty('encryptedData')
    }
})

Review

Pros

The fix directly targets the disclosed leak mechanism by removing encryptedData from server-generated responses rather than relying on clients to ignore it. That is the correct trust boundary: sensitive fields must be redacted server-side. The use of omit(c, ['encryptedData']) is explicit and easy to audit in the modified response-building paths. The added regression test is well aligned with the vulnerability because it asserts the absence of the exact field that should never be serialized. This materially reduces the chance of reintroducing the issue in the covered API flow. The patch is also low-risk from a functional perspective because it preserves the rest of the credential object shape while removing only the sensitive ciphertext.

Cons

The provided diff shows targeted redaction in the modified credential service paths, but it does not by itself prove that every credential-returning endpoint, serializer, or alternate code path in the application applies the same omission. If other services return raw credential entities, similar leakage could persist outside the patched locations. The regression test is valuable but narrow: it validates one API call pattern and one forbidden property, not a broader response schema contract across all credential APIs. Also, the patch removes only encryptedData; if there are other sensitive persistence-only fields associated with credentials, they would need separate review.

Verdict

Root-cause.

Based on the supplied patch, the vulnerability stemmed from server-side inclusion of a sensitive field in serialized API responses, and the fix corrects that behavior at the response construction point by omitting encryptedData. This addresses the actual disclosure primitive described in the advisory, rather than merely masking symptoms on the client side. Engineers should still verify that all credential-related endpoints and serializers consistently enforce the same redaction policy, but the shown change is technically aligned with a root-cause remediation for the disclosed issue. Additional context is also summarized by the external report at cvereports.com.