CVE-2026-41171: Squidex CMS SSRF Vulnerability

CVE-2026-41171 Overview

CVE-2026-41171 is a Server-Side Request Forgery (SSRF) vulnerability affecting Squidex, an open source headless content management system and content management hub. The vulnerability exists due to missing SSRF protection on the Jint HTTP client used by scripting engine functions (getJSON, request, etc.) in versions prior to 7.23.0.

An authenticated user with low privileges (e.g., schema editing permissions) can force the server to make arbitrary outbound HTTP requests to attacker-controlled or internal endpoints. This allows access to internal services and cloud metadata endpoints (e.g., IMDS), potentially leading to credential exposure and lateral movement.

Critical Impact

Authenticated attackers can exploit this SSRF vulnerability to access internal services, cloud metadata endpoints, and potentially obtain cloud credentials, enabling credential exposure and lateral movement within the infrastructure.

Affected Products

• Squidex versions prior to 7.23.0
• Squidex instances with scripting engine features enabled
• Cloud-hosted Squidex deployments with accessible IMDS endpoints

Discovery Timeline

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

Technical Details for CVE-2026-41171

Vulnerability Analysis

This vulnerability is classified under CWE-918 (Server-Side Request Forgery). The root cause lies in the Squidex scripting engine's HTTP client functionality, which lacks proper SSRF protections. The Jint JavaScript engine used by Squidex provides functions such as getJSON and request that allow scripts to make HTTP requests. Without adequate validation of target URLs, these functions can be abused to make requests to arbitrary endpoints.

The attack requires authentication but only minimal privileges—users with schema editing permissions can exploit this vulnerability. This low privilege requirement significantly increases the attack surface, as many CMS users may have such permissions for legitimate content management purposes.

Root Cause

The vulnerability stems from insufficient URL validation in the Jint HTTP client integration within Squidex's scripting engine. The scripting functions (getJSON, request, etc.) do not implement proper safeguards to prevent requests to internal network addresses, localhost, or cloud metadata services. This allows attackers to bypass network boundaries and access resources that should not be reachable from the application layer.

Attack Vector

The attack is network-based and requires low privileges to execute. An authenticated attacker can craft malicious scripts that leverage the getJSON or request functions to target internal endpoints. Common attack scenarios include:

Attackers can use the scripting engine to request internal service endpoints on private networks (e.g., http://192.168.x.x/admin), cloud provider metadata endpoints such as AWS IMDS at http://169.254.169.254/latest/meta-data/, or attacker-controlled servers to exfiltrate data. By accessing cloud metadata services, attackers can potentially retrieve temporary security credentials, IAM role information, and other sensitive cloud configuration details.

For detailed technical information about this vulnerability and the specific fix, refer to the GitHub Security Advisory GHSA-4m22-gvqm-jv97.

Detection Methods for CVE-2026-41171

Indicators of Compromise

• Unusual outbound HTTP requests from Squidex server processes to internal IP ranges (e.g., 10.x.x.x, 172.16.x.x, 192.168.x.x)
• HTTP requests to cloud metadata endpoints such as 169.254.169.254 originating from the Squidex application
• Script execution logs containing URLs pointing to internal or suspicious external endpoints
• Unexpected network connections from the CMS server to attacker-controlled infrastructure

Detection Strategies

• Monitor Squidex server network traffic for outbound connections to private IP ranges and cloud metadata endpoints
• Implement logging for all scripting engine HTTP requests, including target URLs and response codes
• Deploy web application firewall (WAF) rules to detect SSRF patterns in application traffic
• Review Squidex audit logs for suspicious script creation or modification by low-privileged users

Monitoring Recommendations

• Configure network monitoring tools to alert on HTTP requests from Squidex servers to IMDS endpoints (169.254.169.254)
• Enable detailed request logging in Squidex to track all getJSON and request function calls
• Set up alerts for outbound connections from CMS servers to RFC1918 private address ranges
• Monitor for unusual data exfiltration patterns from the Squidex application tier

How to Mitigate CVE-2026-41171

Immediate Actions Required

• Upgrade Squidex to version 7.23.0 or later immediately
• Review and audit all existing scripts for potentially malicious URL targets
• Implement network-level egress filtering to block requests to internal networks and cloud metadata endpoints
• Audit user permissions and restrict schema editing access to trusted personnel only

Patch Information

Squidex version 7.23.0 contains the fix for this vulnerability. The patch implements proper SSRF protections on the Jint HTTP client used by scripting engine functions.

The fix can be reviewed in the GitHub Commit Changes. Organizations should upgrade to version 7.23.0 or later as the primary remediation strategy.

Workarounds

• Disable or restrict access to the scripting engine functionality until the patch can be applied
• Implement network-level controls to block outbound requests to private IP ranges and cloud metadata endpoints from the Squidex server
• Deploy a reverse proxy with URL filtering capabilities to intercept and validate outbound requests from the scripting engine
• Revoke schema editing permissions from non-essential users until the vulnerability is patched

# Network egress filtering example (iptables)
# Block requests to AWS IMDS endpoint
iptables -A OUTPUT -d 169.254.169.254 -j DROP

# Block requests to common private networks
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP