Squidex Webhook Configuration Server-Side Request Forgery Vulnerability

Vulnerability

A server-side request forgery (SSRF) vulnerability has been identified in Squidex versions through 7.21.0. The issue arises in the webhook configuration within the Rules engine, where the url parameter lacks proper validation or restrictions on destination IP addresses. This oversight allows the inclusion of local addresses such as 127.0.0.1 or localhost. When a rule is triggered, the backend server executes an HTTP request to the user-supplied URL. The server then logs the full HTTP response in the rule execution log, accessible via the API. This transforms a 'Blind' SSRF into a 'Full Read' SSRF, enabling authenticated attackers to access sensitive internal information.

Impact

Exploitation of this vulnerability allows authenticated attackers to bypass network segmentation, causing the server to interact with restricted internal services on localhost or the private network. This significantly increases the risk of data exfiltration or remote code execution, especially in cloud environments where instance metadata services can be queried to compromise IAM credentials, all while leaking sensitive internal configuration details through the rule execution logs.

Reproduction

To reproduce this vulnerability, create a webhook rule that targets an internal service, such as one running on the loopback interface. After the rule is created, trigger it by updating content or manually calling the trigger endpoint. Once the rule has executed, the internal service's response can be retrieved from the rule event logs via the API, confirming that the SSRF vulnerability has been exploited.

Remediation

Squidex should implement input validation for the url parameter in webhook actions, denying private IP ranges and localhost. Additionally, the HTTP client used for webhooks should be configured to disable redirects or strictly validate redirect targets.

Added: Jan 27, 2026, 9:19 PM
Updated: Jan 27, 2026, 9:19 PM

Vulnerability Rating

Custom Algorithm
spread
1.9
impact
3.1
exploitability
5.5
remediation
0.0
relevance
2.4
threat
6.4
urgency
2.9
incentive
0.0

Our algorithm analyzes dozens of metrics to generate these 8 key vulnerability categories, which are then combined to calculate the overall risk score.