Flowise CVE-2026-73604

Exploitation requires a valid authenticated session in the target Flowise workspace with the credentials:view permission assigned to the user's role. This permission is a standard Flowise role capability and does not require administrative access; developer, analyst, or similar low-privilege roles commonly carry it. The attacker must be able to reach the Flowise API server over the network (AV:N), and no special non-default configuration, specific deployment mode, or elevated privilege beyond credentials:view is required. Exploitation is scoped to credentials within the attacker's workspace; cross-workspace access is not indicated by the available data. The primary limiting factor is authentication: unauthenticated external attackers cannot exploit this endpoint without first obtaining a valid Flowise account credential.

The CVSS 4.0 score of 7.1 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) is a reasonable representation of the direct flaw, but the effective blast radius is substantially higher because the confidentiality impact is not limited to Flowise itself. Exposed artifacts - database connection strings, cloud service account private keys, and third-party API tokens - enable lateral movement into external systems entirely outside Flowise's scope, making the downstream risk resemble a credential stuffing or cloud account takeover event rather than an isolated application vulnerability. The PR:L metric correctly reflects that a low-privilege Flowise role with credentials:view is sufficient; this is a standard role assignment in many workspace configurations, meaning the attack surface includes insiders and any compromised low-privilege account. No EPSS score was provided in the input data and this CVE does not appear in CISA KEV, so exploitation probability cannot be quantitatively assessed and active exploitation is not confirmed. The absence of public exploit code is a modest mitigating signal, but the attack requires only a valid session token and knowledge of a credential ID - both of which are trivially obtainable for authenticated users. Organizations with multi-user Flowise deployments should prioritize this over its base score suggests, because any authenticated workspace member can exfiltrate every stored credential regardless of whether those credentials belong to their own workflows.

An authenticated Flowise user with the credentials:view role enumerates credential IDs visible in their workspace UI, then issues a series of GET /api/v1/credentials/:id requests using their session token. Each response contains a plainDataObj field with fully decrypted values - a PostgreSQL connection string including username and password, a Google service account JSON blob with an RSA private key, or an AWS access key pair - which the attacker then uses to authenticate directly to the downstream cloud or database services. No public exploit code has been identified, but the attack requires only standard HTTP tooling and a valid session token.