CVE-2026-73633 is a memory exhaustion vulnerability in Apache Struts' JSON plugin, but the headline numbers mask a configuration-gated reality that demands precise triage. The affected version range spans 2.1.8 through 7.2.1 with a CVSS 7.5, yet the actual attack surface requires a specific setup: the JSON plugin must be present AND configured to populate actions from the JSON request body. Most deployments don't meet this precondition and are never at risk — but they may have assumed otherwise based on version numbers alone.
The EPSS score of 0.00324 is notably low for a 7.5, and this gap is itself the signal. EPSG models historical exploitation, and configuration-gated flaws systematically score low because they rarely trigger in the wild. Organizations using EPSS-weighted prioritization may deprioritize this patch precisely when it matters most — for the subset of deployments that ARE in the vulnerable configuration. This is a structural blind spot in threat-intelligence-driven triage, not a reason for complacency.
The more urgent concern is a documented mitigation that doesn't work. Struts ships with a configuration parameter (struts.json.max.length) that appears to bound memory consumption during JSON parsing but fails to do so for the specific request-body population path. This isn't a silent failure — it's a deceptive affordance that likely created false confidence among developers who found and applied the documented setting. If your internal guidance or security policy points to this parameter as sufficient mitigation, it's not. The parameter exists and is documented, but it doesn't wire into the vulnerable code path.
Verify whether your deployment uses the JSON plugin at all, and whether any JSON-to-action population is configured. The plugin may be present as a transitive dependency pulled in by framework starters or base images in microservice environments — 'optional' doesn't mean absent. Once confirmed, the fix is straightforward: upgrade to Struts 6.11.0 or 7.3.0. For organizations on long-term-support tracks, note that this flaw has survived across four parallel version branches (2.x, 2.5.x, 6.x, 7.x) without prior detection — the same unchecked memory path propagated through multiple forks, each maintained by different teams. That's not a hard problem awaiting solution; it's a known control that was never correctly implemented, carrying forward on the assumption it was working.