Fastjson CVE-2026-16723: Default Spring Boot RCE Explained

What does this flaw actually do?

Fastjson is a Java library for reading and writing JSON. According to Alibaba's advisory, the cause is Fastjson 1.x's checkAutoType check, which calls getResourceAsStream on user-controlled type names. In a Spring Boot fat JAR, a forged nested JAR path lets the attacker retrieve bytes of their choosing. The @JSONType annotation inside them is then read as a trust signal, the class passes the checks and loads, which gives code execution.

The entry points are JSON.parse, JSON.parseObject(String) and JSON.parseObject(String, Class). Specifying a target class does not protect, since the payload can sit in an Object or Map field. The chain was described by Kirill Firsov (FearsOff Cybersecurity), who reported the flaw.

Who is affected?

Applications are affected when three conditions combine: Fastjson 1.2.68 through 1.2.83, deployment as a Spring Boot executable fat JAR, and a network path by which attacker-controlled JSON reaches the parser. According to Alibaba, plain JARs, generic uber-JARs and WARs on Tomcat or Jetty are not affected, nor is Fastjson2 for this CVE. Version 1.2.83, long recommended as the safe one, is itself in the affected range.

On exploitation, ThreatBook reported in-the-wild exploitation on July 22 and Imperva described activity aimed at finance, healthcare, computing and retail, mostly in the United States. Neither published attack counts or a confirmed victim: these reports show attempts, not proven compromises. A CISA-ADP assessment on July 23 marked exploitation as "none" and the flaw was absent from the KEV catalog on July 25, with no public explanation for the gap.

How do you detect it in your applications?

1. Inventory Fastjson, including transitive dependencies: mvn dependency:tree | grep fastjson or gradle dependencies.
2. Identify the deployment mode: a Spring Boot fat JAR started with java -jar is the risky case.
3. Find endpoints that parse untrusted JSON: public APIs, webhooks, message queues, imports.
4. Search logs for unexpected "@type" values or nested JAR paths in JSON bodies, as well as unusual outbound connections, child processes of the Java process, file changes and web shells.

How do you fix it?

1. Upgrade to Fastjson 1.2.84, named as the fix in the updated advisory. Check the published version and its checksum before deploying.
2. Enable SafeMode if you cannot update right away: -Dfastjson.parser.safeMode=true, ParserConfig.getGlobalInstance().setSafeMode(true) or the fastjson.properties file.
3. Use the `com.alibaba:fastjson:1.2.83_noneautotype` artifact as a stopgap.
4. Plan the migration to Fastjson2, which removes this root cause. Alibaba notes that version 2.0.63 or later fixes a separate AutoType issue, so target at least that.
5. Filter at the edge bodies containing "@type" as defense in depth, without making it your only barrier.

Why does this pattern keep coming back?

Input-driven type resolution is a classic flaw of Java deserialization libraries, from Log4Shell to Spring4Shell and Fastjson's past AutoType bypasses. Our articles on Log4Shell and Spring4Shell show the same logic. A library that has already had several code execution flaws deserves monitoring and a written replacement plan.

What changes when an AI agent runs on a Java application?

Many AI agents rely on Java services: tool gateways, connectors to databases or CRMs, workflow services. These services parse JSON all the time, including JSON that a model produces. The scenarios below are test hypotheses about Fastjson in an agent's Spring Boot stack, not facts reported about this CVE.

The agent's JSON is untrusted input. An agent builds tool calls in JSON from text a third party can influence (email, web page, document). If a Java tool passes that JSON to Fastjson 1.x, attacker-chosen content reaches the parser without going through any public API. That is the definition of indirect prompt injection, covered on our prompt injection page.

The Java process carries the agent's credentials. Code execution on the tool service gives access to the API keys, database tokens and cloud credentials the agent uses. The blast radius is that of the agent, not that of a simple web service.

Automatic actions amplify the impact. An attacker who controls the tool can send falsified responses back to the agent and trigger follow-up actions (writes, sends) without human validation. The mechanism is excessive agency (LLM06, OWASP Top 10 for LLM Applications 2025): the agent chains writes and sends on the strength of a forged tool response.

Tool dependency inventories are rarely done. MCP servers and connectors written in Java add their own transitive dependencies. See our MCP security page.

Useful controls: validate every tool call against a strict schema before parsing, isolate the tool service with minimally scoped credentials, block unneeded outbound traffic and log calls. Our AI agent security page details these measures.

How do you test this exposure on an agent?

We map the agent's tools, their language and libraries, identify those that parse JSON coming from the model, then check what injected text can deliver to them. We also measure what a compromised process can reach: secrets, databases, actions with no validation.

For a Spring Boot application that feeds an agent, our Agent Red Team Express checks in 5 days (1,900 €) what a booby-trapped deserialization can trigger, after a free 30-minute discovery call.