Summary
Kan contains an unauthenticated server-side request forgery vulnerability in the attachment download endpoint. When S3_ENDPOINT is not configured, an attacker may influence the destination requested by the server and access internal services, localhost ports, or cloud instance metadata.
Kan contains an unauthenticated server-side request forgery vulnerability in the attachment download endpoint. When S3_ENDPOINT is not configured, an attacker may influence the destination requested by the server and access internal services, localhost ports, or cloud instance metadata.
Affected context
The issue affects Kan deployments using the attachment download API when S3_ENDPOINT is unset and request parameters can influence the URL passed to the server-side fetch operation. The vulnerability is associated with an incomplete remediation of an earlier SSRF issue and does not require authentication at the affected route.
The issue affects Kan deployments using the attachment download API when S3_ENDPOINT is unset and request parameters can influence the URL passed to the server-side fetch operation. The vulnerability is associated with an incomplete remediation of an earlier SSRF issue and does not require authentication at the affected route.
Exploit preconditions
- Attack surface: The
/api/download/attatchmentHTTP route - Required access: Network access to the Kan server; authentication is not required
- Trigger point: Processing an attachment download request
- Configuration condition:
S3_ENDPOINTis unset - Why exploitation is possible: Attacker-controlled URL-related parameters can influence the server-side
fetch()destination without sufficient destination restrictions
- Attack surface: The
/api/download/attatchmentHTTP route - Required access: Network access to the Kan server; authentication is not required
- Trigger point: Processing an attachment download request
- Configuration condition:
S3_ENDPOINTis unset - Why exploitation is possible: Attacker-controlled URL-related parameters can influence the server-side
fetch()destination without sufficient destination restrictions
Why this happens
The vulnerability results from incomplete validation and restriction of attacker-influenced request destinations. The attachment download handler passes controllable URL parameters to a server-side HTTP client without reliably enforcing an approved host, scheme, or network boundary. This maps to CWE-918, where a server is induced to make requests to unintended locations on behalf of an external requester.
The vulnerability results from incomplete validation and restriction of attacker-influenced request destinations. The attachment download handler passes controllable URL parameters to a server-side HTTP client without reliably enforcing an approved host, scheme, or network boundary. This maps to CWE-918, where a server is induced to make requests to unintended locations on behalf of an external requester.
Potential impact
- An attacker may read responses from internal services
- An attacker could access services bound to localhost
- Cloud instance metadata and associated credentials may be exposed
- Internal network topology or service configuration may be disclosed
- Compromised metadata credentials could enable further cloud resource access
- An attacker may read responses from internal services
- An attacker could access services bound to localhost
- Cloud instance metadata and associated credentials may be exposed
- Internal network topology or service configuration may be disclosed
- Compromised metadata credentials could enable further cloud resource access
General mitigation guidance
Mitigation generally focuses on enforcing a strict server-side destination
policy for all attachment retrieval requests.
Common defensive patterns include:
- Allowing requests only to explicitly approved storage hosts
- Rejecting private, loopback, link-local, and other restricted address ranges
- Restricting accepted URL schemes and disabling redirects to untrusted destinations
- Resolving hostnames and validating the resulting addresses before connection
- Treating client-supplied URL parameters as untrusted identifiers rather than fetch targets
- Using secure-by-default storage configuration and requiring an explicit endpoint
- Applying network egress controls and least-privilege cloud identity permissions
Mitigation generally focuses on enforcing a strict server-side destination
policy for all attachment retrieval requests.
Common defensive patterns include:
- Allowing requests only to explicitly approved storage hosts
- Rejecting private, loopback, link-local, and other restricted address ranges
- Restricting accepted URL schemes and disabling redirects to untrusted destinations
- Resolving hostnames and validating the resulting addresses before connection
- Treating client-supplied URL parameters as untrusted identifiers rather than fetch targets
- Using secure-by-default storage configuration and requiring an explicit endpoint
- Applying network egress controls and least-privilege cloud identity permissions
How teams detect issues like this
Detection approaches may include:
- Static analysis for server-side HTTP clients receiving request-derived URLs
- Code review checks for missing allowlists, redirect controls, and private-address filtering
- Dynamic testing with requests targeting loopback, private, link-local, and metadata ranges
- Web application firewall or gateway policies that restrict suspicious destination parameters
- Network monitoring for unexpected outbound requests from the Kan service
- Automated security review tools that identify SSRF-prone data flows
Detection approaches may include:
- Static analysis for server-side HTTP clients receiving request-derived URLs
- Code review checks for missing allowlists, redirect controls, and private-address filtering
- Dynamic testing with requests targeting loopback, private, link-local, and metadata ranges
- Web application firewall or gateway policies that restrict suspicious destination parameters
- Network monitoring for unexpected outbound requests from the Kan service
- Automated security review tools that identify SSRF-prone data flows
