SURIQ
Java teams spent the last three years believing they had fastjson under control. After the 2022 deserialization bugs, the standard advice was to keep AutoType, the feature that lets a piece of JSON name its own target class, switched off. CVE-2026-16723 ignores that switch. Alibaba, which maintains the library and assigned the identifier, rates it 9.0 and says it fires under fastjson's default settings, with no AutoType turned on and no attacker-supplied gadget class sitting in the application's classpath.
The affected band runs from fastjson 1.2.68 to 1.2.83, the final release line of fastjson 1.x. That range matters. It is exactly the set of versions people upgraded to in order to get the post-2022 hardening, and the newest 1.2.x build is already inside it, so moving up within the 1.x line closes nothing.
What is actually exposed
There is one precondition, and it is common. The target has to be packaged as a Spring Boot fat-jar, the single self-contained .jar you launch with java -jar app.jar. Alibaba's advisory says the finding was reproduced on every current JDK from 8 to 21, and on Spring Boot 2.x, 3.x and 4.x, which covers most Java services shipped in the last decade.
The root cause, per the vendor advisory, is a resource-probing path. While resolving a type, the library reaches for a class name taken from attacker-controlled input and probes for it with getResourceAsStream. That is a different code path from the AutoType blocklist everyone has been guarding, which is why disabling AutoType leaves it open. Naming a fixed target class for the parse does not help either. The researcher who reported it, Kirill Firsov of FearsOff, showed the payload can hide inside Object or Map typed fields that the application expects to be free-form. A public proof-of-concept is circulating, and NSFOCUS CERT reported that it has seen exploitation activity, so treat the window as open now, not hypothetical.
| Build | Vulnerable to CVE-2026-16723 | Recommended action |
|---|---|---|
| fastjson 1.2.68 to 1.2.83 | Yes, in default configuration | Enable SafeMode now |
| fastjson 1.2.83_noneautotype | No | Drop-in replacement for 1.x |
| fastjson2 | No | Target for migration |
Turn on SafeMode today, then hunt for stray copies
There is no clean version bump inside 1.x that closes this, so pick from three real options, in order of how fast you can apply them.
Enable SafeMode. Setting -Dfastjson.parser.safeMode=true, or the equivalent property or code call, tells fastjson to refuse type-directed deserialization entirely, which removes the class-probing behavior this abuses. It is the fastest lever and the one Alibaba lists first.
Swap in the hardened build. The vendor ships a com.alibaba:fastjson:1.2.83_noneautotype artifact that bakes the same restriction in, useful when you cannot set a JVM flag across a whole fleet.
Migrate to fastjson2. The successor library is not affected. Alibaba says fastjson2 validates types against an allowlist and no longer probes for classes during type resolution, so this class of bug does not apply. It is the longer job, and the one that ends the pattern.
The harder part is knowing where fastjson even runs. It is frequently a transitive dependency pulled in by a framework or an SDK you never chose directly, so grepping your own pom.xml will miss it. Use your software bill of materials or a composition-analysis scan to list every com.alibaba:fastjson at 1.2.x anywhere in the build, including shaded copies tucked inside other jars.
Detection when you cannot patch immediately
This is not a bug you catch with a payload signature, because the malicious JSON looks like ordinary data until the type name is resolved. Watch behavior instead. The remote-class step means a Java service that suddenly makes an outbound connection to a host it has never contacted, right after handling a request, is a strong signal. So is a JVM loading a class from an unexpected source. A managed detection service correlates that kind of process and network telemetry across hosts and maps it to the relevant MITRE ATT&CK techniques, which is how you spot exploitation in the gap before every copy of the library is patched.
The Java deserialization surface keeps paying out
This is the second Java data-binding flaw worth patching this week. We covered a jackson-databind authorization bypass days ago, and Oracle's quarterly update again patched unauthenticated deserialization in Coherence and WebLogic. The through-line is old. Any library that turns untrusted bytes into typed objects is a deserialization target, and blocklist-based fixes keep getting walked around one code path at a time. fastjson2's allowlist design is the honest answer, and CVE-2026-16723 is one more reason to finish that migration rather than bolt another patch onto the 1.x line.