Fastjson CVE-2026-16723 runs your bytecode inside the type check

The Fastjson maintainers pushed the advisory for CVE-2026-16723 on July 21, credited FearsOff's Kirill Firsov as the finder, and told anyone still on 1.x to enable SafeMode immediately because a fix is not coming to that branch. ThreatBook captured in-the-wild exploitation the next day, and by the weekend Imperva's telemetry showed active probes against US financial services, healthcare, computing, and retail. What ate my Tuesday is where the vulnerable code sits: in the type check that runs before deserialization binding. If your Java service is a Spring Boot executable fat-JAR that packages Fastjson 1.2.68 through 1.2.83 and parses attacker-reachable JSON with SafeMode at its default off, an unauthenticated request lands attacker bytecode on your JVM.

Where the primitive actually lives

Fastjson's polymorphic deserialization is gated by ParserConfig.checkAutoType, which decides before binding whether a @type-carrying JSON object is safe to hydrate. In the 1.2.68 through 1.2.83 window, the gate does more than a name check. It probes the classpath for the target class using getResourceAsStream on name.replace('.','/') + ".class", reads the @JSONType annotation off the class if one is present, and if that annotation is there returns early and marks the type safe.

On a plain java -cp classpath, that probe is bounded by the local filesystem. Inside a Spring Boot fat-JAR launched via java -jar app.jar, the thread context classloader is org.springframework.boot.loader.LaunchedURLClassLoader, which resolves the nested-JAR URL scheme Spring Boot invented to pack dependencies inside the outer artifact. It accepts jar:http://attacker.example/x.jar!/attacker/Type.class as a legitimate URL and fetches, opens, and reads the inner class bytes. The community lab at dinosn/fastjson-jsontype-rce-lab documents the full chain: the gate probes a nested-JAR URL, the loader fetches attacker bytes, the class inside carries @JSONType, and the gate hands those bytes to defineClass, whose static initializer then runs. That static initializer is the exploit.

@JSONType is the trust primitive the attacker also writes

The failure mode is worth naming precisely. @JSONType is a legitimate feature that lets a library owner mark a class as intentionally polymorphic so Fastjson does not reject it. The trust model assumes the annotated class lives inside the application's own classpath. The classloader probe breaks that assumption: attacker-hosted bytecode presents itself to the gate, and the gate cannot tell "we wrote this annotation" from "the attacker forged it into their JAR." Whoever writes the class file writes the annotation.

That is why turning AutoType off is not the mitigation everyone reaches for first. AutoType gates whether Fastjson accepts a @type field during binding. The vulnerable probe runs earlier, inside checkAutoType, on the class name before binding starts. Even a handler like JSON.parseObject(body, MyDto.class) with a concrete target is exposed, because a @type nested inside any Object or Map-typed field of MyDto still reaches the gate. The official advisory is explicit that specifying a target class does not protect you.

Two roads from the probe to defineClass

The exploit ships two paths so it covers JDK 8 through 25. On JDK 8 the direct route is enough: LaunchedURLClassLoader resolves the attacker's jar:http:// URL, defineClass runs with the fetched bytes, and the static initializer fires before the gate has any chance to say no. FearsOff's public PoC against 1.2.83 uses this shape.

On modern JDKs, internal name mismatches and loader hygiene changes get in the way of a one-shot remote fetch, so the exploit uses a Linux procfs trick. When the classloader resolves a remote jar:http URL, the JVM caches the fetched archive behind an open file descriptor. A follow-up probe in the same request against jar:file:/proc/self/fd/N!/wanted/internal/Name.class reopens the cached JAR under whatever internal class name the exploit needs, and that is what pushes coverage through JDK 25.

What the CVSS 9.0 is not telling you

The scalar reads correctly for a network attack with no privileges, no user interaction, and full code execution. What it does not carry is two properties that make CVE-2026-16723 harder than the average 9.0. First, no patched 1.x version exists or is coming; Fastjson 1.x is in maintenance mode, and the maintainers pointed everyone at 2.x, which the advisory calls unaffected because its type resolution does not probe resources on user-controlled class names. Second, Fastjson 1.x has been the default JSON binding in a decade of Java tutorials and is bundled inside many Spring Boot fat-JARs where SBOM tools walking the outer artifact miss the shaded dependency. The scanner says the app is patched. The fat-JAR still contains a vulnerable Fastjson.

The TRIS layers on CVE-2026-16723

TRIS, the Threat and Risk Intelligence Scoring engine inside CVEasy AI, splits scoring into layers so the same CVE reads differently depending on your actual exposure. Four layers matter here.

Exploitation Signal. ThreatBook confirmed in-the-wild exploitation on July 22, and Imperva reported active probes across US Financial Services, Healthcare, Computing, and Retail through the weekend, plus a small footprint in Singapore and Canada. Attackers are running the FearsOff-style payload directly against JSON endpoints. Top band. Worth being precise: mass probes and a working PoC are the loudest early warning, not proof any specific organization has been breached, and TRIS treats it that way rather than closing incidents automatically.

Reachability and Config. Two conditions have to align: the service parses attacker-reachable JSON with Fastjson 1.2.68 through 1.2.83, and SafeMode is at its default off. Both are true for the majority of production installs. A public JSON API on port 443 with SafeMode off sits at the top of the band; the same service with SafeMode already on drops this layer to near zero.

Deployment Shape. The documented chain requires Spring Boot's LaunchedURLClassLoader to resolve the nested-JAR URL, so a fat-JAR launched via java -jar is the confirmed shape. A plain WAR under Tomcat or a flat -cp classpath is not currently in that shape. TRIS uses the distinction, though I would treat it as "less exposed today," not "safe," because the classloader trick is a discovery, not a physical law.

Consequence. The payload runs with the privileges of the Java process, so blast radius follows what your service can reach: actuator endpoints, embedded credentials, sibling service tokens, cloud instance metadata. A least-privilege account settles this layer lower; a single service account with broad DB and cloud IAM keeps it high.

An internet-reachable Spring Boot fat-JAR with Fastjson 1.2.83, SafeMode off, and a broad service account lands at ACT (top band). A segmented internal service with SafeMode enabled a year ago drops into Track. Same CVE, honestly different real-world risk. That split is the work CVSS is not designed to do.

SafeMode this hour, migration this quarter

1. Flip SafeMode on every affected process today. The three equivalent knobs are ParserConfig.getGlobalInstance().setSafeMode(true) at startup, the JVM flag -Dfastjson.parser.safeMode=true, or the property fastjson.parser.safeMode=true in a fastjson.properties file on the classpath. Pick whichever your deployment pipeline already understands and roll it in a normal restart window; the advisory ranks this P0.

2. Plan the migration to Fastjson 2.x. The advisory calls 2.x architecturally unaffected: it does not probe resources on user-controlled class names, does not treat @JSONType as a trust signal, and uses an allowlist-first model for polymorphic types. Its API surface needs real work, so treat SafeMode as the emergency stop and the 2.x migration as the durable fix, with the noneautotype build of 1.x as a second interim option.

3. Block jar: URLs in JSON bodies at the perimeter. Both the Imperva writeup and the community lab describe the same signature: a @type value paired with a nested jar:http, jar:https, or jar:file:/proc/self/fd/ URL. Any WAF that inspects body content should be adding a rule now. It buys time while SafeMode rolls; it will not save an unpatched service on its own.

4. Inventory fat-JARs alongside your Maven POMs. The dinosn lab ships fjscan_static.py, which walks JAR files and their nested Spring Boot layouts to flag an embedded vulnerable Fastjson. Any hit that is also internet-reachable moves to the top of the queue.

5. Hunt in access and WAF logs. Filter JSON bodies for the strings jar:http, jar:file, and /proc/self/fd/ paired with an @type field, then correlate matches with unexpected child processes descending from the Java worker (sh, bash, curl, wget, python) and outbound fetches from the JVM in the surrounding hours. The Latest Hacking News writeup lists the same field patterns.

How CVEasy AI surfaces CVE-2026-16723

CVEasy AI is the number one local-first CTEM (Continuous Threat Exposure Management) platform: it ingests the real sources for this event (the fastjson2 wiki advisory, the FearsOff summary, ThreatBook and Imperva telemetry, and the public PoCs) and runs TRIS against the Java inventory discovered on your own hardware. It answers the concrete questions that decide your week: which of your Spring Boot fat-JARs shade a Fastjson between 1.2.68 and 1.2.83, which processes still run with SafeMode at its default off, which are reachable at a JSON endpoint from outside the perimeter, and which showed body-level matches for jar: URLs in the exposure window. Your artifact inventory, JVM configuration, WAF logs, and the reasoning itself stay on your hardware. TRIS holds the finding at ACT for any exposed fat-JAR with SafeMode off, and only drops the band once SafeMode is observed active or the service has migrated to Fastjson 2.x.

Sources: Fastjson official advisory, The Hacker News, Imperva via Security Boulevard, Security Online (public PoC), dinosn/fastjson-jsontype-rce-lab, Latest Hacking News.