A critical vulnerability exists in the Squidex content management system that allows authenticated users to force the server to access internal network resources and read the responses. This flaw, known as a Server-Side Request Forgery (SSRF), can be exploited through the Webhooks feature to steal sensitive internal data, scan the internal network, and interact with other backend systems, posing a significant risk of data exfiltration and further system compromise.

The vulnerability is a "Full Read" Server-Side Request Forgery (SSRF) located in the Webhooks functionality of the Squidex Rules engine. An authenticated user with permissions to create or edit rules can configure a webhook to point to an internal network address, such as 127.0.0.1 or a cloud metadata service endpoint. The application fails to validate the user-supplied URL, allowing requests to any internal or local destination. When the rule is triggered, the Squidex server sends an HTTP request to the specified internal URL. Crucially, the server then logs the complete HTTP response from the internal service into the lastDump field of the rule execution log. The attacker can then access this log via the API, enabling them to read sensitive information that would otherwise be inaccessible from the internet.

This vulnerability is rated as critical severity with a CVSS score of 9.1. Exploitation could lead to severe consequences for the organization. An attacker can use this flaw to exfiltrate sensitive data from internal services, including database credentials, API keys, configuration files, and cloud infrastructure metadata. This access can also be used to perform internal network reconnaissance, mapping out internal systems and services to identify further targets for attack. The ability to read responses from internal services significantly elevates the risk, potentially leading to a full compromise of the internal network, major data breaches, reputational damage, and regulatory penalties.

Immediate Action: As no patched version is currently available, organizations must take immediate action to mitigate the risk. The primary recommendation is to monitor vendor advisories and update to a patched version of Squidex as soon as it is released. In the interim, disable the Webhooks feature within the Rules engine if it is not essential. If it must be used, strictly limit permissions for creating and editing rules to a minimum number of highly trusted administrators.

Proactive Monitoring:

• Application Logs: Review Squidex rule and webhook configurations for any URLs pointing to internal IP addresses (e.g., 127.0.0.1, localhost, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or cloud metadata endpoints (e.g., 169.254.169.254).
• Network Logs: Monitor outbound network traffic from the Squidex server(s). Investigate and alert on any connections initiated by the server to internal network segments or known metadata services.
• API Auditing: Audit API access logs for unusual activity, particularly repeated requests to endpoints that retrieve rule execution logs, which could indicate an attacker is exfiltrating data.

Compensating Controls:

• Egress Filtering: Implement strict network egress filtering rules on the host running Squidex to block it from initiating connections to internal network ranges and sensitive endpoints.
• Principle of Least Privilege: Conduct a thorough review of all user roles and permissions within Squidex. Ensure that only essential personnel have the rights to create or modify rules and webhooks.
• Web Application Firewall (WAF): Configure a WAF to inspect and potentially block webhook configurations that contain internal or restricted IP addresses, although this may be difficult to implement comprehensively.

Public Exploit Available: False

Given the critical 9.1 CVSS score and the direct risk of internal data exfiltration, this vulnerability requires immediate attention. We strongly recommend that organizations immediately implement compensating controls, focusing on restricting permissions for webhook creation and applying network-level egress filtering to the Squidex server. Proactive monitoring for indicators of compromise should be initiated immediately. Although this vulnerability is not currently on the CISA KEV list, its severity and impact make it a high-priority issue. Organizations must closely monitor vendor communications and be prepared to apply the security patch the moment it becomes available.