Why Every Spring Boot Fat‑JAR Is Vulnerable to the New Fastjson RCE Flaw

On July 19, security researcher Kirill Firsov announced a gadget‑free remote code execution vulnerability in Fastjson 1.2.83, providing a PoC that gains a shell with a single payload.

Alibaba issued CVE‑2026‑16723 (CVSS 9.0/9.8) and the article consolidates the official notice, the researcher’s technical write‑up, and reports from several security vendors to explain the impact and remediation steps.

Previous Fastjson exploits required either AutoType to be enabled or a usable gadget class on the classpath, so the common defence was to disable AutoType and remove risky dependencies. This new flaw bypasses those measures because Fastjson’s type‑parsing logic attempts to load an unknown type name as a class‑path resource and checks for the @JSONType annotation, treating it as trusted.

By crafting a malicious @type value, the attacker forces Fastjson’s internal character replacement to produce a URL that points to a remote JAR. The application then downloads and loads the malicious class before normal type checks, making the AutoType setting and classpath contents irrelevant.

Even code that explicitly calls JSON.parseObject(body, SomeDto.class) is not safe, because malicious content can be hidden in Object or Map fields and still trigger the vulnerable parsing path.

Conditions for being vulnerable :

Fastjson version : 1.2.68–1.2.83 (or the broader 1.2.37–1.2.83 range reported by some vendors).

Deployment method : Executable Spring Boot fat‑JAR launched with java -jar. WAR deployments on external Tomcat are not affected.

SafeMode : Must be disabled (default).

Outbound network : The server must be able to reach external HTTP endpoints so the attacker‑controlled JAR can be downloaded.

Entry point : Any public or internal API that passes external JSON to Fastjson (including callbacks and inter‑service calls).

The reason fat‑JARs are specifically impacted is that they use LaunchedURLClassLoader, which resolves nested JAR resources and will perform a real network request for the crafted URL, whereas a regular class loader would treat the name as a local path and stop.

JDK version influences the exploit path: JDK 8 allows a single‑step execution, while JDK 9+ requires a two‑step approach (download then load) due to stricter class‑name validation. The researchers verified successful exploitation on JDK 8, 11, 17, and 21; on Windows with newer JDKs the two‑step method fails.

Real‑world exploitation has been observed. Imperva’s July 24 report recorded attacks against U.S., Singapore, and Canadian targets across finance, healthcare, IT, and retail sectors (finance 28 %, healthcare 22.9 %). ThreatBook also issued alerts for wild exploitation. A full PoC, detection rules, and a vulnerable testbed are publicly available on GitHub and have been reproduced on JDK 8, 17, 21, and 25.

Fastjson 1.x was archived as read‑only in October 2024, so no further patches will be released; waiting for an upstream fix is not an option.

Recommended actions :

Inventory all Java services, prioritize those that depend on Fastjson 1.x and run as Spring Boot fat‑JARs.

Enable SafeMode immediately, either via JVM flag -Dfastjson.parser.safeMode=true or programmatically with ParserConfig.getGlobalInstance().setSafeMode(true).

Restrict outbound HTTP from application servers to prevent malicious JAR downloads.

Plan a migration to Fastjson 2.x, which has a redesigned architecture and is not vulnerable to this flaw.

The article concludes that the long‑standing belief that upgrading to the latest 1.x version and disabling AutoType guarantees safety was misplaced; the new vulnerability invalidates that assumption and forces teams to act quickly.