This CVE breaks a pattern that has defined fastjson exploitation for years: it works without AutoType enabled. That single qualifier should concern you more than the CVSS 9 suggests, because the previous four or five fastjson RCEs all required AutoType — a setting many organizations explicitly disabled after years of advisories. The removal of that prerequisite dramatically expands the attack surface, yet the EPSS score sits at 0.00413. The most likely explanation is not that EPSS is broken, but that it models opportunistic scanning behavior while this vulnerability represents a supply-chain attack vector, where an attacker with access to your dependency chain exploits what they find rather than what they scan for.
The version range 1.2.68 through 1.2.83 spanning fifteen releases is a structural warning, not a disclosure quirk. Fastjson has repeatedly patched specific type-handling pathways without fixing the underlying deserialization model. Each CVE addresses a symptom; the mechanism remains. When a library produces critical-severity deserialization flaws across fifteen consecutive releases, that is a library that should be replaced, not patched in perpetuity.
In practice, exploitation is gated by parsing context. The JSON.parseObject() method carries higher risk than JSON.parse(), and exploitation chains typically require the parsed content to flow into reflective operations. However, the version range means you no longer need to fingerprint AutoType settings to identify vulnerable deployments — any fastjson in that range is suspect by default. The reconnaissance barrier has collapsed.
Check your dependency trees for fastjson 1.2.83 or earlier. If present, treat this as a library retirement decision, not a point-patch. The question is not whether this specific CVE is exploitable in your context — it is whether you are running a library that has produced five architectural failures in the same subsystem and will produce more.