Summary
Frappe Builder's WebP conversion endpoint can be abused by a low-privilege authenticated user to make the server request internal URLs or cloud metadata services. Because redirects and resolved IP addresses are not consistently revalidated, fetched responses may be exposed through a world-readable files URL, enabling data exfiltration or blind internal-network probing.
Frappe Builder's WebP conversion endpoint can be abused by a low-privilege authenticated user to make the server request internal URLs or cloud metadata services. Because redirects and resolved IP addresses are not consistently revalidated, fetched responses may be exposed through a world-readable files URL, enabling data exfiltration or blind internal-network probing.
Affected context
The vulnerability occurs in deployments where the WebP conversion API accepts a user-controlled image URL and retrieves it from the server side. Risk is increased when the endpoint lacks the access control used by comparable asset-ingestion handlers, follows redirects, does not validate every resolved destination, and stores successful responses in publicly accessible file paths.
The vulnerability occurs in deployments where the WebP conversion API accepts a user-controlled image URL and retrieves it from the server side. Risk is increased when the endpoint lacks the access control used by comparable asset-ingestion handlers, follows redirects, does not validate every resolved destination, and stores successful responses in publicly accessible file paths.
Exploit preconditions
- Attack surface: The server-side image-fetching behavior in the WebP conversion API
- Required access: A low-privilege authenticated account able to invoke the endpoint
- Trigger point: Submission of an image URL that causes the server to perform an outbound request
- Network condition: The server must be able to reach the targeted internal address, metadata service, or redirect destination
- Why exploitation is possible: Destination validation is incomplete across redirects and DNS resolution, while the resulting image response may be placed at a world-readable URL
- Attack surface: The server-side image-fetching behavior in the WebP conversion API
- Required access: A low-privilege authenticated account able to invoke the endpoint
- Trigger point: Submission of an image URL that causes the server to perform an outbound request
- Network condition: The server must be able to reach the targeted internal address, metadata service, or redirect destination
- Why exploitation is possible: Destination validation is incomplete across redirects and DNS resolution, while the resulting image response may be placed at a world-readable URL
Why this happens
The underlying bug is server-side request forgery caused by treating a user-controlled URL as a trusted outbound resource without enforcing a complete destination policy.
The endpoint also lacks equivalent authorization checks and does not reliably revalidate resolved addresses after redirects or DNS changes. This maps to CWE-918: Server-Side Request Forgery, where application-controlled requests can reach unintended internal or external services.
The underlying bug is server-side request forgery caused by treating a user-controlled URL as a trusted outbound resource without enforcing a complete destination policy.
The endpoint also lacks equivalent authorization checks and does not reliably revalidate resolved addresses after redirects or DNS changes. This maps to CWE-918: Server-Side Request Forgery, where application-controlled requests can reach unintended internal or external services.
Potential impact
- An attacker may probe internal hosts and services through response behavior
- The server could access cloud instance metadata or other sensitive internal endpoints
- Retrieved responses could be exposed through a publicly readable files URL
- Internal credentials, configuration data, or service information could be exfiltrated
- The vulnerability could enable follow-on attacks against reachable administrative interfaces
- An attacker may probe internal hosts and services through response behavior
- The server could access cloud instance metadata or other sensitive internal endpoints
- Retrieved responses could be exposed through a publicly readable files URL
- Internal credentials, configuration data, or service information could be exfiltrated
- The vulnerability could enable follow-on attacks against reachable administrative interfaces
General mitigation guidance
Mitigation generally focuses on reducing trust in user-supplied URLs and enforcing authorization before server-side fetching.
Common defensive patterns include:
- Applying endpoint-level authorization consistent with other asset-ingestion operations
- Allowing only explicitly approved URL schemes, hostnames, ports, and destinations
- Resolving hostnames and rejecting private, loopback, link-local, and metadata-network addresses
- Revalidating the destination after every redirect and before connecting
- Limiting redirects, response sizes, protocols, and request duration
- Preferably retrieving approved assets through controlled proxy services or accepting direct uploads instead of arbitrary URLs
- Storing fetched content with non-public permissions and access-controlled URLs
- Running outbound fetchers with restricted network egress and minimal privileges
Mitigation generally focuses on reducing trust in user-supplied URLs and enforcing authorization before server-side fetching.
Common defensive patterns include:
- Applying endpoint-level authorization consistent with other asset-ingestion operations
- Allowing only explicitly approved URL schemes, hostnames, ports, and destinations
- Resolving hostnames and rejecting private, loopback, link-local, and metadata-network addresses
- Revalidating the destination after every redirect and before connecting
- Limiting redirects, response sizes, protocols, and request duration
- Preferably retrieving approved assets through controlled proxy services or accepting direct uploads instead of arbitrary URLs
- Storing fetched content with non-public permissions and access-controlled URLs
- Running outbound fetchers with restricted network egress and minimal privileges
How teams detect issues like this
Detection approaches can include:
- Static analysis for HTTP client calls that consume request parameters without URL validation
- Code review checks for missing authorization on server-side fetch endpoints
- Review of redirect handling, DNS resolution, and private-address filtering
- Runtime monitoring for requests from application servers to loopback, private, link-local, and cloud-metadata ranges
- Network egress policies that alert on unexpected internal destinations or metadata-service access
- Tests that verify validation is repeated after redirects and DNS changes
- Automated security review tools that identify SSRF-prone URL-fetching patterns
Detection approaches can include:
- Static analysis for HTTP client calls that consume request parameters without URL validation
- Code review checks for missing authorization on server-side fetch endpoints
- Review of redirect handling, DNS resolution, and private-address filtering
- Runtime monitoring for requests from application servers to loopback, private, link-local, and cloud-metadata ranges
- Network egress policies that alert on unexpected internal destinations or metadata-service access
- Tests that verify validation is repeated after redirects and DNS changes
- Automated security review tools that identify SSRF-prone URL-fetching patterns
