CVE-2026-73635

The EPSS score of 0.0019 versus the CVSS 7.5 tells you something important about where this vulnerability lives: it's not a memory safety flaw or injection bug—it's a design assumption that should never have been made. Apache Struts built its localized-text lookup system on the assumption that incoming request locales would be bounded and controlled. When developers fail to configure a fixed locale, the framework trusts the client completely. That's not a classic vulnerability; it's a fundamental failure of defensive architecture that has existed since 2.0.0. The massive version range (2.0.0 through 7.2.1) is the most analytically significant detail. This isn't a regression introduced in a recent refactor—this architectural weakness persisted across 15+ years of releases. The community either didn't recognize the resource exhaustion risk or accepted it as acceptable behavior. Compare this to injection vulnerabilities where defense-in-depth layers (parameterization, encoding, size limits) get added even when primary defenses exist. Here, no such layered controls emerged. The practical problem is the insecure default. Struts shipped with locale trust as the default behavior, meaning every new application started vulnerable. The secure configuration—setting a fixed locale—requires active developer intervention. For applications that never intended to support dynamic locale switching, this was never a conscious decision; it was just what the framework did out of the box. The EPSS score likely reflects the operational difficulty of weaponizing this at scale (you need sustained, high-volume requests with distinct locale values), but it says nothing about the population of silently vulnerable deployments that persist because they never triggered alerts. There's also a blast radius dimension that the CVSS score undersells. One unauthenticated remote client can exhaust the heap and take down the entire JVM instance—every user on that server goes dark simultaneously. That's a 1-to-N collateral damage ratio that elevates the operational severity beyond what a 7.5 suggests. The mitigation is configuration-based (setting a fixed locale), not a code-level fix. For applications already using fixed locale as a best practice, the operational risk is minimal. But for applications that intentionally or accidentally exposed dynamic locale switching, remediation isn't just changing a config flag—it requires answering whether that behavior was ever consciously architected or just inherited from the default. That's organizational debt that CVSS will never capture.

Reviewed through automated stages and approved by a human before publication.