Skip to content
Braincap
← All articles

FastJSON: an actively exploited RCE zero-day (CVE-2026-16723) with no patch

by Claudiu Hulea · IT Management Consultant

Illustration of code execution through unsafe JSON deserialization

A critical remote code execution (RCE) flaw in the Java library FastJSON (CVE-2026-16723) is being actively exploited in real-world attacks, especially against US companies. It’s made worse by an unpleasant detail: FastJSON 1.x is no longer maintained, so there is no patch. Below: what it is, how it works and what to do instead of “wait for the update”.

In brief

  • The library: FastJSON — an open-source Java library (from Alibaba) for JSON serialization/deserialization, very widely used.
  • Vulnerability: CVE-2026-16723, RCE via unsafe deserialization, critical severity.
  • Affected: FastJSON 1.2.68 – 1.2.83. Not affected: 1.2.60 and earlier, fastjson2, and non-“fat-JAR” deployments.
  • Patch: none — FastJSON 1.x is no longer actively maintained.
  • Status: actively exploited; primary targets in the US (plus Singapore and Canada), across sectors such as financial services, healthcare, retail and IT.

How it works

Attackers abuse @type processing during deserialization to slip malicious classes into Object or Map fields. The root cause: the type-resolution logic performs attacker-controlled resource lookups before it enforces AutoType restrictions — so loading a malicious class is possible without AutoType enabled and without third-party “gadget” chains.

Two things make it especially dangerous:

  • It bypasses the usual defences: even if you specify the target class at deserialization, you are not protected from CVE-2026-16723.
  • Exploitation particularly targets Spring Boot fat-JAR deployments (launched with java -jar xxx.jar).

Why it’s dangerous

You have an RCE that is already exploited in the wild, in a widely used library that no longer receives fixes and that bypasses common defensive settings. The “actively exploited + no patch” combination moves it from “watch this” to “act now”.

What to do now

  1. Enable SafeMode in FastJSON immediately, or switch to a non-impacted build, as an emergency measure.
  2. Migrate to fastjson2, which uses an allowlist-first polymorphic deserialization model — far safer by design.
  3. Inventory where you use FastJSON 1.x — including as a transitive dependency (pulled in by other libraries), not just directly. Here a software bill of materials (SBOM) or an audit helps enormously.
  4. Monitor and filter: look for deserialization payloads with a suspicious @type in traffic, and treat internet-exposed systems as a priority.

The takeaway

Deserialization libraries are a classic RCE surface, and end-of-life (EOL) components are a special risk: when a vulnerability appears, no patch follows. Dependency inventory and removing unmaintained components are exactly the hygiene an IT security audit brings to light, while a penetration test confirms what is genuinely exploitable.

Sources

Frequently asked questions

What is the FastJSON CVE-2026-16723 vulnerability?

A critical remote code execution (RCE) flaw via unsafe deserialization in the Java library FastJSON, actively exploited in real attacks. It affects FastJSON 1.2.68–1.2.83; not affected are 1.2.60 and earlier, fastjson2, and non-fat-JAR deployments.

Is there a patch?

No. FastJSON 1.x is no longer actively maintained, so no fix is coming. The "actively exploited plus no patch" combination moves it from "watch this" to "act now".

Why does it bypass the usual defences?

Because the type-resolution logic performs attacker-controlled resource lookups before it enforces AutoType restrictions — so loading a malicious class is possible without AutoType enabled and without third-party gadget chains. Even if you specify the target class at deserialization, you are not protected.

What do I do if I use FastJSON 1.x?

As an emergency, enable SafeMode or switch to a non-impacted build. Then migrate to fastjson2 (allowlist-first model, safer by design), inventory where you use FastJSON 1.x including as a transitive dependency (SBOM/audit), and monitor traffic for deserialization payloads with a suspicious `@type`.