astropod sign in

fastjson 1.x CVE-2026-16723 - yikes!

2026-07-25 17:22:44 · last edited 2026-07-25 17:27:19 · Chris vulnerability-intelligencesoftware-supply-chain-securitymavenjavaremote-code-executiondeserialization

Published on gastropod.io on 07-25-2026

With No Patch for fastjson 1.x CVE-2026-16723 is an Inventory Problem

Tags: vulnerability-intelligence, software-supply-chain-security, maven, java, remote-code-execution, deserialization, fastjson

Alibaba's fastjson, one of the most widely deployed JSON libraries in the Java world, has an unauthenticated remote code execution flaw that is being probed in the wild right now. It is tracked as CVE-2026-16723, and as of July 25, 2026 there is no patched 1.x release to install.

Security researcher Kirill Firsov of FearsOff Cybersecurity reported the bug through responsible disclosure, and Alibaba published its advisory on July 21. The affected range is fastjson 1.2.68 through 1.2.83, and Alibaba assigned it a CVSS score of 9.0.

What makes this fastjson bug different

It works under stock defaults. Older fastjson RCE chains needed AutoType switched on or a useful gadget class already present on the classpath. This one needs neither. Firsov traced it to fastjson's type-resolution path, where an attacker-controlled @type value becomes a class-resource lookup. Inside a Spring Boot executable JAR, a crafted nested JAR path can fetch attacker-controlled bytecode, and a @JSONType annotation on that resource is treated as proof the class is safe, which lets it pass fastjson's type checks and load.

The exploit is not universal, and the exact conditions decide who is actually exposed. The confirmed chain needs a Spring Boot executable JAR, a network-reachable endpoint that passes attacker-controlled JSON to an affected parser, and SafeMode left off, which is the default.

The packaging detail explains why those terms matter. Spring Boot bundles an application and all its dependencies into one runnable archive, and it stores those dependencies as JARs nested inside that archive, read through a custom loader. This is often called a "fat JAR." The attack abuses that nested-JAR path to reach its bytecode. Packaging that does not use that nested structure is not affected, and Alibaba names three: a plain application JAR shipped without its dependencies bundled in, a shaded "uber-JAR" that merges every dependency flat into a single archive with no nesting, and a Tomcat or Jetty WAR. Only the Spring Boot nested-JAR layout exposes the path the exploit needs.

Reachable entry points include JSON.parse and both parseObject signatures. Binding input to a fixed class does not protect you if that class holds an Object or Map field where the payload can nest. The maintainers verified the chain on Spring Boot 2.x, 3.x, and 4.x across JDK 8, 11, 17, and 21.

What the exploitation reports actually say

ThreatBook reported in-the-wild exploitation on July 22, and Imperva reported request activity aimed at financial services, healthcare, retail, and other sectors, mostly in the United States with smaller volumes in Singapore and Canada. Both describe observed exploit attempts, not confirmed code execution against a named target. The flaw was also still absent from CISA's Known Exploited Vulnerabilities catalog as of July 25, so the current evidence comes from vendor telemetry rather than a federal listing.

One detail in the version history makes this worse for some teams. Alibaba recommended 1.2.83 as the upgrade for a separate AutoType bypass back in 2022. That release falls inside the current affected range, so teams that patched cleanly three years ago and never moved off 1.x are exposed today.

No patch means step one is finding it

With no 1.x fix to apply, the options are configuration and migration. You can enable SafeMode with -Dfastjson.parser.safeMode=true, switch to the restricted 1.2.83_noneautotype build, or move to fastjson2, which does not use the same annotation-based path. Every one of those choices depends on the same first step, and it is the step teams underestimate: you have to know every place fastjson 1.2.68 through 1.2.83 actually resolved in your builds, including the copies you never chose directly.

fastjson is often a transitive dependency, not one you picked. It arrives pulled in by an ORM helper, a logging bridge, or an internal shared library that several teams inherited. A grep of your own pom files will miss those, and a scanner that matches on the name alone can confuse the affected 1.2.83 with the restricted 1.2.83_noneautotype build and report the wrong answer either way.

An artifact-aware registry produces that inventory as part of proxying your packages, so it is not a separate project you have to start. Gastropod tracks every Java artifact it proxies by its PURL, correlates OSV advisories at the specific version, and reconstructs a CycloneDX SBOM on demand, so you can already answer "where does fastjson 1.2.x live, directly and transitively" instead of researching it under time pressure. Because it identifies artifacts by exact version and digest, it tells the affected 1.2.68 through 1.2.83 builds apart from the 1.2.83_noneautotype restricted build instead of treating everything named fastjson as one thing. The transitive blast-radius graph shows which of your services pulled an affected copy and through what path, and a block rule at intake stops the affected range from entering new builds while you migrate.

If you cannot answer "which of our builds ship an affected fastjson right now" in under a minute, close that gap before the next unpatched Java deserialization bug appears. You can see how Gastropod handles it on the product page, or point a Maven client at it and check your own artifacts at gastropod.io/start.

Sources

← news