Squidex is an open source headless content management system and content management hub. Versions prior to 7.23.0 have a Server-Side Request Forgery (SSRF) vulnerability due to missing SSRF protection on the `Jint` HTTP client used by scripting engine functions (`getJSON`, `request`, etc.). 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. Version 7.23.0 contains a fix.
Squidex is an open source headless content management system and content management hub. Prior to version 7.23.0, the Squidex Restore API is vulnerable to Blind Server-Side Request Forgery (SSRF). The application fails to validate the URI scheme of the user-supplied `Url` parameter, allowing the use of the `file://` protocol. This allows an authenticated administrator to force the backend server to interact with the local filesystem, which can lead to Local File Interaction (LFI) and potential disclosure of sensitive system information through side-channel analysis of internal logs. Version 7.23.0 contains a fix.
Squidex is an open source headless content management system and content management hub. Prior to version 7.23.0, an SSRF vulnerability allows a user with asset upload permission to force the server to fetch arbitrary URLs, including localhost/private network targets, and persist the response as an asset. Version 7.23.0 contains a fix.
Squidex is an open source headless content management system and content management hub. Versions of the application up to and including 7.21.0 allow 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 or 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. As of time of publication, no patched versions are available.