Alibaba’s Fastjson library — still embedded in a huge share of Java backends despite years of AutoType-bypass RCEs — has another critical remote code execution flaw, and this one is worse than the usual pattern. CVE-2026-16723 (CVSS 9.0) needs no authentication, no AutoType enabled, and no third-party gadget class on the classpath. It’s already being exploited in the wild, and Alibaba has confirmed there will be no patched Fastjson 1.x release.

What happened

FearsOff Cybersecurity researcher Kirill Firsov reported the flaw, and Alibaba published its advisory on July 21, 2026. The confirmed attack chain needs only four things: Fastjson somewhere in the 1.2.68–1.2.83 range, a Spring Boot application packaged as an executable fat-JAR, a network-reachable endpoint that feeds attacker-controlled JSON into an affected parser method, and SafeMode left at its disabled-by-default state. That’s it — no AutoType toggle to flip, no deserialization gadget from a library like Commons Collections or CC-BC needed. A single crafted JSON request is enough to get code execution with the privileges of the Java process.

This breaks the mental model most teams have relied on since Fastjson’s earlier RCE waves (2017 and 2020’s autoType bypasses), where disabling AutoType was treated as sufficient mitigation. It wasn’t a complete fix then and it does nothing against this bug at all — the flaw sits in how the fat-JAR classloader layout interacts with Fastjson’s type resolution during parsing, independent of the AutoType feature flag.

Active exploitation

Attacks started within days of disclosure and are ongoing as of this writing. Telemetry shows targeting concentrated in the US, with additional activity against organizations in Singapore and Canada, spanning financial services, healthcare, retail, and general business/computing infrastructure. Roughly 30% of observed attack tooling is written in Ruby and Go rather than off-the-shelf Java exploit kits, with the remainder using browser-impersonating HTTP clients to blend into normal traffic — a sign attackers have moved past proof-of-concept and built repeatable tooling.

Why there’s no patch

Fastjson 1.x has been in maintenance-only mode for years, with Alibaba steering new deployments to the rewritten Fastjson2. As of July 25, no fixed 1.x release exists, and none is expected — this is being treated as an end-of-life library issue rather than a bug the vendor will backport a fix for. That leaves every application still pinned to Fastjson 1.x permanently exposed unless operators apply mitigations themselves or migrate off it entirely.

Affected versions and impact

Fastjson 1.2.68 through 1.2.83 running inside Spring Boot fat-JAR deployments with SafeMode disabled (the default). Given how long Fastjson 1.x has been the default JSON library for a large fraction of Chinese and global enterprise Java stacks, and how many of those services are packaged exactly this way for containerized/cloud deployment, the exposed population is large. Successful exploitation hands an attacker code execution as the application’s service account — from there, credential theft, lateral movement, and data exfiltration follow the same playbook as any other Java RCE.

Mitigation

  • Enable SafeMode explicitly: set the JVM flag -Dfastjson.parser.safeMode=true, or switch to the com.alibaba:fastjson:1.2.83_noneautotype artifact, which enforces the equivalent restriction at the dependency level.
  • Treat SafeMode as mandatory going forward, not optional hardening — this bug proves AutoType-disabled alone is not a sufficient control for Fastjson 1.x.
  • Inventory every service still on Fastjson 1.x (check both direct dependencies and transitive pulls via older Spring/MyBatis/Dubbo integrations) and prioritize migration to Fastjson2, which uses a different parsing architecture not subject to this class of bug.
  • Add WAF/RASP rules to flag anomalous JSON payloads hitting deserialization-adjacent endpoints, and monitor for unexpected outbound connections or process spawns from Java services immediately after a JSON POST.
  • Do not rely on network segmentation alone if the affected endpoint is internet-facing — patch or mitigate immediately given confirmed active exploitation.

Alibaba’s advisory and Imperva’s technical breakdown have the clearest detail on the affected code paths: The Hacker News coverage and Imperva’s analysis both link through to the underlying advisory. Expect a CISA KEV addition if exploitation against US targets continues at its current pace.