Summary
Flowise contains a server-side request forgery vulnerability in HTTP security checks that can be bypassed using IPv4-mapped IPv6 addresses. If an attacker controls DNS resolution for a hostname used by supported HTTP request features, they may direct requests to localhost, internal services, or cloud metadata endpoints.
Flowise contains a server-side request forgery vulnerability in HTTP security checks that can be bypassed using IPv4-mapped IPv6 addresses. If an attacker controls DNS resolution for a hostname used by supported HTTP request features, they may direct requests to localhost, internal services, or cloud metadata endpoints.
Affected context
The issue occurs in Flowise deployments where user-controlled or attacker-influenced hostnames are resolved by HTTP Node, API Chain, Document Loader, MCP tool, or other functionality using the shared secure request controls. Risk is higher when DNS resolution can return IPv4-mapped IPv6 addresses and the application relies on IPv4 CIDR deny-list entries without normalizing address representations first.
The issue occurs in Flowise deployments where user-controlled or attacker-influenced hostnames are resolved by HTTP Node, API Chain, Document Loader, MCP tool, or other functionality using the shared secure request controls. Risk is higher when DNS resolution can return IPv4-mapped IPv6 addresses and the application relies on IPv4 CIDR deny-list entries without normalizing address representations first.
Exploit preconditions
- Attack surface: Server-side HTTP request functionality and associated deny-list checks
- Required access: Ability to influence or control DNS resolution for a hostname consumed by a Flowise request feature
- Trigger point: Resolution and validation of the destination address before an outbound request
- Why exploitation is possible: IPv4-mapped IPv6 addresses may be classified as IPv6 while IPv4 deny-list rules are skipped, allowing restricted destinations to pass validation
- Attack surface: Server-side HTTP request functionality and associated deny-list checks
- Required access: Ability to influence or control DNS resolution for a hostname consumed by a Flowise request feature
- Trigger point: Resolution and validation of the destination address before an outbound request
- Why exploitation is possible: IPv4-mapped IPv6 addresses may be classified as IPv6 while IPv4 deny-list rules are skipped, allowing restricted destinations to pass validation
Why this happens
The vulnerability results from inconsistent handling of equivalent IP address representations. The security module checks IPv4-mapped IPv6 addresses as IPv6 values without first converting them to their IPv4 form, so IPv4 CIDR deny-list rules do not apply. This maps primarily to CWE-918: Server-Side Request Forgery, with CWE-1389: Improper Handling of Inconsistent Naming Conventions, because alternate textual or protocol representations of the same destination are not normalized before authorization decisions.
The vulnerability results from inconsistent handling of equivalent IP address representations. The security module checks IPv4-mapped IPv6 addresses as IPv6 values without first converting them to their IPv4 form, so IPv4 CIDR deny-list rules do not apply. This maps primarily to CWE-918: Server-Side Request Forgery, with CWE-1389: Improper Handling of Inconsistent Naming Conventions, because alternate textual or protocol representations of the same destination are not normalized before authorization decisions.
Potential impact
- Requests to localhost services could be issued from the Flowise server
- Internal network endpoints could be accessed or enumerated
- Cloud instance metadata could be retrieved
- Internal credentials, tokens, or configuration data may be exposed
- Compromised internal services could enable further lateral movement
- Requests to localhost services could be issued from the Flowise server
- Internal network endpoints could be accessed or enumerated
- Cloud instance metadata could be retrieved
- Internal credentials, tokens, or configuration data may be exposed
- Compromised internal services could enable further lateral movement
General mitigation guidance
Mitigation generally focuses on making destination validation representation-independent and reducing trust in attacker-controlled hostnames.
Common defensive patterns include:
- Normalize IPv4-mapped IPv6 addresses and equivalent address forms before applying allowlists or denylists
- Validate the final resolved IP address rather than relying only on the original hostname
- Apply consistent controls to IPv4, IPv6, loopback, link-local, private, and cloud-metadata ranges
- Prefer explicit destination allowlists for integrations that do not require arbitrary outbound access
- Re-check destinations after DNS resolution and account for rebinding or resolution changes
- Restrict outbound network access from application workers and apply least-privilege service permissions
- Avoid exposing response bodies from sensitive internal endpoints to untrusted users
Mitigation generally focuses on making destination validation representation-independent and reducing trust in attacker-controlled hostnames.
Common defensive patterns include:
- Normalize IPv4-mapped IPv6 addresses and equivalent address forms before applying allowlists or denylists
- Validate the final resolved IP address rather than relying only on the original hostname
- Apply consistent controls to IPv4, IPv6, loopback, link-local, private, and cloud-metadata ranges
- Prefer explicit destination allowlists for integrations that do not require arbitrary outbound access
- Re-check destinations after DNS resolution and account for rebinding or resolution changes
- Restrict outbound network access from application workers and apply least-privilege service permissions
- Avoid exposing response bodies from sensitive internal endpoints to untrusted users
How teams detect issues like this
Organizations can identify similar SSRF risks through:
- Static analysis for outbound request functions that accept user-influenced URLs
- Code review checks for IP filtering performed before DNS resolution or without address-family normalization
- Tests covering loopback, private, link-local, metadata, IPv4-mapped IPv6, and alternate textual address forms
- Network monitoring for application-originated requests to internal ranges and cloud metadata services
- Policy enforcement requiring centralized URL validation and outbound egress controls
- Automated security review tools that flag inconsistent IPv4 and IPv6 deny-list handling
Organizations can identify similar SSRF risks through:
- Static analysis for outbound request functions that accept user-influenced URLs
- Code review checks for IP filtering performed before DNS resolution or without address-family normalization
- Tests covering loopback, private, link-local, metadata, IPv4-mapped IPv6, and alternate textual address forms
- Network monitoring for application-originated requests to internal ranges and cloud metadata services
- Policy enforcement requiring centralized URL validation and outbound egress controls
- Automated security review tools that flag inconsistent IPv4 and IPv6 deny-list handling
