There Is No Patch for This One. Fastjson 1.x Is Being Exploited and the Library Is Dead.
- Patrick Duggan
- 11 minutes ago
- 4 min read
Most vulnerability advice ends with "apply the update." This one cannot.
CVE-2026-16723 is a remote code execution flaw in Fastjson, the widely deployed Java JSON library, rated CVSS 9.0. It affects versions 1.2.68 through 1.2.83. Public proof-of-concept material is circulating. ThreatBook and Imperva both report active exploitation, weighted toward finance and healthcare targets.
Fastjson 1.x is no longer maintained. As of July 25 there is no patched 1.x artifact in the project's GitHub tags or on Maven Central. 1.2.83 remains the latest 1.x release, and 1.2.83 is vulnerable.
So the patch does not exist. It is not late. It is not coming.
Why this one is worse than the usual Fastjson bug
Fastjson has a long deserialization history, and the institutional memory around it is "AutoType is dangerous, so we turned AutoType off." A lot of teams have been carrying that belief for years as their reason not to worry.
That belief does not protect you here. This vulnerability requires neither AutoType enabled nor gadget classes on the classpath. It works under the library's default configuration. An unauthenticated attacker sends crafted JSON to an endpoint that parses it, and gets code execution.
It is described as especially dangerous in Spring Boot fat-JAR deployments — which is to say, the single most common way Java services are shipped. If you run Spring Boot and Fastjson 1.x is anywhere in your dependency graph, assume you are exposed until you have checked.
Note where it is not: this is not in the CISA KEV catalog as of this writing, and it was not in our corpus before today. We did not have it and we are not claiming otherwise. We are covering it because "actively exploited, no patch, hits hospitals and banks" is precisely the shape a defender without a vendor contract will not hear about in time.
What to do tonight
Enable SafeMode. Now, before anything else. SafeMode disables the type-resolution behaviour the attack depends on. It is a configuration change, it takes effect at startup, and it does not require a library upgrade — which matters enormously when no upgrade exists. Do this first and do it in every service, not just the internet-facing ones.
Then find out where Fastjson actually is. The dangerous instances are not the ones in your own build file. They are the transitive ones — a framework, an internal shared library, a vendor SDK, an old service nobody has redeployed in two years. Resolve your full dependency tree and grep it for fastjson. Fat-JARs make this worse because the library is baked inside the artifact, so a scan of declared dependencies can miss it entirely while the packaged JAR contains it.
Plan migration to Fastjson 2.x. 2.x is a different, maintained codebase. It is not a version bump — the API differs and it needs real testing. Start it now anyway, because SafeMode is a control on an abandoned library and every month you stay on 1.x you are betting nobody finds the next bypass in dead code.
If you cannot do any of the above quickly, put a control in front of it: a WAF rule on JSON request bodies to the affected endpoints, or network restrictions so untrusted callers cannot reach the parser at all. Imperva has published detection for their customers. This is a stopgap and should be treated as one.
The part that should make you angry
An abandoned library with a 9.0 under active exploitation and no possible patch is not a Fastjson problem. It is a structural one.
Fastjson 1.x sits in production at organizations that have no idea it is there, put there by a framework choice made years ago by someone who has since left. The maintainers have moved to 2.x, which is a reasonable thing for volunteers to do. Nobody owes anybody a backport. And the outcome is that hospitals and banks are running an unpatchable 9.0 today because the economics of open-source maintenance and the economics of enterprise Java deployment have never once been aligned.
This is the same shape as every end-of-life reckoning we have covered this year. The vulnerability is not the interesting part. The interesting part is that the fix requires an organization to find something it does not know it has, inside an artifact it cannot easily inspect, and replace it with a library that has a different API — and to do that faster than an attacker with a working PoC.
We are 95 percent confident this one lands in CISA KEV within weeks given confirmed exploitation, which will start a compliance clock for federal agencies on a bug with no patch to apply. Watch what the mitigation guidance says when that happens; "enable SafeMode and migrate" is a very different instruction from "update to version X," and the KEV process is not really built for the former.
Credit to ThreatBook and Imperva for the exploitation reporting.
Free IP, domain, hash, and malicious-package blocklists at analytics.dugganusa.com. If you want the KEV cross-reference for your own stack, the feed is there and it costs nothing.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.