CRITICAL: Fastjson 1.x CVE-2026-16723 Exploited in the Wild With No Patch

There is a special kind of irony reserved for people who patch diligently. Back in 2020, when Fastjson was shipping a new AutoType bypass roughly every other week, the advice from every security team on the planet was to get onto a current 1.2.x build and stop worrying about it. Six years later, the versions that came out of that cleanup, 1.2.68 through 1.2.83, are precisely the ones being exploited right now under CVE-2026-16723. Anything on 1.2.60 or older is not affected. The shops that upgraded are the ones on fire, and the shops that ignored the whole saga are sitting comfortably. Nobody said this job was fair.

Alibaba disclosed the flaw on July 21, 2026. NVD published it two days later with a CVSS v3.1 base score of 9.0 and the vector AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H. The attack complexity rating of high is doing a lot of polite work there, because the preconditions are common enough that ThreatBook and Imperva both started watching people throw exploits at real production systems within about twenty four hours of disclosure. There is still no patched Fastjson 1.x release. Version 1.2.83 remains the latest 1.x artifact in Maven Central. You are going to fix this with configuration and dependency surgery, not with a version bump.

Why the default configuration is enough

The genuinely nasty part of CVE-2026-16723 is what it does not require. It does not require AutoType to be enabled. It does not require a gadget class sitting on your classpath. It does not require authentication. It works against stock defaults, which is a sentence that should make anyone who has spent time with Java deserialization bugs sit up straight.

When Fastjson parses untrusted JSON containing an @type directive, the type resolution path ends up calling getResourceAsStream() on a name the attacker controls. In an ordinary deployment that goes nowhere interesting. In a Spring Boot executable fat JAR, the nested archive layout means that resource lookup can be steered into fetching bytecode from nested JAR paths, including jar:http and jar:file URL patterns, which is how an attacker gets a class of their choosing loaded and executed. The whole thing is catalogued as CWE-502 deserialization of untrusted data with CWE-20 improper input validation alongside it, and the scope change flag in the CVSS vector reflects that code execution lands with the privileges of the Java process rather than staying politely inside the parser.

The full precondition list is short. You need Fastjson somewhere between 1.2.68 and 1.2.83 inclusive, you need SafeMode left at its disabled default, you need the application deployed as a Spring Boot executable fat JAR launched with java and the jar flag, and you need a network reachable path that hands attacker controlled JSON to the parser. Researchers verified the chain across Spring Boot 2.x, 3.x and 4.x on JDK 8, 11, 17 and 21, so there is no version of the modern Java stack that quietly saves you.

Here is the part that catches careful developers. Specifying a target class, the pattern where you call JSON.parseObject(body, SomeDto.class) because you assumed that constrains what can be instantiated, provides no protection at all. Attackers simply nest the payload inside a field typed as Object or Map, and the parser obliges. If you were planning to grep for JSON.parse calls and consider the typed variants safe, do not.

Who is actually exposed

Deployments that are not vulnerable include plain non-fat JARs, generic uber JARs that flatten dependencies rather than nesting them, and traditional WAR deployments running under Tomcat or Jetty. Fastjson2 is architecturally immune, because it does not call getResourceAsStream on user controlled names, resolves types against an allowlist first, and keeps AutoType off by default.

The uncomfortable question is not whether you run Fastjson. It is whether you know you run Fastjson. This library shows up as a transitive dependency in an enormous amount of Java tooling, particularly anything with Chinese upstream origins or anything old enough to predate the Jackson consensus. Plenty of teams currently believing they have no exposure are shipping a fat JAR with com.alibaba:fastjson 1.2.83 buried four levels down a dependency tree they have never actually read. Go look at your software bill of materials rather than your direct dependency declarations.

What exploitation looks like in the wild

ThreatBook confirmed exploitation activity on July 22, one day after disclosure, and Imperva reported blocking attempts across financial services, healthcare, computing, retail and general business targets. Activity is overwhelmingly aimed at United States organizations right now, with a scattering in Singapore and Canada, which almost certainly means the geography broadens rather than that the rest of the world got lucky.

The tooling profile is telling. The majority of the traffic comes from clients impersonating browsers, with purpose built scanners written in Ruby and Go making up roughly thirty percent of observed attempts. That is the signature of opportunistic mass scanning rather than targeted intrusion, which means exposure is being inventoried at internet scale while you read this.

One honest caveat is worth stating plainly. Neither vendor has published a confirmed successful compromise, only observed exploitation attempts, and as of July 25 the CVE had not been added to the CISA Known Exploited Vulnerabilities catalog. That is a meaningful distinction and you should not let anyone sell you a panic on it. It is also not much comfort, because the gap between confirmed attempts against a working unauthenticated RCE and confirmed victims is usually measured in the time it takes someone to write an incident report.

What to do about it

The immediate fix is SafeMode, and it costs you a restart rather than a release. Set it with the JVM flag -Dfastjson.parser.safeMode=true, or programmatically through ParserConfig.getGlobalInstance().setSafeMode(true), or through a fastjson.properties entry, whichever fits how your applications are configured. SafeMode disables @type handling entirely, which is exactly what you want, with the caveat that if any part of your application legitimately relies on polymorphic type information in JSON, that functionality breaks. Test it in staging first rather than discovering it at three in the morning.

The alternative immediate control is swapping the artifact for the restricted build published as com.alibaba:fastjson:1.2.83_noneautotype, which is useful for applications where you cannot safely flip a global parser setting. Either way, treat both of these as a tourniquet rather than a cure. The actual remediation is migrating to Fastjson2, which eliminates the root cause architecturally instead of configuring around it, and Alibaba is very clearly signalling that no fixed 1.x release is coming.

For detection, put a WAF rule in front of anything that accepts JSON and look for @type values in request bodies alongside jar:http and jar:file URL patterns, which is essentially what the commercial signatures are matching on. Watch for outbound HTTP from application servers to destinations that have no business receiving traffic from a backend, because the exploit fetches remote bytecode and that egress is the loudest part of the chain. On the host, alert when a Java process spawns shell children, and audit your JVM start commands for anything launched as a fat JAR without the SafeMode flag. Then run a dependency scan across every build pipeline you own for com.alibaba:fastjson in the affected range, including transitive pulls, and keep the results, because you will be asked this question again.

For MSPs, this one sells itself to any client running custom Java applications, because the honest answer to whether they know what is in their dependency tree is almost always no. Lead with a software composition analysis engagement scoped to their production JARs, and let the inevitable pile of unknown transitive dependencies justify ongoing SBOM management and vulnerability monitoring as recurring revenue rather than a one time project.

The broader lesson here is one the industry keeps refusing to learn. Deserialization of untrusted data has been a top tier Java vulnerability class for over a decade, and we are still shipping parsers that will happily resolve a class name handed to them by a stranger on the internet. Fastjson2 fixed the design rather than the symptom, which is why it is not on this list. Everything still on 1.x is running on a clock that Alibaba has now explicitly declined to reset.