Security Vulnerability Report: Server-Side Request Forgery (SSRF) in Webhook Configuration
- Affected Component: Squidex API (Webhook Rules Engine)
Summary
The application allows users to define “Webhooks” as actions within the Rules engine. The url parameter in the webhook configuration does not appear to validate or restrict destination IP addresses. It accepts local addresses such as 127.0.0.1, localhost
When a rule is triggered (Either manual trigger by manually calling the trigger endpoint or by a content update or any other triggers), the backend server executes an HTTP request to the user-supplied URL. Crucially, the server logs the full HTTP response in the rule execution log (lastDump field), which is accessible via the API. Which turns a “Blind” SSRF into a “Full Read” SSRF.
Details
Configuration: An attacker creates a webhook rule targeting an internal service, e.g., http://127.0.0.1:5000 or a metadata service http://169.254.169.254.
Trigger: The attacker triggers the rule (e.g., by updating schema content).
Execution: The backend server sends a request to the internal target.
Exfiltration: The attacker retrieves the rule event logs via the API. The logs contain the internal service’s response (headers and body), disclosing sensitive internal information.
PoC
- Malicious Rule Creation
Submit a POST request to create a rule targeting the server’s own loopback interface:
POST /api/content/{app-name}/{test-schema} HTTP/1.1
Content-Type: application/json
Authorization: Bearer <ACCESS_TOKEN>
{
"data": {
"sampleField": { "iv": "trigger-ssrf" }
},
"publish": true
}
- Triggering the Rule
To fire the webhook, satisfy the trigger condition (Either by manual trigger or by ContentChanged for example or any other trigger), for example, by creating a dummy content item:
POST /api/content/{app-name}/{test-schema} HTTP/1.1
Content-Type: application/json
Authorization: Bearer <ACCESS_TOKEN>
{
"data": {
"sampleField": { "iv": "trigger-ssrf" }
},
"publish": true
}
- Observing the SSRF
After the rule executes, query the event logs to view the SSRF response:
GET /api/apps/{app-name}/rules/events HTTP/1.1
Authorization: Bearer <ACCESS_TOKEN>
Response (Example):
The lastDump field in the response will contain the HTML key/data returned by the service running on 127.0.0.1:5000, confirming that the backend server successfully connected to itself.
Impact
This vulnerability enables authenticated attackers to breach network segmentation and force the server to interact with restricted internal services bound to localhost (such as Redis or Memcached) or the private network. This critically heightens the risk of data exfiltration or remote code execution, particularly in cloud environments where instance metadata services (IMDS) can be queried to compromise IAM credentials, all while leaking sensitive internal configuration details via the rule execution logs.
Precedent & Related / Similar CVEs for your reference
The industry standard is to treat SSRF in webhook configurations as a significant vulnerability, even when it requires authenticated permissions. It allows application-level users to breach network-level segmentation. Similar vulnerabilities in other CMS and platforms have been assigned high-severity CVEs:
CVE-2024-52588 (Strapi CMS): Authenticated SSRF in Strapi webhooks allowing attackers to scan internal ports via localhost URLs.
CVE-2024-13879 (WordPress Stream Plugin): Authenticated Admin SSRF in webhook functionality allowing requests to internal locations.
CVE-2024-5526 (Grafana OnCall): Authenticated SSRF in webhook logic.
Remediation Recommendations
Input Validation:
-
Validate the url parameter in webhook actions.
Deny-list private IP ranges (127.0.0.0/8, 10.0.0.0/8, etc.) and localhost.
Perform DNS resolution on the backend and verify the resolved IP is not internal before making the request.
Safe HTTP Client Configuration:
-
Configure the HTTP client used for webhooks to disable redirects or strictly validate redirect targets to prevent bypasses.
Note: I have already communicated this with the team, through the platform, find the post here "https://support.squidex.io/t/ssrf-in-authenticated-user/6084", and communicated with "Sebastian" in private messages, from an account with my email "ahmed.goma1010@gmail.com" this is me, the same person, just for clarification
ahmedgomaaa Reporter
Security Vulnerability Report: Server-Side Request Forgery (SSRF) in Webhook Configuration
Summary
The application allows users to define “Webhooks” as actions within the Rules engine. The url parameter in the webhook configuration does not appear to validate or restrict destination IP addresses. It accepts local addresses such as 127.0.0.1, localhost
When a rule is triggered (Either manual trigger by manually calling the trigger endpoint or by a content update or any other triggers), the backend server executes an HTTP request to the user-supplied URL. Crucially, the server logs the full HTTP response in the rule execution log (lastDump field), which is accessible via the API. Which turns a “Blind” SSRF into a “Full Read” SSRF.
Details
Configuration: An attacker creates a webhook rule targeting an internal service, e.g., http://127.0.0.1:5000 or a metadata service http://169.254.169.254.
Trigger: The attacker triggers the rule (e.g., by updating schema content).
Execution: The backend server sends a request to the internal target.
Exfiltration: The attacker retrieves the rule event logs via the API. The logs contain the internal service’s response (headers and body), disclosing sensitive internal information.
PoC
Submit a POST request to create a rule targeting the server’s own loopback interface:
To fire the webhook, satisfy the trigger condition (Either by manual trigger or by ContentChanged for example or any other trigger), for example, by creating a dummy content item:
After the rule executes, query the event logs to view the SSRF response:
Response (Example):
The lastDump field in the response will contain the HTML key/data returned by the service running on 127.0.0.1:5000, confirming that the backend server successfully connected to itself.
Impact
This vulnerability enables authenticated attackers to breach network segmentation and force the server to interact with restricted internal services bound to localhost (such as Redis or Memcached) or the private network. This critically heightens the risk of data exfiltration or remote code execution, particularly in cloud environments where instance metadata services (IMDS) can be queried to compromise IAM credentials, all while leaking sensitive internal configuration details via the rule execution logs.
Precedent & Related / Similar CVEs for your reference
The industry standard is to treat SSRF in webhook configurations as a significant vulnerability, even when it requires authenticated permissions. It allows application-level users to breach network-level segmentation. Similar vulnerabilities in other CMS and platforms have been assigned high-severity CVEs:
CVE-2024-52588 (Strapi CMS): Authenticated SSRF in Strapi webhooks allowing attackers to scan internal ports via localhost URLs.
CVE-2024-13879 (WordPress Stream Plugin): Authenticated Admin SSRF in webhook functionality allowing requests to internal locations.
CVE-2024-5526 (Grafana OnCall): Authenticated SSRF in webhook logic.
Remediation Recommendations
Input Validation:
Validate the url parameter in webhook actions.
Deny-list private IP ranges (127.0.0.0/8, 10.0.0.0/8, etc.) and localhost.
Perform DNS resolution on the backend and verify the resolved IP is not internal before making the request.
Safe HTTP Client Configuration:
Configure the HTTP client used for webhooks to disable redirects or strictly validate redirect targets to prevent bypasses.
Note: I have already communicated this with the team, through the platform, find the post here "https://support.squidex.io/t/ssrf-in-authenticated-user/6084", and communicated with "Sebastian" in private messages, from an account with my email "ahmed.goma1010@gmail.com" this is me, the same person, just for clarification