CVE-2026-41172: Squidex CMS SSRF Vulnerability

CVE-2026-41172 Overview

CVE-2026-41172 is a Server-Side Request Forgery (SSRF) vulnerability affecting Squidex, an open source headless content management system and content management hub. Prior to version 7.23.0, this vulnerability allows an authenticated user with asset upload permission to force the server to fetch arbitrary URLs, including localhost and private network targets, and persist the response as an asset within the system.

Critical Impact
Authenticated attackers can leverage this SSRF flaw to access internal services, exfiltrate sensitive data from private networks, and potentially pivot to further attacks against infrastructure not intended to be publicly accessible.

Affected Products

Squidex Headless CMS versions prior to 7.23.0
Squidex Content Management Hub (all versions before security patch)
Self-hosted Squidex deployments with asset upload functionality enabled

Discovery Timeline

2026-04-22 - CVE-2026-41172 published to NVD
2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-41172

Vulnerability Analysis

This SSRF vulnerability (CWE-918) exists in the asset upload functionality of Squidex CMS. The vulnerability stems from insufficient validation of user-supplied URLs during the asset import process. When a user with asset upload permissions provides a URL for the system to fetch, the server-side code does not adequately restrict which destinations can be accessed.

The exploitation requires low privileges (asset upload permission), can be performed remotely over the network, and requires no user interaction. An attacker can successfully exploit this vulnerability to access high-value targets including internal metadata services, localhost-bound administration interfaces, and other private network resources that should not be accessible from the application layer.

Root Cause

The root cause is improper URL validation in the asset fetching mechanism. The application fails to implement adequate server-side URL filtering, allowing requests to internal IP addresses (such as 127.0.0.1, 10.x.x.x, 192.168.x.x, 169.254.169.254 for cloud metadata), and other restricted network ranges. This lack of egress filtering enables attackers to abuse the server as a proxy to reach otherwise inaccessible resources.

Attack Vector

The attack is network-based and requires authentication with asset upload privileges. An attacker can craft a malicious request containing a URL pointing to internal resources. The Squidex server then fetches the content from that URL and stores it as an asset, effectively allowing the attacker to read the response. This can be used to:

Access cloud provider metadata endpoints (AWS, GCP, Azure) to retrieve credentials
Scan internal network services and ports
Interact with internal APIs and administration interfaces
Bypass network segmentation and firewall controls

The vulnerability mechanism involves the server making HTTP requests on behalf of the user without proper destination validation. When a user submits a URL for asset import, the application fetches the resource server-side, which allows access to internal network resources that the client cannot directly reach. See the GitHub Security Advisory GHSA-x7cq-4f4c-8qcv for additional technical details.

Detection Methods for CVE-2026-41172

Indicators of Compromise

Unusual outbound HTTP requests from the Squidex server to internal IP ranges (127.0.0.1, 10.x.x.x, 172.16.x.x, 192.168.x.x)
Asset upload requests containing URLs targeting cloud metadata endpoints (e.g., 169.254.169.254)
Unexpected assets stored in the system containing configuration data, credentials, or internal service responses
Network logs showing the Squidex server initiating connections to services it should not normally access

Detection Strategies

Monitor web application logs for asset upload requests containing suspicious URL patterns targeting private IP ranges or localhost
Implement network-level monitoring to detect outbound connections from the Squidex server to internal services or cloud metadata endpoints
Review stored assets for anomalous content that appears to be server responses, configuration files, or credential data
Deploy web application firewall (WAF) rules to detect and block SSRF attack patterns in request parameters

Monitoring Recommendations

Enable verbose logging for all asset upload operations including the source URLs requested
Configure network segmentation alerts for unexpected traffic patterns from web application servers
Implement egress filtering and log all outbound connections from the Squidex server for anomaly detection
Set up alerts for any access to cloud metadata service IPs from application-tier hosts

How to Mitigate CVE-2026-41172

Immediate Actions Required

Upgrade Squidex to version 7.23.0 or later immediately
Review existing assets for any suspicious content that may indicate prior exploitation
Audit user accounts with asset upload permissions and restrict access where not strictly necessary
Implement network-level egress filtering to block requests to internal IP ranges from the web application server

Patch Information

The vulnerability has been addressed in Squidex version 7.23.0. The fix is available in GitHub commit b81d75e1d9c1a8e30993c2ee59b350002b9aeda4. Organizations should upgrade to this version or later to remediate the vulnerability. Additional details can be found in the GitHub Security Advisory GHSA-x7cq-4f4c-8qcv.

Workarounds

Restrict asset upload permissions to only trusted administrators until patching is complete
Deploy a reverse proxy or WAF to filter requests containing private IP addresses or suspicious URL patterns
Implement network segmentation to prevent the Squidex server from accessing internal services directly
Block outbound connections from the application server to cloud metadata endpoints (169.254.169.254)

bash

# Example: Block outbound requests to internal ranges using iptables
iptables -A OUTPUT -d 127.0.0.0/8 -m owner --uid-owner www-data -j DROP
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
iptables -A OUTPUT -d 169.254.169.254 -m owner --uid-owner www-data -j DROP