Summary
Flowise contains an unauthenticated OAuth2 token refresh endpoint that makes server-side HTTP requests to a credential-controlled token URL without adequate SSRF protections. An attacker may cause outbound requests to an attacker-controlled service, receive the remote response, and expose OAuth-related credential data.
Flowise contains an unauthenticated OAuth2 token refresh endpoint that makes server-side HTTP requests to a credential-controlled token URL without adequate SSRF protections. An attacker may cause outbound requests to an attacker-controlled service, receive the remote response, and expose OAuth-related credential data.
Affected context
The issue occurs in Flowise deployments where the OAuth2 token refresh endpoint is accessible without authentication and accepts a credential identifier associated with a configurable access token URL. Risk is increased when an attacker can influence that credential configuration or select credentials whose token endpoint is not restricted to trusted destinations.
The issue occurs in Flowise deployments where the OAuth2 token refresh endpoint is accessible without authentication and accepts a credential identifier associated with a configurable access token URL. Risk is increased when an attacker can influence that credential configuration or select credentials whose token endpoint is not restricted to trusted destinations.
Exploit preconditions
- Attack surface: HTTP POST OAuth2 token refresh API
- Required access: Access to the endpoint; authentication is not required by the affected design
- Trigger point: Processing a token refresh request for a credential
- Network condition: The Flowise server must be able to make outbound HTTP requests
- Why exploitation is possible: The server trusts a credential-controlled URL and forwards OAuth-related request data without enforcing destination or response restrictions
- Attack surface: HTTP POST OAuth2 token refresh API
- Required access: Access to the endpoint; authentication is not required by the affected design
- Trigger point: Processing a token refresh request for a credential
- Network condition: The Flowise server must be able to make outbound HTTP requests
- Why exploitation is possible: The server trusts a credential-controlled URL and forwards OAuth-related request data without enforcing destination or response restrictions
Why this happens
The vulnerability results from combining an unauthenticated token refresh operation with unrestricted server-side URL handling. The application performs an outbound request to an accessTokenUrl selected through credential configuration, without applying allowlists, destination validation, or equivalent SSRF controls, and then exposes the remote response to the caller.
This behavior is associated with CWE-639: Authorization Bypass Through User-Controlled Key, because access to a credential-selected operation is not sufficiently authorized or constrained. It also reflects an SSRF pattern in which attacker-influenced input determines a server-side network destination.
The vulnerability results from combining an unauthenticated token refresh operation with unrestricted server-side URL handling. The application performs an outbound request to an accessTokenUrl selected through credential configuration, without applying allowlists, destination validation, or equivalent SSRF controls, and then exposes the remote response to the caller.
This behavior is associated with CWE-639: Authorization Bypass Through User-Controlled Key, because access to a credential-selected operation is not sufficiently authorized or constrained. It also reflects an SSRF pattern in which attacker-influenced input determines a server-side network destination.
Potential impact
- An attacker could induce requests from the Flowise server to internal or external destinations
- OAuth client identifiers, client secrets, refresh tokens, or related response data may be exposed
- Internal services could receive unauthorized requests from a trusted network position
- The application could become a proxy for probing or interacting with restricted network resources
- Remote response content could be reflected to an unauthorized caller
- An attacker could induce requests from the Flowise server to internal or external destinations
- OAuth client identifiers, client secrets, refresh tokens, or related response data may be exposed
- Internal services could receive unauthorized requests from a trusted network position
- The application could become a proxy for probing or interacting with restricted network resources
- Remote response content could be reflected to an unauthorized caller
General mitigation guidance
Mitigation generally focuses on protecting token refresh operations and reducing trust in credential-controlled destinations.
Common defensive patterns include:
- Require authentication and authorization for credential refresh operations
- Restrict token endpoint destinations using explicit HTTPS-based allowlists
- Resolve hostnames and validate resulting addresses against private, loopback, link-local, and reserved network ranges
- Limit redirects, response sizes, connection targets, and outbound protocols
- Avoid reflecting complete upstream responses to API callers
- Keep OAuth client secrets and refresh tokens out of user-visible responses and logs
- Apply least-privilege network egress policies to the application runtime
- Separate credential administration from ordinary workflow execution
Mitigation generally focuses on protecting token refresh operations and reducing trust in credential-controlled destinations.
Common defensive patterns include:
- Require authentication and authorization for credential refresh operations
- Restrict token endpoint destinations using explicit HTTPS-based allowlists
- Resolve hostnames and validate resulting addresses against private, loopback, link-local, and reserved network ranges
- Limit redirects, response sizes, connection targets, and outbound protocols
- Avoid reflecting complete upstream responses to API callers
- Keep OAuth client secrets and refresh tokens out of user-visible responses and logs
- Apply least-privilege network egress policies to the application runtime
- Separate credential administration from ordinary workflow execution
How teams detect issues like this
Detection can include static analysis for server-side HTTP clients whose destinations derive from request data or stored user-controlled configuration. Code review should examine unauthenticated credential operations, URL allowlist enforcement, redirect handling, private-address blocking, response forwarding, and secret redaction.
Runtime monitoring can alert on outbound requests from Flowise to unexpected domains, private address ranges, unusual ports, or destinations that are not part of an approved token-service inventory. Policy enforcement in CI and API gateways can require authentication for credential-management routes and restrict outbound network access.
Detection can include static analysis for server-side HTTP clients whose destinations derive from request data or stored user-controlled configuration. Code review should examine unauthenticated credential operations, URL allowlist enforcement, redirect handling, private-address blocking, response forwarding, and secret redaction.
Runtime monitoring can alert on outbound requests from Flowise to unexpected domains, private address ranges, unusual ports, or destinations that are not part of an approved token-service inventory. Policy enforcement in CI and API gateways can require authentication for credential-management routes and restrict outbound network access.
