CVE-2026-45660: Statamic CMS SSRF Vulnerability

CVE-2026-45660 Overview

CVE-2026-45660 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] in Statamic, a Laravel and Git powered content management system (CMS). The flaw exists in the Glide image proxy, where URL validation can be bypassed using a non-normalized IP representation. An unauthenticated attacker can force the server to issue HTTP requests to internal addresses, including loopback interfaces, private network ranges, and cloud metadata endpoints. The issue affects deployments that pass user-supplied URLs to Glide. Sites running PHP 8.3 or newer are not affected. Statamic resolved the vulnerability in versions 5.73.22 and 6.18.1.

Critical Impact
Unauthenticated attackers can pivot through the Statamic server to reach cloud metadata services such as 169.254.169.254, potentially exposing IAM credentials and internal infrastructure.

Affected Products

Statamic CMS versions prior to 5.73.22
Statamic CMS 6.x versions prior to 6.18.1
Statamic deployments running on PHP versions earlier than 8.3 that pass user-supplied URLs to Glide

Discovery Timeline

2026-05-29 - CVE-2026-45660 published to NVD
2026-06-01 - Last updated in NVD database

Technical Details for CVE-2026-45660

Vulnerability Analysis

The vulnerability resides in the Glide image proxy component of Statamic. Glide accepts URLs that point to remote images, fetches them server-side, and processes them for delivery. To prevent SSRF, Statamic validates that the target host resolves to a public IP address. The check fails because the IP representation is not normalized before evaluation. Attackers can supply IP literals in alternative encodings, such as octal, hexadecimal, decimal long-form, or IPv4-mapped IPv6 notation, that bypass the public-IP filter but still resolve to internal targets when the HTTP client performs the actual request.

Sites running PHP 8.3 or later are unaffected because PHP 8.3 introduced stricter IP parsing semantics in FILTER_VALIDATE_IP and related socket functions, which reject or normalize the ambiguous representations the validator relied on.

Root Cause

The root cause is a parser differential between the validation routine and the outbound HTTP client. The validator interprets the supplied IP one way and concludes the address is public, while the underlying network stack interprets the same string differently and connects to an internal host. This is a classic SSRF filter bypass pattern documented under CWE-918: Server-Side Request Forgery.

Attack Vector

An unauthenticated attacker submits a crafted URL to any Statamic endpoint that forwards user-supplied URLs to Glide. The crafted URL points to an internal target encoded in a non-canonical form. Glide validates the URL, accepts it as public, and issues an HTTP GET request. The response can be reflected back through Glide processing or used to probe internal services. Common targets include the AWS instance metadata service at 169.254.169.254, Kubernetes API endpoints, internal admin panels, and loopback services bound to 127.0.0.1.

No exploit code is published in the advisory. Refer to the GitHub Security Advisory GHSA-pf9c-ch8r-2958 for vendor details.

Detection Methods for CVE-2026-45660

Indicators of Compromise

Outbound HTTP requests from the Statamic web server process to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) that do not correspond to known internal dependencies.
Outbound connections from the web server to 169.254.169.254, fd00:ec2::254, or other cloud metadata endpoints.
Glide proxy requests containing IP literals in octal, hexadecimal, or decimal-long form within the source URL parameter.
Web server logs showing repeated Glide requests with varying encoded host components from a single client.

Detection Strategies

Inspect access logs for Glide endpoint requests where the upstream URL parameter contains numeric IP encodings rather than hostnames or dotted-quad addresses.
Correlate Glide request timestamps with egress firewall logs to identify server-initiated connections to private address space.
Deploy egress filtering rules that explicitly block the web server from initiating connections to metadata IPs and internal management ranges, then alert on rule hits.

Monitoring Recommendations

Enable verbose logging on the Glide URL validation pipeline to capture rejected and accepted URLs for audit review.
Monitor cloud audit logs (AWS CloudTrail, Azure Activity Log, GCP Audit Logs) for unexpected API calls authenticated with instance role credentials.
Forward web server and egress proxy telemetry into a centralized analytics platform for cross-source correlation of SSRF indicators.

How to Mitigate CVE-2026-45660

Immediate Actions Required

Upgrade Statamic to version 5.73.22 or 6.18.1 immediately. These releases contain the validated IP normalization fix.
If upgrading is not immediately possible, upgrade the PHP runtime to version 8.3 or later, which eliminates the underlying parser differential.
Audit all application surfaces that forward user-supplied URLs to Glide and temporarily disable those features if neither remediation is feasible.

Patch Information

The vendor fix is included in Statamic 5.73.22 and 6.18.1. The patch normalizes IP representations before the public-IP check, ensuring the validator and the HTTP client agree on the final destination. Patch details are published in the GitHub Security Advisory GHSA-pf9c-ch8r-2958.

Workarounds

Restrict Glide to a fixed allow-list of trusted image source domains rather than accepting arbitrary user-supplied URLs.
Deploy strict egress filtering on the web server to block outbound traffic to RFC1918 networks, loopback addresses, and cloud metadata IPs.
On AWS, enforce IMDSv2 with a hop limit of 1 to prevent SSRF retrieval of instance credentials.
Place the Statamic server behind an outbound HTTP proxy that enforces destination policy and logs all upstream requests.

bash

# Example egress restriction using iptables on the Statamic host
iptables -A OUTPUT -m owner --uid-owner www-data -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 192.168.0.0/16 -j REJECT