Fastjson CVE-2026-16723: no AutoType, no gadgets, just Spring Boot fat-JAR

TL;DR

---

CVE-2026-16723 is an RCE in Fastjson 1.2.83, the last regular release of the 1.x line.
Alibaba published the advisory on July 21, 2026, and the CVE record lists 1.2.68 through 1.2.83.
CVSS is 9.0 from Alibaba as the CNA. NVD still has no independent score as of July 26, 2026, but carries the CNA score of 9.0 Critical.

The official CVE range and the first version that shipped the offending code are not the same thing.
The CVE record marks 1.2.68–1.2.83 as affected and sets defaultStatus to unaffected for everything else. Alibaba’s wiki calls 1.2.60 and earlier unaffected, but does not explain the reasoning for 1.2.61 through 1.2.67.
GCSA’s source code analysis says the decisive resource lookup is present in 1.2.67 as well. That said, the only Fastjson version the company reproduced end to end across every JDK was 1.2.83, so for 1.2.61–1.2.67 there is neither enough evidence to call them affected nor enough to call them safe on the grounds that they sit outside the official range.

Past Fastjson issues usually came with conditions like “AutoType is on” and “there is a usable gadget on the classpath.”
This one works with AutoType disabled, as long as SafeMode is off.
Alibaba’s advisory says the same: exploitable in a stock default configuration, no classpath gadget required.

Telling whether your artifact is a Spring Boot executable fat-JAR

Alongside the library version, Alibaba lists another precondition: the app has to be started as a Spring Boot executable fat-JAR with java -jar xxx.jar.
The advisory also says Spring Boot 2.x, 3.x and 4.x were verified end to end against JDK 8, 11, 17 and 21, but it does not publish the per-combination results or a condition table by OS and embedded server.

I wrote earlier in Request smuggling vs request splitting in Spring Boot: what to check for each that the things to check in Spring Boot split into application code, the embedded Tomcat, the upstream proxy, and how the app is actually started.
Here too, whether Fastjson is in pom.xml and what form the running artifact takes are separate conditions.

Alibaba’s list of unaffected setups includes a plain non-fat JAR, a generic uber-JAR, and a WAR deployed to Tomcat or Jetty.
The condition holds when Fastjson 1.x’s type resolution path is combined with the Spring Boot fat-JAR loader.

A regular JAR starts with java -jar too, so the command line alone does not tell you whether this is a Spring Boot executable fat-JAR.
Check the manifest and BOOT-INF of the artifact you actually deployed.

unzip -p app.jar META-INF/MANIFEST.MF \
  | rg '^(Main-Class|Start-Class):'
jar tf app.jar \
  | rg '^BOOT-INF/(classes/|lib/fastjson-.*\.jar$)'

For Spring Boot 2.x through the 3.1 line, the manifest Main-Class is typically org.springframework.boot.loader.JarLauncher; for 3.2 and later, including 4.x, it is org.springframework.boot.loader.launch.JarLauncher.
If a real file like BOOT-INF/lib/fastjson-1.2.83.jar is there, you have confirmed that the regular Fastjson build is in the shipped artifact itself.

flowchart TD
    A[External JSON input] --> B[Fastjson 1.x parser]
    B --> C["Build a class resource name from @type"]
    C --> D["Resolve a URL-form resource<br/>via getResourceAsStream"]
    D --> E[Fetch class bytes from the attacker's JAR]
    E --> F["Detect @JSONType"]
    F --> G{Can the class be defined directly?}
    G -->|Succeeds on JDK 8 and similar| H[Class initialization]
    H --> K[Code execution with the Java process privileges]
    G -. Fails on JDK 9 and later .-> I[Temporary cache of the remote JAR]
    I --> J["Published chain that re-references it<br/>through /proc/self/fd/N on Linux"]
    J --> H

In the analysis by Kirill Firsov of FearsOff, Fastjson builds a class resource name from an attacker-controlled @type and reads the content with getResourceAsStream.
The launcher ClassLoader of a Spring Boot executable JAR can in some cases resolve that resource name as a URL, which reaches a JAR on the attacker’s side.
What gets loaded is an external JAR the attacker prepared; the nested JARs bundled inside the application’s own fat-JAR are not used.

When the fetched class bytes carry a @JSONType annotation, Fastjson proceeds to loadClass ahead of the usual AutoType rejection.
In FearsOff’s testing, the direct load path on JDK 8 and the behavior on JDK 9 and later diverged. JDK 9 and later reject class names containing ://, so the initial remote JAR fetch stops at SSRF (Server-Side Request Forgery, making the server issue requests to arbitrary URLs).
The RCE the company demonstrated on a modern JDK with a default Tomcat was a multi-stage path: the remote JAR that the JVM opened as a temporary file gets re-referenced from a later candidate through /proc/self/fd/N.

/proc/self/fd is Linux-specific. GCSA, who reproduced the issue independently, confirmed it with /dev/fd on macOS as well, but that is not evidence that the same path works on every OS including Windows.
On the other hand, Alibaba’s advisory does not list any OS as an unaffected condition, so being on something other than Linux is not grounds for calling yourself safe either. The published chain also requires that the Java process can reach the attacker’s HTTP service and that the environment allows a temporary JAR cache. Restricting outbound traffic is defense in depth that cuts off the fetch of the attacker’s JAR. Type resolution itself is stopped on the Fastjson side.

Pinning a DTO still leaves Object and Map fields open

Alibaba’s advisory lists JSON.parse, JSON.parseObject(String) and JSON.parseObject(String, Class) as reachable entry points.
Code that pins the target class, as in JSON.parseObject(body, SomeDto.class), is on that list too.

Even when the input JSON is bound to a fixed DTO, if that DTO has an Object or Map field, the content of that field has no fixed type.
Those values go into Fastjson’s type resolution without passing through the outer class specification, and enter the same resource lookup path there.

Start by listing the direct and transitive dependencies on com.alibaba:fastjson and comparing them against the version inside the fat-JAR you shipped.
Then look for the places where externally supplied JSON strings enter Fastjson.

mvn dependency:tree -Dincludes=com.alibaba:fastjson
./gradlew dependencyInsight \
  --dependency com.alibaba:fastjson \
  --configuration runtimeClasspath
jar tf app.jar | rg '^BOOT-INF/lib/fastjson-.*\.jar$'
rg "JSON\\.parse|JSON\\.parseObject|JSONReader|JSONObject\\.parse" src

What this search returns is a set of candidates; static imports, in-house wrappers and calls that go through another module do not show up in a text search.
And even after the dependency tree tells you whether the library is present, the entry points for externally reachable JSON extend past HTTP requests to admin screens, webhooks, internal APIs and message queue consumers.

Whether SafeMode is on is decided by the ParserConfig actually in use

As of July 26, 2026 there is no new fixed regular build of Fastjson 1.x.
The fastjson repository on GitHub was archived on October 23, 2024, and the newest tag is still 1.2.83 from May 23, 2022, which is the version being attacked right now.

The short-term options are enabling SafeMode or switching to the noneautotype build.
SafeMode stops type resolution at a point earlier than the class resource lookup used here.

java -Dfastjson.parser.safeMode=true -jar app.jar

If you set it in code, and you can confirm that every call site uses the global instance, the following is enough to stop it.

ParserConfig.getGlobalInstance().setSafeMode(true);

However, code that passes new ParserConfig() or its own ParserConfig to the parser does not pick up a field change made on the global instance.
Fastjson 1.2.83 decides SafeMode from SafeMode on the ParserConfig itself, from Feature.SafeMode at the call site, or from JSON.DEFAULT_PARSER_FEATURE. Look past the startup arguments to the configuration files and to how the parser is actually called.

jcmd 12345 VM.system_properties \
  | rg '^fastjson\.parser\.safeMode='
jar tf app.jar | rg '(^|/)fastjson\.properties$'
unzip -p app.jar BOOT-INF/classes/fastjson.properties \
  | rg '^fastjson\.parser\.safeMode='
rg "setSafeMode|Feature\\.SafeMode|new ParserConfig|AutoTypeCheckHandler" src

Even if it does not show up in the system properties, SafeMode may be enabled in code or through a Feature at the call site.
Conversely, even when isSafeMode() on the global instance returns true, any entry point that uses a different ParserConfig does not have that setting applied to its parser. AutoTypeCheckHandler is called before the SafeMode decision, so if one is registered, check whether it limits the permitted types to a strict allowlist.

The other P0 option is com.alibaba:fastjson:1.2.83_noneautotype.
Alibaba’s advisory describes that build as one where the vulnerable AutoType-related code is removed at compile time.
It is worthless if a downstream library pulls the regular fastjson back in, though, so verify the actual artifact including dependency management on Maven or resolution strategy on Gradle.

Fastjson2 has neither the resource probing that is the root cause here nor a path that trusts an annotation enough to skip the check.
It also handles type permissions allowlist-first.
Migration takes compatibility work, but Fastjson2 is what Alibaba lists as the long-term fix. The noneautotype build closes the path used by this CVE, but you are still running a 1.x line that is out of maintenance.

Attacks are observed, but no evidence of impact is public

ThreatBook reported on July 22, 2026 that after adding detection rules it confirmed exploitation in the wild.
Its own reproduction is narrower: full code execution on a Spring Boot fat-JAR with JDK 8, and only a remote JAR fetch or SSRF in the embedded Tomcat test.

Imperva also reported exploitation attempts against CVE-2026-16723, with traffic observed toward finance, healthcare, computing and retail.
The traffic is mostly US, with small volumes from Singapore and Canada.
The company says it inspects for suspicious @type values, nested JAR URL patterns and RCE techniques on the WAF side.

What public sources confirm is the observation of attack requests and exploitation attempts.
Evidence of code execution reaching a live environment, victim organization names, breach counts, raw requests and post-execution process artifacts are not in either company’s published write-up.
NVD’s change history also records that CISA-ADP added SSVC with exploitation set to none on July 23, 2026.
That is CISA-ADP’s classification as of that date, and it does not line up with the vendors’ observation claims.
As of July 26, 2026 the CVE is not in CISA KEV either. Rather than waiting for a KEV listing, change the setups where a regular 1.2.68–1.2.83 build, SafeMode off, a parse entry point reachable by external JSON, and a Spring Boot fat-JAR all overlap.

On the logging side, the things to detect are @type, jar:http, jar:file, outbound HTTP/HTTPS traffic, child processes spawned from the Java process, web shells, and unexpected file changes.
What WAF and CDN logs preserve stops at the request; what the Java process went on to execute is not there.
Whether an RCE succeeded is decided by correlating EDR, auditd, the systemd journal, application logs and container runtime logs.

References:

• Alibaba fastjson2 Wiki: Security Advisory Remote Code Execution in fastjson 1.2.68-1.2.83
• CVE Project: CVE-2026-16723
• FearsOff: FastJson 1.2.83 Remote Code Execution
• GCSA: Fastjson 1.2.83 Gadget-Free Vulnerability Analysis
• Fastjson Wiki: fastjson_safemode
• Spring Boot: Nested JARs
• ThreatBook: Fastjson RCE <=1.2.83 Active Exploitation Detected
• Imperva: Customers Protected Against CVE-2026-16723 Critical FastJson 1.x Zero-Day RCE
• NVD: CVE-2026-16723
• CISA: Known Exploited Vulnerabilities Catalog
• Maven Central: com.alibaba:fastjson:1.2.83_noneautotype
• GitHub tags: alibaba/fastjson