JSPWiki versions prior to 2.12.4 are vulnerable to JSON Hijacking, a vulnerability class that refuses to die not because individual developers make mistakes, but because the protection mechanisms live across three separate layers that no framework enforces as a coherent unit. The fix in 2.12.4 is almost certainly straightforward — likely enforcing application/json Content-Type headers, adding SameSite cookie attributes, or inserting CSRF tokens into API calls — but the straightforwardness of the fix is precisely what makes this CVE worth treating seriously.
The EPSS score of 0.0019 is misleading comfort. This vulnerability class has a documented history of spiking in exploitation only after tooling catches up — when scanners add the pattern to their default rulesets, attackers build reusable payloads, and the security community remembers to look. The gap between EPSS (low) and CVSS (high) reflects degraded attention to this class more than genuine exploit difficulty. The moment JSON Hijacking was declared "solved" circa 2015-2018, audit attention got deprecated. Code written during that window carries what amounts to temporal debt: maintainers assumed browser hardening had protected them, but specific implementation patterns never received validation.
Here's what matters now: JSPWiki is niche, but JSON Hijacking is a pattern. Check your own applications for JSON endpoints that return data without application/json Content-Type, that rely on SameSite cookies without verifying preloading paths (like <link rel="prefetch">), or that serve APIs without CSRF tokens. The JSPWiki CVE is a reconnaissance gift — it tells attackers exactly where to look for the same pattern in other applications. If your codebase predates 2018 and contains REST APIs, treat this CVE as a prompt to audit your JSON handling, not as a reason to patch one wiki engine and move on.
The real question isn't whether JSPWiki was vulnerable. It's how many other applications share the same architectural assumption — that JSON responses are inherently safe — and have never been audited because the vulnerability class was marked "historical."