Summary
Flowise versions before 3.1.3 expose an OAuth credential refresh endpoint without authentication. An attacker who knows a credential ID may obtain a newly refreshed access token for the connected service and may consume refresh-token quota.
Flowise versions before 3.1.3 expose an OAuth credential refresh endpoint without authentication. An attacker who knows a credential ID may obtain a newly refreshed access token for the connected service and may consume refresh-token quota.
Affected context
The issue occurs in Flowise deployments where the /api/v1/oauth2-credential/refresh/:credentialId endpoint is reachable and exempted from authentication. The endpoint decrypts stored OAuth credentials, contacts the configured provider using the client secret and refresh token, and returns the resulting access token to the caller. Exploitation depends on an attacker obtaining or guessing a valid credential identifier and reaching the affected API.
The issue occurs in Flowise deployments where the /api/v1/oauth2-credential/refresh/:credentialId endpoint is reachable and exempted from authentication. The endpoint decrypts stored OAuth credentials, contacts the configured provider using the client secret and refresh token, and returns the resulting access token to the caller. Exploitation depends on an attacker obtaining or guessing a valid credential identifier and reaching the affected API.
Exploit preconditions
- Attack surface: The Flowise OAuth2 credential refresh API
- Required access: Network access to the endpoint and a valid credential ID; authentication is not required by the affected route
- Trigger point: A request to the credential refresh endpoint
- Why exploitation is possible: The route refreshes a stored credential and returns the access token without first establishing that the requester is authorized to use that credential
- Attack surface: The Flowise OAuth2 credential refresh API
- Required access: Network access to the endpoint and a valid credential ID; authentication is not required by the affected route
- Trigger point: A request to the credential refresh endpoint
- Why exploitation is possible: The route refreshes a stored credential and returns the access token without first establishing that the requester is authorized to use that credential
Why this happens
The underlying flaw is an authorization failure combined with excessive exposure of sensitive authentication data. A credential refresh operation is placed in an unauthenticated allowlist, and its response includes the provider-issued access token. This behavior maps to CWE-200 because authentication material is disclosed to an unauthorized party; it also reflects missing access control around a sensitive operation.
The underlying flaw is an authorization failure combined with excessive exposure of sensitive authentication data. A credential refresh operation is placed in an unauthenticated allowlist, and its response includes the provider-issued access token. This behavior maps to CWE-200 because authentication material is disclosed to an unauthorized party; it also reflects missing access control around a sensitive operation.
Potential impact
- An attacker may access resources exposed through the victim's connected OAuth service.
- Stolen access tokens could allow unauthorized actions within the provider's permitted scope.
- Repeated requests could exhaust refresh-token quotas or trigger provider-side rate limits.
- Exposed client secrets or refresh credentials may increase the impact of a compromised Flowise instance.
- An attacker may access resources exposed through the victim's connected OAuth service.
- Stolen access tokens could allow unauthorized actions within the provider's permitted scope.
- Repeated requests could exhaust refresh-token quotas or trigger provider-side rate limits.
- Exposed client secrets or refresh credentials may increase the impact of a compromised Flowise instance.
General mitigation guidance
Mitigation generally focuses on enforcing authorization for every credential
operation and minimizing the disclosure of authentication material.
Common defensive patterns include:
- Require authenticated, authorized access before resolving or refreshing any credential.
- Bind credentials to the owning user, workspace, or tenant and enforce that relationship server-side.
- Return only the minimum response data needed by a trusted internal workflow, rather than exposing access tokens through general API responses.
- Store secrets using protected mechanisms and avoid placing them in client-visible or broadly accessible responses.
- Apply least-privilege scopes to connected OAuth applications and isolate tenant data.
- Add rate limits, refresh-token-use controls, and monitoring for repeated refresh attempts.
- Treat credential identifiers as non-secret references that nevertheless require authorization and should not provide object access by themselves.
Mitigation generally focuses on enforcing authorization for every credential
operation and minimizing the disclosure of authentication material.
Common defensive patterns include:
- Require authenticated, authorized access before resolving or refreshing any credential.
- Bind credentials to the owning user, workspace, or tenant and enforce that relationship server-side.
- Return only the minimum response data needed by a trusted internal workflow, rather than exposing access tokens through general API responses.
- Store secrets using protected mechanisms and avoid placing them in client-visible or broadly accessible responses.
- Apply least-privilege scopes to connected OAuth applications and isolate tenant data.
- Add rate limits, refresh-token-use controls, and monitoring for repeated refresh attempts.
- Treat credential identifiers as non-secret references that nevertheless require authorization and should not provide object access by themselves.
How teams detect issues like this
Detection approaches can include:
- Static analysis and API policy checks for sensitive routes that are included in unauthenticated allowlists.
- Code review searches for endpoints that decrypt credentials, invoke OAuth refresh flows, or return access tokens.
- Tests verifying that unauthenticated and cross-user requests cannot refresh or retrieve another principal's credentials.
- Response-data rules that flag access tokens, refresh tokens, client secrets, or equivalent authentication material in API responses.
- Runtime monitoring for unusual refresh frequency, credential-ID enumeration, and access to multiple tenants' OAuth connections.
Automated API security testing and policy-as-code tools can help identify missing authorization and sensitive-data exposure.
Detection approaches can include:
- Static analysis and API policy checks for sensitive routes that are included in unauthenticated allowlists.
- Code review searches for endpoints that decrypt credentials, invoke OAuth refresh flows, or return access tokens.
- Tests verifying that unauthenticated and cross-user requests cannot refresh or retrieve another principal's credentials.
- Response-data rules that flag access tokens, refresh tokens, client secrets, or equivalent authentication material in API responses.
- Runtime monitoring for unusual refresh frequency, credential-ID enumeration, and access to multiple tenants' OAuth connections.
Automated API security testing and policy-as-code tools can help identify missing authorization and sensitive-data exposure.
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
