Fastjson 1.x RCE Vulnerability Targeted in Attacks With No Patch Available

A Forgotten Code Path in a 1.x Branch

The vulnerability traces to Fastjson's type-resolution path, where an attacker-controlled @type value is converted into a class-resource lookup. In a Spring Boot executable fat-JAR — a self-contained deployment artifact that packages all dependencies into a single archive — a crafted nested JAR path can be made to point at attacker-controlled bytecode. An @JSONType annotation in that resource is then treated as a trust signal, allowing the class to pass Fastjson's type checks and load. This is notable because the chain does not require AutoType to be enabled, nor does it need a classpath gadget — the standard ingredients attackers look for when targeting Java deserialization flaws.

The flaw was discovered by Kirill Firsov of FearsOff Cybersecurity and reported to Alibaba on a responsible-disclosure timeline that culminated in an advisory on July 21. The maintainers verified the chain against Spring Boot 2.x, 3.x, and 4.x running on JDK 8, 11, 17, and 21 — a broad swath of enterprise Java stacks still in production. Fastjson 1.2.83, originally released as Alibaba's recommended upgrade for a separate AutoType bypass disclosed in 2022, now sits inside the affected range.

What the Exploit Chain Actually Requires

The vulnerability is not a blanket condition. The confirmed chain requires Fastjson 1.2.68 through 1.2.83, a Spring Boot executable fat-JAR, a network-reachable endpoint that delivers attacker-controlled JSON to an affected parser, and SafeMode left at its disabled default. Alibaba lists plain non-fat JARs, generic uber-JARs, and Tomcat or Jetty WAR deployments as unaffected. The reachability requirement matters in practice: exposed JSON.parse, JSON.parseObject(String), and JSON.parseObject(String, Class) entry points are the realistic targets, and binding input to a fixed class is not sufficient when an object contains an Object or Map field that can carry nested payloads.

Firsov's analysis also documents a newer-JDK variant that downloads a remote JAR and references it through /proc/self/fd, broadening the attack surface. The result is an unauthenticated code-execution path carrying a CVSS 9.0 — the kind of finding that would normally trigger urgent patching, except that no fix is available.

Detection Gaps and the CISA Disconnect

ThreatBook reported on July 22 that its platform had captured in-the-wild exploitation, after adding detection support two days earlier; its laboratory reproduction produced full code execution on Spring Boot fat-JAR with JDK 8, while embedded Tomcat tests produced only a remote JAR fetch or server-side request forgery. Imperva reported attack traffic against financial services, healthcare, computing, and retail organizations, primarily in the United States, with smaller volumes in Singapore and Canada, noting that browser impersonators generated most requests while Ruby and Go tools accounted for roughly 30%.

Neither vendor published attack counts, raw requests, execution evidence, named victims, or confirmed compromises, and the reports establish observed exploit activity rather than proof of successful code execution against a real-world target. A July 23 CISA-ADP assessment nevertheless marked exploitation as "none," and The Hacker News confirmed on July 25 that the flaw was absent from CISA's Known Exploited Vulnerabilities catalog. The available sources do not explain the mismatch, leaving defenders to choose between competing signals about urgency.