Summary
Chaskiq contains a server-side request forgery vulnerability in the createUrlUpload GraphQL mutation. An unauthenticated attacker may cause the server to request arbitrary URLs, including internal services or cloud instance metadata endpoints, and retrieve responses through the returned ActiveStorage blob URL.
Chaskiq contains a server-side request forgery vulnerability in the createUrlUpload GraphQL mutation. An unauthenticated attacker may cause the server to request arbitrary URLs, including internal services or cloud instance metadata endpoints, and retrieve responses through the returned ActiveStorage blob URL.
Affected context
The vulnerability occurs in Chaskiq deployments that expose the GraphQL API and allow unauthenticated use of the createUrlUpload mutation. It becomes risky when the application server can make outbound requests to internal networks or cloud metadata services and subsequently exposes fetched content through an accessible ActiveStorage URL.
The vulnerability occurs in Chaskiq deployments that expose the GraphQL API and allow unauthenticated use of the createUrlUpload mutation. It becomes risky when the application server can make outbound requests to internal networks or cloud metadata services and subsequently exposes fetched content through an accessible ActiveStorage URL.
Exploit preconditions
- Attack surface: Publicly reachable GraphQL API at
POST /graphql - Required access: No authentication may be required to invoke the vulnerable mutation
- Trigger point: Processing of the
createUrlUploadmutation - Target condition: The server must be able to reach the attacker-selected URL
- Why exploitation is possible: Server-side URL fetching is not sufficiently restricted, and the retrieved response can be accessed through the generated blob URL
- Attack surface: Publicly reachable GraphQL API at
POST /graphql - Required access: No authentication may be required to invoke the vulnerable mutation
- Trigger point: Processing of the
createUrlUploadmutation - Target condition: The server must be able to reach the attacker-selected URL
- Why exploitation is possible: Server-side URL fetching is not sufficiently restricted, and the retrieved response can be accessed through the generated blob URL
Why this happens
The underlying issue is server-side request forgery, mapped to CWE-918. The application accepts a user-controlled URL and makes a server-side request without adequately constraining destination hosts, network ranges, protocols, or response exposure. Because the server occupies a more trusted network position than an external client, this behavior may provide access to internal services and sensitive endpoint responses.
The underlying issue is server-side request forgery, mapped to CWE-918. The application accepts a user-controlled URL and makes a server-side request without adequately constraining destination hosts, network ranges, protocols, or response exposure. Because the server occupies a more trusted network position than an external client, this behavior may provide access to internal services and sensitive endpoint responses.
Potential impact
- Internal services may be queried from the application network
- Cloud instance metadata and temporary credentials could be exposed
- Sensitive internal responses may be retrieved through generated blob URLs
- Network boundaries and access-control assumptions could be bypassed
- Internal systems may be probed or abused through the application server
- Internal services may be queried from the application network
- Cloud instance metadata and temporary credentials could be exposed
- Sensitive internal responses may be retrieved through generated blob URLs
- Network boundaries and access-control assumptions could be bypassed
- Internal systems may be probed or abused through the application server
General mitigation guidance
Mitigation generally focuses on removing unnecessary server-side fetching and reducing trust in user-supplied URLs.
Common defensive patterns include:
- Allowing only explicitly approved schemes, hosts, and destination ports
- Applying network-aware allowlists rather than relying only on domain-name checks
- Blocking loopback, link-local, private, and reserved address ranges after resolution
- Rechecking resolved addresses to reduce DNS-rebinding exposure
- Preventing access to cloud metadata services through application and network controls
- Avoiding public exposure of fetched response bodies and generated object URLs
- Applying authentication, authorization, rate limits, and least-privilege network egress
Mitigation generally focuses on removing unnecessary server-side fetching and reducing trust in user-supplied URLs.
Common defensive patterns include:
- Allowing only explicitly approved schemes, hosts, and destination ports
- Applying network-aware allowlists rather than relying only on domain-name checks
- Blocking loopback, link-local, private, and reserved address ranges after resolution
- Rechecking resolved addresses to reduce DNS-rebinding exposure
- Preventing access to cloud metadata services through application and network controls
- Avoiding public exposure of fetched response bodies and generated object URLs
- Applying authentication, authorization, rate limits, and least-privilege network egress
How teams detect issues like this
Detection can include:
- Static analysis for HTTP clients receiving directly user-controlled URLs
- Code review checks for URL validation, redirect handling, DNS resolution, and response publishing
- API tests covering private, loopback, link-local, reserved, and metadata destinations
- Network monitoring for unexpected outbound requests from application workers
- Web-application monitoring for unusual GraphQL mutation usage and repeated blob retrievals
- Policy enforcement that requires approved destination allowlists for server-side fetch features
Automated application-security and API-security review tools may help identify unsafe URL-fetching patterns.
Detection can include:
- Static analysis for HTTP clients receiving directly user-controlled URLs
- Code review checks for URL validation, redirect handling, DNS resolution, and response publishing
- API tests covering private, loopback, link-local, reserved, and metadata destinations
- Network monitoring for unexpected outbound requests from application workers
- Web-application monitoring for unusual GraphQL mutation usage and repeated blob retrievals
- Policy enforcement that requires approved destination allowlists for server-side fetch features
Automated application-security and API-security review tools may help identify unsafe URL-fetching patterns.
