CVE-2026-27127
TOCTOU SSRF Vulnerability in Craft CMS GraphQL Asset Mutation
Publication date: 2026-02-24
Last updated on: 2026-02-25
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| craftcms | craft_cms | 5.0.0 |
| craftcms | craft_cms | 5.0.0 |
| craftcms | craft_cms | 3.5.0 |
| craftcms | craft_cms | From 3.5.1 (inc) to 4.16.19 (exc) |
| craftcms | craft_cms | From 5.0.1 (inc) to 5.8.23 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-367 | The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': 'CVE-2026-27127 is a Server-Side Request Forgery (SSRF) protection bypass vulnerability in Craft CMS’s GraphQL Asset mutation. It arises from a Time-of-Check-Time-of-Use (TOCTOU) race condition caused by separate DNS resolutions during validation and the actual HTTP request.'}, {'type': 'paragraph', 'content': "During validation, the system uses PHP's gethostbyname() to resolve the hostname and check if the IP is within a blocked set of cloud metadata IP addresses. However, the actual HTTP request later performs a second DNS resolution independently using Guzzle/libcurl."}, {'type': 'paragraph', 'content': 'An attacker controlling a malicious DNS server can exploit this by returning a safe IP address during validation and a blocked cloud metadata IP address during the request. This DNS rebinding attack bypasses SSRF protections, allowing access to sensitive cloud metadata endpoints and retrieval of credentials such as IAM roles or service account tokens.'}, {'type': 'paragraph', 'content': 'Exploitation requires GraphQL schema permissions to edit or create assets in a volume, which may be granted to authenticated users or misconfigured public schemas. The root cause is the TOCTOU vulnerability from two separate DNS lookups returning different IPs.'}] [1]
How can this vulnerability impact me? :
This vulnerability can allow an attacker to bypass SSRF protections and access sensitive internal cloud metadata services from the Craft CMS server.
By exploiting this, an attacker can retrieve credentials such as IAM roles, service account tokens, or instance identity documents from cloud providers like AWS, GCP, Azure, Alibaba Cloud, and Oracle Cloud.
With these credentials, the attacker could execute arbitrary code, for example by launching new instances with injected SSH keys, potentially leading to full compromise of cloud infrastructure.
The vulnerability requires specific GraphQL permissions, but if those are granted or misconfigured, the impact can be severe, including unauthorized access and control over cloud resources.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection of this vulnerability involves monitoring for suspicious DNS rebinding activity and unauthorized access attempts to cloud metadata IP addresses such as 169.254.169.254 or other known internal IPs used by cloud providers.
Since the vulnerability exploits a Time-of-Check-Time-of-Use (TOCTOU) race condition with separate DNS resolutions, network detection can focus on identifying DNS queries that resolve to different IP addresses for the same hostname within a short time frame.
You can use network monitoring tools or packet capture utilities like tcpdump or Wireshark to observe DNS traffic and HTTP requests from your Craft CMS server.
- Use tcpdump to capture DNS queries and responses: tcpdump -i <interface> port 53 -w dns_traffic.pcap
- Analyze captured DNS traffic with Wireshark to check for DNS rebinding patterns (multiple IPs returned for the same hostname).
- Monitor HTTP requests from the server to internal IP ranges (e.g., 169.254.169.254) using commands like: sudo netstat -anp | grep <craft_cms_process> or sudo lsof -i -n -P | grep <craft_cms_process>
Additionally, reviewing application logs for GraphQL asset mutation requests from authenticated users with permissions to edit or create assets may help identify exploitation attempts.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading Craft CMS to a patched version: 4.16.19 or later for the 4.x series, or 5.8.23 or later for the 5.x series.
If upgrading immediately is not possible, apply the following mitigations:
- Implement DNS pinning by resolving hostnames once during validation and forcing HTTP requests to use the same resolved IP address via options like CURLOPT_RESOLVE in libcurl.
- Enforce network egress filtering to block outgoing requests to known cloud metadata IP addresses such as 169.254.169.254, 169.254.170.2, 100.100.100.200, and 192.0.0.192.
- Enforce IMDSv2 (Instance Metadata Service version 2) on cloud instances to require token headers for metadata access, reducing risk if SSRF occurs.
- Review and restrict GraphQL schema permissions to ensure only trusted users have asset editing or creation rights.
The official patch strengthens hostname and IP validation during asset uploads to prevent SSRF by blocking requests to internal or cloud metadata IPs and hostnames.