Squidex SSRF CVE-2026-41172: 72-Hour Plan for Operations Teams After the April 22 Patch

News · Incident Response · As of: 23.04.2026

6 Min. reading time

Squidex publicly disclosed the SSRF vulnerability CVE-2026-41172 on April 22, 2026. CVSS 7.3, patched in version 7.23.0. An authenticated editor with asset upload permission can force the Squidex server to fetch arbitrary internal URLs and store the response as an asset. For security operations, this means: within the next 72 hours, three components should be in place. The patch alone closes the vulnerability. The structural weaknesses in egress and WAF configuration remain unaddressed if operations teams don’t address them now.

Key Takeaways

CVE-2026-41172 is an SSRF vulnerability in Squidex before version 7.23.0, disclosed on April 22, 2026, CVSS 7.3.
Patch is available. Operations teams additionally need egress allowlist, IMDS lockdown, and WAF profile review, otherwise the next similar bug will hit just as hard.
72-hour plan: Inventory Squidex instances. Implement egress rules. Enforce IMDSv2. Sharpen WAF rule set against SSRF patterns.
Editor permissions are often historically broad. An asset upload review is part of the cleanup efforts.

Why This SSRF Vulnerability Must Not Disappear from the CVE List

SSRF with CVSS 7.3 appears manageable in the patch bulletin. A quick update to Squidex 7.23.0, checkmark, back to business. This exact reaction is the risk in 2026. Headless CMS installations have increased significantly over the past three years, are often positioned centrally within the architecture, and in many asset inventories are not classified as security-critical components. An SSRF vulnerability in such an installation means that an authenticated editor with asset upload permissions gains access to internal endpoints and cloud metadata within their scope. Without an egress allowlist and without a WAF profile, the leap from CVE to abused cloud role is short.

What is SSRF? Server-Side Request Forgery is a vulnerability where a server is made to fetch URLs on behalf of an attacker. The attacker doesn’t need direct access to internal networks. They use the vulnerable server as a proxy. This exact leverage is now active in Squidex: The asset upload endpoint fetches the specified URL, persists the response, and serves it through the normal asset interface.

Operations teams typically discover the vulnerability through two channels. First, through vulnerability scans that detect CVE-2026-41172 within the first 24 hours after publication. Second, through internal asset inventories, provided Squidex is properly inventoried there. Both methods indicate the vulnerability. Both say little about actual exposure. The interesting question isn’t whether a Squidex server exists, but what it can accomplish when compromised.

The 72-Hour Plan for Operations Teams

Anyone on shift on April 23, 2026 should consider the following steps as a sequence, not as a wishlist. The first 24 hours are for inventory plus patching. The second 24 hours are for egress hardening and IMDS lockdown. The final 24 hours are for WAF profile and permission review.

72-Hour Plan CVE-2026-41172

Hour 0 to 24

Inventory Squidex instances. Patch to 7.23.0. Those who don’t manage it within 24 hours should immediately switch to the hardening path.

Hour 24 to 48

Container-level egress allowlist. Enforce IMDSv2, set hop limit to 1. Tighten network policies.

Hour 48 to 72

Sharpen WAF profile for SSRF patterns. Enable logging of blocked URLs. Review asset upload permissions in the Squidex frontend.

The inventory in the first hours is more straightforward than it sounds if an asset inventory exists. In environments without clean inventory, a targeted scan of typical Squidex paths plus default ports is worthwhile. The standard response from the asset endpoint provides enough signal for quick identification. Those who obtain Squidex through a platform provider should check the deployed versions there.

The patch to 7.23.0 is standard procedure. Those who cannot patch for the next 14 days due to freeze windows, change boards, or dependent frontends should immediately activate the hardening steps. The egress allowlist is the most important measure here. Squidex only needs to reach a small number of external hosts, typically CDN targets plus defined asset sources. An egress rule that blocks everything else eliminates most SSRF attack variants against internal IP ranges.

Egress Rules and WAF Profile as a Second Line of Defense

The assumption that applications in container environments will only do what they’re supposed to do will no longer hold up in any SSRF discussion by 2026. Default configurations in Kubernetes allow unrestricted egress. Container platforms outside of Kubernetes behave similarly. A Squidex pod without a network policy can reach any internal endpoint in the same cluster, can query the cloud metadata endpoint, and can contact external hosts that would never be necessary for the actual use case.

A sensible egress allowlist covers three areas. First, the external asset sources that editorial teams actually use. These are typically stock photo providers, own CDN buckets, and occasionally partner APIs. Second, the internal services that Squidex needs for identity, logging, and monitoring. Third, explicit blocks against 169.254.169.254 (AWS IMDS), 169.254.170.2 (ECS Task Metadata), the GCP metadata endpoint, and comparable addresses in Azure. Those who completely block the 169.254.0.0/16 range at the pod level have covered the greatest leverage with minimal effort.

Enforcing IMDSv2 is the second step for AWS environments. The hop-limit parameter should be set to 1. This way, a compromised pod cannot reach the metadata endpoint via normal routing. Comparable mechanisms exist in Azure with the Instance Metadata Service, which requires a header check, and in Google Cloud with the Metadata Concealment feature. Those working in multi-cloud environments check the configuration for each cloud provider.

Pros and Cons of Egress Allowlist in Squidex Pod

Pro Structural defense against SSRF, independent of specific CVEs. Also works with the next headless CMS vulnerability.	Con Initial setup takes time. Editorial teams report issues with new asset sources not yet in the allowlist.
Pro Compliance argument for auditors: active egress filter instead of default configuration.	Con Maintenance effort: every new legitimate URL must go through a change process.
Pro Logging of blocked URLs provides a reliable signal for abuse or misconfiguration.	Con Incorrectly configured allowlist can break legitimate editorial workflows, so staging test beforehand.

The WAF profile is the third building block. A WAF that only knows generic OWASP rules blocks SSRF unreliably. The specific patterns are clear: requests to internal IP ranges, requests to metadata endpoints, requests with unusual URL schemes like file:// or gopher://. Those operating Squidex behind a WAF should enable a rule set that recognizes these patterns. Cloudflare, AWS WAF, and comparable providers have managed rule sets that can be specifically applied to SSRF. Logging the blocked requests is just as important as blocking them: It’s the detection layer that shows whether someone is abusing the asset upload.

Permission Review and What Remains After 72 Hours

Squidex comes with a role-based permission model. Asset upload permission is a privilege that is active in the standard configuration for editor roles. In mature installations, these roles are often historically broad. A permission review is the fourth component of the 72-hour plan and the step that operates at the application level.

The question is simple: Who has asset upload permission and who actually needs it? External agency accounts, intern accounts, archived editor roles, service accounts with historical rights. Any account that currently can upload assets but hasn’t been actively used in the last 90 days is a candidate for reduction. Squidex admins can evaluate the last activity per account. The audit log provides the data basis.

What remains after 72 hours is more than just a patched Squidex. Those who execute the plan cleanly have an egress allowlist in the Squidex pod, IMDSv2 with a low hop limit, a WAF rule set that detects SSRF patterns, and a reduced list of editor accounts with asset upload rights. The next comparable CVE in a headless CMS, a wiki system, or a marketing cloud will encounter a prepared environment. This is the real gain beyond CVE-2026-41172.

The most common pitfall in such 72-hour plans is the assumption that everything is done after patching. Those who read the WAF rule’s audit log in the following week, who check whether in the first days after the CVE became known there were suspicious requests to internal IP ranges, gain two insights. First, whether their own Squidex instance was actively targeted. Second, how well the WAF detection works. Both data points belong in the post-mortem document for CVE-2026-41172.

Frequently Asked Questions

Is a patch for Squidex 7.23.0 sufficient?

The patch cleanly closes CVE-2026-41172. However, operations teams gain little if they leave structural vulnerabilities in the egress configuration and WAF profile open. With the next comparable CVE in another headless CMS, the environment will be in the same position again. The patch is mandatory, but hardening is also worthwhile.

How quickly should the egress allowlist be implemented?

Realistically within 24 to 48 hours, if Squidex is running in containers and network policies are already established in the cluster. In environments without network policies, clean implementation takes longer, but at least the hard block of the 169.254.0.0/16 range is worthwhile as an immediate measure.

Which WAF rulesets reliably detect SSRF?

AWS WAF provides a foundation with the Managed Rule Set for CommonRuleSet, which partially covers SSRF patterns. Cloudflare has a dedicated SSRF ruleset in the OWASP set. Users of a self-operated WAF should specifically add rules for internal IP ranges and metadata endpoints, rather than relying solely on the OWASP defaults.

How do I identify unused asset upload accounts in Squidex?

The Squidex audit log contains activities per user. An evaluation over the last 90 days shows which accounts have actually used the asset upload permission. Accounts without upload activity are the first candidates for permission reduction.