Potheeswaran 
A newly disclosed remote code execution vulnerability in FastJson, the once-ubiquitous Alibaba-built JSON library for Java, is putting Spring Boot applications worldwide at risk, with attacks already underway and no patch coming for the affected branch.
Tracked as CVE-2026-16723 and carrying a CVSS score as high as 9.8 depending on the scoring source, the flaw strips away FastJson’s long-standing AutoType defenses without requiring authentication, user interaction, or a gadget class. FastJson maintainers published their security advisory on July 21, 2026, crediting FearsOff Cybersecurity with the discovery.
The bug spans versions 1.2.68 through 1.2.83, the entire tail end of the 1.x branch, including its final-ever release, and has been confirmed exploitable in Spring Boot fat-JAR deployments across Spring Boot 2.x, 3.x, and 4.x, running on JDK 8, 11, 17, and 21. NSFOCUS CERT independently corroborated the “no gadget, no AutoType required” exploitation path, rating it CVSS 9.8.
Critical FastJson 1.x Zero-Day RCE
The exploit abuses FastJson’s polymorphic deserialization feature, which relies on an attacker-influenced @type field to determine which Java class gets instantiated.
Normally, FastJson 1.x blocks untrusted classes through AutoType restrictions, but this flaw exposes an alternate route through the library’s internal type-resolution logic that treats the @JSONType annotation as an implicit trust signal.
In vulnerable Spring Boot fat-JAR setups, attackers can weaponize nested JAR URLs during this resource-lookup process to sidestep FastJson’s checks entirely and reach code execution all through routine parsing calls like JSON.parse or JSON.parseObject.
Even specifying a target class during deserialization isn’t a reliable safeguard, since malicious payloads can still be smuggled inside Object- or Map-typed fields.
Imperva report that exploitation attempts are already targeting a broad swath of industries: financial services, healthcare, computing, retail, and business services, with activity concentrated in the US and smaller footprints appearing in Singapore and Canada.
Imperva confirmed the flaw is being actively targeted in the wild, noting there is currently no patched version for the 1.x line. Roughly 30% of observed attack traffic originates from tools written in Ruby and Go, with the remainder disguised as browser traffic, suggesting both opportunistic scanning and more deliberate automated exploitation.
Mitigation
Because FastJson 1.x is no longer actively maintained, there is no forthcoming patch; organizations must rely on configuration hardening and migration instead. Recommended immediate steps include:
- Enable SafeMode via -Dfastjson.parser.safeMode=true, the fastjson.properties file, or ParserConfig.getGlobalInstance().setSafeMode(true)
- Use a FastJson noneautotype build to strip AutoType code at compile time
- Inventory all Java and Spring Boot apps for direct and transitive FastJson dependencies
- Migrate to FastJson 2.x, which uses an allowlist-first model and doesn’t treat @JSONType as a trust signal
- Audit logs for suspicious @type fields or jar:http/jar:file URL patterns, and inspect systems for webshells or unauthorized changes
Imperva says its Cloud WAF and WAF Gateway customers are already shielded from exploitation attempts targeting this flaw, inspecting incoming requests for malicious JSON payloads and suspicious @type behavior.
Still, researchers stress that perimeter defenses are a stopgap, not a substitute for retiring vulnerable FastJson 1.x deployments given the flaw’s unauthenticated, zero-interaction exploitation profile.
About the Author
