Alibaba fastjson 1.2.68–1.2.83 — remote code execution under stock defaults in Spring Boot fat-JAR deployments; no patched 1.x release, exploited in the wild

CVE-2026-16723 — Alibaba fastjson 1.2.68–1.2.83: remote code execution under stock defaults in Spring Boot fat-JARs, exploited in the wild with no 1.x patch

Alibaba's fastjson 1.2.68 through 1.2.83 carries a remote code execution flaw that fires under the library's shipped defaults: "This vulnerability is exploitable under fastjson's stock default configuration — no AutoType enablement required, no classpath gadget required" (Alibaba fastjson2 project, 2026-07-21). The single deployment precondition is that the application runs as a Spring Boot executable fat-JAR, which the maintainer notes is the most common Spring Boot deployment model, and the advisory records end-to-end verification across Spring Boot 2.x/3.x/4.x and JDK 8, 11, 17 and 21. All three common entry points — JSON.parse, JSON.parseObject(String) and JSON.parseObject(String, Class) — are reachable, and the defensive habit most teams rely on does not help: passing a concrete target class is explicitly not a mitigation, because a payload can be nested inside any Object- or Map-typed field of that DTO (same advisory). The root cause is fastjson 1.x resolving user-controlled class names through a resource-probing path and treating the @JSONType annotation as a trust signal — behaviour fastjson2 removes architecturally, which is why no fastjson2 version is affected.

The operational problem is that there is nothing to patch. Imperva states that "FastJson 1.x is no longer actively maintained, and no patched 1.x version has been released for this vulnerability" (Imperva, 2026-07-24), leaving three vendor-sanctioned routes: enable SafeMode, which rejects all @type input before the vulnerable path is reached; deploy the 1.2.83_noneautotype build, which strips the vulnerable code at compile time; or migrate to fastjson2 (Alibaba fastjson2 project, 2026-07-21). Deployments that are not Spring Boot fat-JARs — uber-JARs and Tomcat or Jetty WAR deployments — do not meet the trigger condition, and fastjson 1.2.60 and earlier lack the vulnerable code path entirely (same advisory). Imperva reports attacks already in progress "across Financial Services, Healthcare, Computing, Retail, Business, and other industries", currently concentrated almost entirely on US-based organisations with a few in Singapore and Canada, and expects the targeting to expand globally; roughly 30 per cent of the attack traffic it sees comes from Ruby- and Go-based tooling rather than browser impersonators (Imperva, 2026-07-24). The vulnerability was reported by Kirill Firsov of FearsOff Cybersecurity (Alibaba fastjson2 project, 2026-07-21).

Detection concepts, telemetry class first: in reverse-proxy, WAF and application access logs, surface JSON request bodies carrying @type or @JSONType keys against any endpoint that deserialises user input; in process-creation telemetry with parent lineage, alert on the JVM spawning a shell or downloader child; and in egress telemetry, look for outbound connections initiated by the Java process at the moment of type resolution, which is how the resource-probing path manifests when it reaches for an attacker-supplied class. The discriminator against benign traffic is configuration state rather than the marker itself — applications that deliberately use fastjson's polymorphic deserialisation also carry @type fields, so the signal is a @type value resolving to something outside the application's own allow-listed DTOs on an instance where SafeMode is off, not the presence of the key. Because the exposure is a library rather than a product, the hard part is inventory: fastjson 1.x is most likely to be present in Swiss and European estates as a transitive dependency inside a vendor-supplied Spring Boot artifact, where neither an asset inventory nor a national-CERT advisory will name it.