TL;DR
- what: CVE-2026-16723 is an unauthenticated remote code execution flaw in Alibaba's Fastjson 1.x JSON library, disclosed July 21 and already seeing in-the-wild exploit activity.
- impact: A single malicious JSON request to a reachable parser runs arbitrary code with the privileges of the Java process, with no authentication, no AutoType, and no classpath gadget required.
- fix: No fixed Fastjson 1.x exists as of July 25; enable SafeMode via -Dfastjson.parser.safeMode=true or switch to com.alibaba:fastjson:1.2.83_noneautotype, and migrate to Fastjson2 for the long-term fix.
- who: Spring Boot 2.x/3.x/4.x applications packaged as executable fat-JARs on JDK 8/11/17/21 that parse attacker-reachable JSON with Fastjson 1.2.68 through 1.2.83.
A single unauthenticated JSON request can now execute arbitrary code inside a large class of Java web applications. CVE-2026-16723 is a critical flaw in Fastjson, Alibaba's widely deployed JSON library for Java. In an affected Spring Boot application, a crafted request runs code with the full privileges of the Java process, no login required. Alibaba assigned it a CVSS score of 9.0. As of July 25, there is no patched Fastjson 1.x release available.
Security firms ThreatBook and Imperva report exploit activity in the wild. Alibaba published its advisory on July 21 after responsible disclosure by Kirill Firsov of FearsOff Cybersecurity. The catch: Fastjson 1.2.83, the version Alibaba recommended after a separate 2022 AutoType bypass, now sits inside the affected range. Organizations that patched last time are exposed this time.
What makes this different
Prior Fastjson RCE chains depended on AutoType being enabled and on a usable gadget already sitting on the classpath. This one needs neither. The maintainers confirmed the chain works with no AutoType enablement and no classpath gadget, verified against Spring Boot 2.x, 3.x, and 4.x on JDK 8, 11, 17, and 21. That combination covers a very large share of production Java services.
Firsov traced the issue to Fastjson's type-resolution path. An attacker-controlled @type value gets turned into a class-resource lookup. In a Spring Boot executable fat-JAR, a crafted nested JAR path can fetch attacker-controlled bytecode. An @JSONType annotation inside that resource is then treated as a trust signal, letting the class pass Fastjson's type checks and load. His analysis also documents a newer-JDK variant that pulls a remote JAR and references it through /proc/self/fd.
⚠️ The exact conditions for exploitation — The confirmed chain requires all of: Fastjson 1.2.68–1.2.83, a Spring Boot executable fat-JAR, a network-reachable path that feeds attacker-controlled JSON to the 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 fat-JAR loader is what makes the resource-probing step work.
Where the payload gets in
Reachable entry points include JSON.parse, JSON.parseObject(String), and JSON.parseObject(String, Class). Binding input to a fixed class does not save you: if that class contains an Object or Map field, the payload can be nested inside it and still reach the vulnerable path. Any endpoint that hands untrusted JSON to a 1.x parser should be treated as in scope until proven otherwise.
What the telemetry actually shows
ThreatBook said on July 22 that its platform captured in-the-wild exploitation two days after adding detection. Its own lab results were narrower: full code execution on a Spring Boot fat-JAR under JDK 8, but its embedded Tomcat test produced only a remote JAR fetch or server-side request forgery. Imperva reported activity against financial services, healthcare, computing, and retail organizations, primarily in the United States, with smaller volumes in Singapore and Canada. Browser impersonators generated most requests; Ruby and Go tooling made up roughly 30% combined.
Be precise about what this proves. Neither vendor published attack counts, raw request volumes, execution evidence, named victims, or confirmed compromises. The reports establish observed exploit attempts, not proof of successful code execution against a real target. A July 23 CISA-ADP assessment marked exploitation as none, and the flaw was absent from CISA's Known Exploited Vulnerabilities catalog as of July 25. The sources do not explain that mismatch. Treat the risk as active regardless: exploit activity plus no patch is a bad combination to wait out.
Mitigation and response
There is no fixed 1.x artifact in the project's GitHub tags or on Maven Central. Version 1.2.83 remains the latest standard 1.x release, and 1.2.83_noneautotype remains the restricted build. Until a fix ships, apply a stopgap and hunt for signs of use.
- Enable SafeMode with -Dfastjson.parser.safeMode=true, or swap in com.alibaba:fastjson:1.2.83_noneautotype.
- Inventory direct and transitive Fastjson dependencies; transitive pulls are easy to miss.
- Migrate to Fastjson2, which is not affected because it does not use the same resource-probing or annotation-based trust path. Alibaba lists this as the long-term fix.
- Inspect affected systems for suspicious @type values, nested JAR URLs, unexpected outbound connections, unexpected child processes, file changes, and web shells.
Prioritization — Focus first on Spring Boot fat-JAR services on JDK 8, where full RCE has been reproduced, that expose JSON parsing to untrusted networks. WAR deployments on Tomcat or Jetty and non-fat JARs are outside the confirmed chain, but confirm your packaging before deprioritizing them.
The uncomfortable takeaway: the recommended remediation for the 2022 Fastjson bypass landed users squarely inside this one, and there is currently nowhere to upgrade to within the 1.x line. Fastjson2 is the exit, and until you get there, SafeMode is the seatbelt.
Originally published on RedEye Threat Intelligence.
