Fastjson Flaw Enabled RCE in Spring Boot Fat JAR Applications

Alibaba has disclosed a remote code execution flaw in Fastjson 1.2.68 through 1.2.83. An attacker can reach the vulnerable type-resolution path while AutoType remains disabled, provided the application runs as a Spring Boot executable fat JAR and parses attacker-controlled JSON.

That deployment condition limits the exposure. Fastjson2 is unaffected, as are Fastjson applications with SafeMode enabled, noneautotype builds, and deployments that do not use Spring Boot’s executable fat-JAR loader. Alibaba says it reproduced the flaw across Spring Boot 2.x through 4.x and JDK 8, 11, 17, and 21.

Public evidence leaves the scale of exploitation unknown

CVE-2026-16723 carries a 9.0 CVSS 3.1 score from Alibaba. NIST had not added its own score or analysis as of July 27. The record describes the affected range as 1.2.68 through 1.2.83 and lists deserialization of untrusted data and improper input validation as the relevant weakness categories.

ThreatBook offers the clearest public claim of attacks. Its researchers said their detection platform captured exploitation in the wild and reproduced full code execution in a Spring Boot fat-JAR deployment on JDK 8. ThreatBook is the source for that incident claim, and no independent incident record corroborates it. CISA’s contribution to the CVE record marked exploitation as none on July 23, so the public evidence does not establish the scale, targets, or success rate of the reported activity.

ThreatBook also described the affected range as every Fastjson release through 1.2.83. Alibaba’s later advisory is more specific: the vulnerable path starts at 1.2.68. Defenders should use the maintainer’s range when deciding which applications meet the stated conditions.

A user-controlled type name reaches the fat-JAR loader

The flaw sits in Fastjson’s handling of a user-controlled @type value. Alibaba says Fastjson 1.x can probe application resources while resolving that value. In a Spring Boot executable fat JAR, the application class loader understands nested archive URLs. That behavior gives the crafted type name a route to a remote JAR, after which the class can be defined inside the application process.

The chain does not require AutoType to be enabled or a compatible gadget library to be present. Specifying a target class in JSON.parseObject is also insufficient protection when the target contains fields typed as Object or Map, because a nested value can still reach the vulnerable path.

SafeMode stops the chain earlier by rejecting @type values before resource probing begins. Fastjson2 removed the resource-probing behavior from its type-resolution path and uses an allowlist-first model, according to Alibaba.

Inventory packaging as well as the dependency

Finding Fastjson 1.x is only the first check. Teams also need to identify applications that accept external JSON, run versions 1.2.68 through 1.2.83, leave SafeMode off, and ship as Spring Boot executable fat JARs.

Maven and Gradle can expose direct and transitive copies:

mvn dependency:tree -Dincludes=com.alibaba:fastjson

./gradlew dependencyInsight --dependency fastjson --configuration runtimeClasspath

For each match, inspect the deployed artifact and startup command. Reachability depends on the production package and launch path, which a dependency listing cannot establish.

Alibaba’s immediate mitigation is to enable SafeMode with the JVM option:

-Dfastjson.parser.safeMode=true

Applications can also enable SafeMode in code:

ParserConfig.getGlobalInstance().setSafeMode(true);

The same setting can go in fastjson.properties. The maintainer lists com.alibaba:fastjson:1.2.83_noneautotype as another interim option. Migration to Fastjson2 removes the affected 1.x design and is the durable fix.

Before rollout, run the application’s normal JSON integration tests because SafeMode rejects all @type use, including legitimate use. Add a benign test containing an @type field and confirm that the parser rejects it. That rejection is the verification point; a successful parse means the mitigation is absent or the test is not reaching the parser used by the exposed endpoint.

ThreatBook published perimeter signatures for @type values containing jar:http: patterns. Those indicators can support hunting, but they should not carry the mitigation plan. Encoding changes and unlogged application paths can bypass a narrow string match. Dependency inventory, packaging checks, SafeMode verification, and migration off Fastjson 1.x address the condition that makes the reported chain possible.