A single JSON request can hand a Java server over to an attacker. That is the uncomfortable summary of CVE-2026-16723, a critical remote code execution flaw (CVSS 9.0) in Fastjson 1.x, the veteran Alibaba JSON serialisation library still running inside thousands of enterprise applications. The security firm FearsOff found it, the Fastjson maintainers published an advisory on 21 July 2026, and within days it was being exploited in the wild against US organisations.
What makes it urgent is not the score but the lack of a comfortable exit: Fastjson 1.x has reached the end of its practical life and no patch is coming for that branch. Vendors such as ThreatBook and Imperva confirmed real-world attacks within days of disclosure. And because Fastjson usually travels as a transitive dependency —nobody installed it on purpose, it arrived on the back of another library— many teams do not even realise they are running it.
At a glance
- CVE-2026-16723 is a remote code execution flaw in Fastjson 1.x, triggered when the library parses malicious JSON, with no authentication required.
- It affects Fastjson 1.2.68 through 1.2.83 in Spring Boot applications packaged as an executable fat-JAR, with SafeMode left at its disabled default.
- There is no patch for the 1.x branch. The immediate mitigation is to enable SafeMode; the real fix is migrating to Fastjson 2.x, which is not affected.
- The bigger risk is what you cannot see: the library is frequently a transitive dependency, so the first job is inventory, not patching.
How it works, without the recipe
Fastjson turns JSON into Java objects. Its long-standing weak point is the @type field, which tells the library which Java class to instantiate when reading a document. To curb abuse of that field, the project added AutoType over time and, later, SafeMode. What is new here is that the confirmed chain works under the stock default configuration: no AutoType enabled, and no classic gadget chain on the classpath.
Conceptually, a crafted @type value is turned into a class-resource lookup that lets an attacker load bytecode from a nested path inside a JAR, while the @JSONType annotation ends up serving as a trust signal that walks the class past the library's own security checks. The outcome is code execution in the application's context. We do not reproduce the request itself: the mechanism is enough to understand the risk and prioritise the defence, which is the point.
For the confirmed chain to work, several conditions must line up at once:
- Fastjson in the 1.2.68 to 1.2.83 range.
- A Spring Boot application packaged as a fat-JAR (confirmed on Spring Boot 2.x, 3.x and 4.x, across JDK 8, 11, 17 and 21).
- A network-reachable path that feeds attacker-controlled JSON to an affected parser.
- SafeMode at its default value, meaning disabled.
The figures, and who stands behind them
The official record lists CVE 2026-16723 at CVSS 9.0, affecting Fastjson 1.2.68 through 1.2.83. The finding belongs to the security firm FearsOff, and the Fastjson maintainers published their advisory on 21 July 2026, as recorded in Tenable's entry.
In-the-wild exploitation, aimed mainly at US organisations, is reported by BleepingComputer and The Hacker News, which cite security vendors including ThreatBook and Imperva among those observing the attacks. The point that matters most for a security leader is the one several analyses stress: Fastjson 1.x is discontinued and no fix is coming for the branch, so the correct route is migration to 2.x.
Why the usual controls fall short
Patch management, the reflex reaction to a CVE, has nothing to grab onto here: there is no patch to apply. When a component reaches end of life, the vulnerability management process has to change register, moving from “patch” to “mitigate and replace”.
The second problem is visibility. Fastjson is rarely declared by hand; it arrives as a transitive dependency pulled in by something else, a classic supply chain attack pattern. A by-eye inventory will not find it, which is why software composition analysis and an SBOM stop being nice-to-haves and become the only reliable way to know whether you are exposed. We develop the point in lessons from the digital supply chain.
The third is that the payload can resolve from a path internal to the fat-JAR itself, which complicates network or WAF rules built to block class loading from external servers. This is exactly where running a scanner is not the same as managing the risk.
Operational detection
Without waiting for a patch, there are concrete signals a team can watch from now:
- Review application and proxy logs for suspicious values inside JSON bodies: @type, jar:http: or jar:file: strings.
- Watch for unexpected child processes of the JVM —a Java instance spawning a command interpreter, PowerShell or /bin/sh is a clear anomaly— and correlate them in the EDR.
- Look for anomalous outbound connections from application servers (towards LDAP, RMI or HTTP to unknown destinations), new files in application directories and possible web shells.
- Map the surface: list Fastjson's direct and transitive dependencies with your build tooling (Maven or Gradle dependency tree) or an SCA platform.
Practical defence
The immediate mitigation is to enable SafeMode, which closes the confirmed path outright. Apply it through the JVM start-up property -Dfastjson.parser.safeMode=true or, in code, with ParserConfig.getGlobalInstance().setSafeMode(true). Test it first: SafeMode disables @type processing, so it will break any feature that relies on instantiating types declared in the JSON.
From there, and in this order, the sensible plan is:
- If SafeMode breaks something critical, consider the compatibility artefact com.alibaba:fastjson:1.2.83_noneautotype as an interim step.
- Plan the migration to Fastjson 2.x, which is not affected by design, after compatibility testing: the API changes and it is not a drop-in replacement.
- Keep a virtual patch on the WAF while the migration runs; several vendors published rules for this CVE, but it is a bridge, not the destination.
- Restrict outbound traffic from application servers: tightening egress limits the impact of a remote class load if something slips through.
If monitoring surfaces signs of exploitation, treat the case as an incident rather than a mere finding: isolate, preserve evidence and trigger the incident response procedure. Deciding what to mitigate first when several exposures are open is exactly the ground covered by frameworks such as KEV, EPSS and SSVC.
What NIS2 and DORA look at here
This case is not judged by the CVE alone, but by how you manage dependencies and unmaintained software. NIS2 requires covered entities to manage supply chain risk and the vulnerability lifecycle; DORA asks financial entities for equivalent control over ICT and third-party risk, with demonstrable inventory and resilience. A discontinued component in production stops being a technical footnote and becomes an audit finding.
And there is a clock: if exploitation with impact is confirmed, notification windows —NIS2's timelines and DORA's reporting duties— start to run. Having the component located, the mitigation documented and the replacement plan mapped is what separates an orderly response from a blind scramble.
The bottom line
Fastjson 1.x is the perfect example of the debt that appears on no roadmap: code that works, that nobody looks at, and that one day becomes the way in. The quick answer is called SafeMode. The serious answer is knowing, at any moment, which libraries you actually run and which ones no longer have anyone to fix them. The first takes an afternoon; the second is a muscle you train.
This analysis is provided for defensive purposes. The configuration and mitigation options described should be tested in a controlled environment before being taken to production: enabling SafeMode or switching to the noneautotype artefact may change the behaviour of applications that rely on the @type field.