CVE-2026-27127: Craftcms Craft CMS SSRF Vulnerability

CVE-2026-27127 Overview

CVE-2026-27127 is a Time-of-Check-Time-of-Use (TOCTOU) vulnerability in Craft CMS that enables DNS rebinding attacks to bypass Server-Side Request Forgery (SSRF) validation. The vulnerability exists in the GraphQL Asset mutation where DNS resolution is performed separately from the HTTP request, allowing an attacker's DNS server to return different IP addresses during validation compared to the actual request. This vulnerability is a bypass of the security fix for CVE-2025-68437 and expands the attack surface to all blocked IPs, not just IPv6 endpoints.

Critical Impact

Authenticated attackers with GraphQL schema permissions can bypass SSRF protections to access internal network resources, potentially exposing sensitive data from internal services and cloud metadata endpoints.

Affected Products

• Craft CMS versions 4.5.0-RC1 through 4.16.18
• Craft CMS versions 5.0.0-RC1 through 5.8.22
• Installations with GraphQL schema write permissions enabled (including misconfigured Public Schema)

Discovery Timeline

• 2026-02-24 - CVE-2026-27127 published to NVD
• 2026-02-25 - Last updated in NVD database

Technical Details for CVE-2026-27127

Vulnerability Analysis

The vulnerability exists in Craft CMS's GraphQL Asset mutation handling, specifically in the SSRF validation mechanism. When processing asset uploads from external URLs, the CMS validates the target hostname by resolving it to an IP address and checking against a blocklist. However, this DNS resolution occurs at a different time than the actual HTTP request, creating a classic Time-of-Check-Time-of-Use (TOCTOU) race condition.

This design flaw allows DNS rebinding attacks where an attacker controls a DNS server configured with a very short TTL (Time To Live). During the validation check, the DNS server returns a safe, allowed IP address. By the time the actual HTTP request is made, the DNS entry has expired and a subsequent lookup returns an internal IP address (such as 127.0.0.1, 169.254.169.254 for cloud metadata, or other internal network addresses).

The vulnerability requires authenticated access with specific GraphQL permissions: the ability to edit assets in a volume and create assets in a volume. These permissions could be granted through authenticated user GraphQL schema access or, critically, through misconfigured Public Schema settings that inadvertently enable write permissions.

Root Cause

The root cause is the separation of DNS resolution between the SSRF validation check and the actual HTTP request execution. CWE-367 (Time-of-Check Time-of-Use race condition) accurately describes this class of vulnerability where a security check and the operation it's meant to protect occur at different times, allowing the underlying state to change between them.

Attack Vector

The attack requires network access and an authenticated user with appropriate GraphQL schema permissions. An attacker would:

1. Set up a malicious DNS server with short TTL records
2. Configure the DNS to return an allowed IP for initial resolution
3. Submit a GraphQL mutation to create/edit an asset with the malicious hostname
4. The CMS validates the URL (DNS returns allowed IP)
5. Between validation and request, the DNS record changes to an internal IP
6. The HTTP request is made to the now-internal IP, bypassing SSRF protection

The following patch demonstrates how Craft CMS addressed this vulnerability by utilizing GuzzleHttp\TransferStats to ensure DNS resolution and HTTP request occur atomically:

 use GraphQL\Type\Definition\ResolveInfo;
 use GuzzleHttp\Client;
 use GuzzleHttp\RequestOptions;
+use GuzzleHttp\TransferStats;
 use Illuminate\Support\Collection;
 use Throwable;
 use yii\base\Exception;

Source: GitHub Commit Update

The fix introduces TransferStats to capture the actual IP address used during the HTTP request, allowing validation to occur on the resolved IP at request time rather than during a separate DNS lookup.

Detection Methods for CVE-2026-27127

Indicators of Compromise

• Unusual GraphQL mutations targeting the Asset endpoint with external URLs
• DNS queries to domains with extremely short TTL values (1-2 seconds)
• HTTP requests to internal IP ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.169.254) originating from the Craft CMS application
• Log entries showing asset creation attempts with hostnames that resolve to different IPs on repeated lookups

Detection Strategies

• Monitor GraphQL query logs for createAsset or saveAsset mutations containing external URLs
• Implement DNS monitoring to detect queries with suspiciously short TTL responses
• Deploy network segmentation alerts for internal service access from web application servers
• Review Craft CMS access logs for patterns indicating SSRF exploitation attempts

Monitoring Recommendations

• Enable detailed logging for GraphQL API requests, particularly those involving asset manipulation
• Configure network monitoring to alert on outbound connections from the CMS server to internal IP ranges
• Audit GraphQL schema permissions regularly, especially Public Schema configurations
• Monitor for access to cloud metadata endpoints (169.254.169.254) from application servers

How to Mitigate CVE-2026-27127

Immediate Actions Required

• Upgrade Craft CMS 4.x installations to version 4.16.19 or later
• Upgrade Craft CMS 5.x installations to version 5.8.23 or later
• Audit GraphQL schema permissions and disable write access in Public Schema if enabled
• Review user accounts with GraphQL asset editing permissions

Patch Information

Craft CMS has released patched versions that address this vulnerability. The fix is available in versions 4.16.19 and 5.8.23. The patch modifies the Asset mutation resolver to use GuzzleHttp\TransferStats for validating the actual IP address at request time, eliminating the TOCTOU race condition. For detailed technical information, see the GitHub Security Advisory GHSA-gp2f-7wcm-5fhx and the related GitHub Security Advisory GHSA-x27p-wfqw-hfcc.

Workarounds

• Restrict GraphQL schema permissions to remove asset creation and editing capabilities for untrusted users
• Disable GraphQL Public Schema entirely or ensure it has no write permissions
• Implement network-level egress filtering to block requests to internal IP ranges from the web server
• Deploy a web application firewall (WAF) rule to inspect and block GraphQL mutations with suspicious external URLs

# Example: Restrict outbound connections from web server to internal networks (iptables)
# Block connections to localhost from web application
iptables -A OUTPUT -o lo -m owner --uid-owner www-data -j DROP
# Block connections to private IP ranges
iptables -A OUTPUT -d 10.0.0.0/8 -m owner --uid-owner www-data -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -m owner --uid-owner www-data -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -m owner --uid-owner www-data -j DROP
# Block cloud metadata endpoint
iptables -A OUTPUT -d 169.254.169.254 -m owner --uid-owner www-data -j DROP