SURIQ
The critical fastjson flaw we flagged last week has moved from proof of concept to a live campaign. Security firms now report CVE-2026-16723 under active exploitation, aimed almost entirely at organizations in the United States, and the first thing to check is not which fastjson version you run. It is how your Java apps are packaged.
That distinction is the whole story. fastjson, the JSON library Alibaba built for the Java world, carries a remote code execution flaw rated 9.0 in versions 1.2.68 through 1.2.83. Confirmed exploitation lands against one deployment shape only: a Spring Boot service packaged as an executable fat JAR and launched with java -jar. The same library version inside a plain JAR, a generic uber-JAR, or a Tomcat or Jetty WAR is not reachable through this path. Kirill Firsov of FearsOff Cybersecurity reported the issue to Alibaba, which published its advisory on July 21, 2026.
The exploit fires only inside a Spring Boot fat JAR
The flaw lives in fastjson's type-resolution step. Hand it an @type value you control and it will try to resolve that name to a class before the AutoType allowlist has weighed in. In a fat JAR, that resolution can be aimed at a nested-JAR path, so the process ends up loading code the attacker chose. An @JSONType annotation on the class it loads is then read as a signal to trust it, and the final checks fall away.
Two consequences matter for a defender. It works under fastjson's stock configuration. AutoType is off by default and the attacker needs no separate gadget class on the classpath, so the hardened-by-default assumption does not hold. Pinning your input to a fixed target class does not save you either, because the payload can ride inside a field typed as Object or Map. That is why the packaging, not just the version number in your dependency tree, is the risk signal here.
| Deployment | Exposure to CVE-2026-16723 |
|---|---|
| Spring Boot executable fat JAR (java -jar), fastjson 1.2.68 to 1.2.83 | Exploitable, confirmed exploited in the wild |
| Plain non-fat JAR or generic uber-JAR, same fastjson | Not exploitable through this path |
| Tomcat or Jetty WAR, same fastjson | Not exploitable through this path |
| fastjson 1.2.60 or earlier | Not affected |
| fastjson2, any deployment | Not affected |
There is no patch coming for fastjson 1.x
This is the part the recaps understate. As of late July, Alibaba had not shipped a fixed 1.x release, and the 1.x line no longer gets active upkeep. Version 1.2.83 is the end of the road. Treat this as an end-of-life vulnerability: the vendor exit you normally wait for does not exist here, so "patch and move on" is not an option.
The advisory's interim control is SafeMode, set with the JVM option -Dfastjson.parser.safeMode=true, which turns off the @type handling the exploit rides. It ships off by default, it changes how your app deserializes JSON so it needs compatibility testing, and at least one report cautions it may not neutralize every variant. Alibaba also offers a 1.2.83_noneautotype build as a stopgap. Read all of these as a tourniquet on an unmaintained library, not a fix. The durable answer is moving to fastjson2, whose type handling was redesigned to start from an allowlist and never probes for classes named by the caller. The same trap has bitten the other big Java JSON parser too, as the Jackson allowlist bypass showed earlier this year.
How to tell if you were hit before you migrate
Migrating closes the door. It does not tell you whether someone already walked through it in the window since July 21, and that is the question worth answering now. The request itself is a weak signal. Attacks arrive as ordinary-looking JSON POST bodies, and by Imperva's telemetry most of the malicious requests came from clients forging a browser user agent, with Ruby and Go tooling behind roughly a third of the rest. Blocking on user agent will not catch that.
The higher-fidelity signal is on the host. This exploit makes the application server reach outward, fetching a class resource over a nested-JAR path right after it parses JSON. An app server that suddenly opens an unexpected outbound connection, or resolves a remote class, immediately after handling a request is the behavior to hunt for, not the string in the request body. Watching for that kind of runtime deviation is the core of vulnerability detection that still works when a flaw has no patch. ThreatBook added detection for the pattern on July 22, and Imperva has logged activity across financial services, healthcare, computing, and retail, with small volumes in Singapore and Canada.
Inventory by packaging, then schedule the fastjson2 move
Start with a question your software bill of materials can answer but usually frames wrong: not "do we ship fastjson 1.2.x," but "do we ship it inside a Spring Boot executable JAR." Pull the fat-JAR services to the top of the list; a plain JAR or a WAR on Tomcat can wait behind them. For anything exposed, set SafeMode or drop in the noneautotype build today to buy time, then put the fastjson2 migration on the calendar with a real date, because no future patch will make the 1.x line safe. In Java, the JSON parser is attack surface, and the dependency you stopped thinking about is the one that gets you.