Fastjson RCE (CVE-2026-16723) puts Spring Boot apps at risk — act now

A flaw that can let an attacker take over a server just by sending it a crafted piece of data has been found in older versions of "Fastjson," a data-conversion component widely used in Java systems. Tracked as CVE-2026-16723, it is rated near the top of the danger scale at CVSS 9.0 (Critical).

That said, the score alone is no reason to panic. Several conditions have to line up before the flaw can be exploited—which also means that by checking those conditions, you can tell clearly whether your own system is affected. This article walks through what happens, who is at risk, and exactly what to do if you are.

What Fastjson is, and why the impact is so wide

Fastjson is a component for Java programs published by China's Alibaba (Alibaba Group). Its job is simple: it converts back and forth between data exchanged in the text format called "JSON" and the data a program handles internally. Whenever a mobile app talks to a server, or one system hands data to another, this conversion is running quietly behind the scenes.

Every Java system contains a converter of this kind, and Fastjson is one of the go-to choices. Known for its speed, it has been used around the world for years, from corporate business systems to the backends of consumer web services. The problem here lies in the older 1.x series, including "1.2.83," which is the final release of that line.

In other words, even if you have never heard of this component, there is a good chance it runs behind a service you use every day. The Chinese security firm Qi'anxin estimates that "millions" of systems worldwide are in an exposed state to this flaw.

What happens: incoming data alone can take over the server

The frightening part of this flaw is that all an attack needs is to send one crafted piece of data. There is no need to steal a password or first break inside. The moment Fastjson reads JSON data sent from outside, the problem occurs.

In plain terms, here is how it works. Fastjson reassembles the data it receives into the "objects" a program can handle. During that reassembly, an attacker can slip in an instruction that says, in effect, "go fetch the command at this address and run it." The server obeys, reaches across the internet to retrieve the attacker's prepared command, and runs it. This is the state known as "remote code execution," where arbitrary commands can be run from outside.

Technically, it arises when Fastjson's type-resolution logic meshs badly with the class-loading mechanism of Spring Boot, the foundation many apps run on. The attacker nests the attack data inside flexible fields such as "Object" or "Map" in the data the target receives. According to security-media analysis, the striking feature of this flaw is that the whole chain succeeds under stock default settings.

Attacks that abuse the process of restoring received data to its original form are not unique to Fastjson. The same class of weakness has surfaced repeatedly, such as in the remote-takeover flaw found in Apache MINA; it is a long-standing weak point in the Java world.

Who attackers target, and what they do

The kind of adversary who goes after this flaw is one who scans internet-facing corporate and service servers en masse, hunting for entry points that still run an old version of Fastjson. Rather than pinpointing one specific victim, this flaw suits attacks that "mechanically find whatever targets are exploitable." Because proof-of-concept code is already circulating, even less-skilled attackers can readily copy the technique.

Once they find a target, what the attacker does is send the crafted data, run any command they like on the server, and take it over from the inside. Once commands can be run, anything goes—stealing stored customer data, planting ransomware, or using the server as a stepping stone into other internal systems.

The harm points in two directions. For end users of the service, personal or payment information they entrusted could leak. For the company running the system, losing control of the server ties directly to business downtime and reputational damage. That is exactly why the next section—pinning down whether your system is even affected—matters so much.

Is your system affected? Judge by three conditions

While the severity is a high CVSS 9.0, the score's breakdown sets "attack complexity (AC)" to high. That is because not just any server can be taken over instantly; several prerequisites must line up first. Based on the official advisory and security reporting, you are at risk when all three of the following apply.

• You use Fastjson 1.2.68 through 1.2.83—older 1.2.60-and-earlier, or the successor "fastjson2," are not affected by this flaw.
• You run it as a Spring Boot "fat-jar"—the most common packaging, launched with "java -jar app.jar." The older "WAR" style of deployment is reported to be out of scope.
• You have an endpoint that reads JSON data from outside, and the server can make outbound HTTP requests—the state in which it can go fetch the attacker's prepared command.

If even one of the three does not apply, there is no risk of takeover through this flaw. In particular, environments already migrated to fastjson2, or systems that do not use Fastjson at all, need take no action here. Start by having your development team confirm whether your systems match the three conditions above.

Affected-version quick reference

The table below shows where your version stands. You can find the version from the number next to "com.alibaba:fastjson" in your dependency list (Maven's pom.xml or your Gradle configuration).

The key point is that no fix for this flaw will be released for the 1.x line. 1.2.83 was already the final version of the 1.x series, and development has moved to fastjson2. So the usual move of "just upgrade to a newer 1.x" is not available, and you must protect yourself through the other methods described below.

Why the usual defenses do not work

For past Fastjson flaws, turning off a feature called "AutoType" was the standard defense. AutoType automatically determines the type (class) of received data and restores it, and it had been the entry point for previous takeover attacks. This time, however, turning off AutoType does not stop the attack.

Traditional attacks assumed the presence of a "gadget"—a component that could serve as a stepping stone—inside the system. That is why measures like "don't use risky components" or "restrict with an allowlist" worked. But this technique needs no such stepping-stone component. The discoverer, Kirill Firsov, describes it as "gadget-free remote code execution." It is a new type of attack that breaks the old assumptions, so the conventional wisdom no longer applies as-is.

This property—succeeding "under stock settings" and "without a stepping-stone component"—is what drives the severity up. That is why the mitigations below need to cut off the attack's prerequisites at the root, rather than being stopgap config tweaks.

What to do right now

If you matched the three conditions above, consider the mitigations in the following order, listed from highest priority down.

• Enable SafeMode first—turn it on by adding -Dfastjson.parser.safeMode=true at startup, specifying it in the config file (fastjson.properties), or setting it from code. This is the fastest emergency measure to stop the attack from succeeding.
• Swap in a build with AutoType fully removed—changing the dependency to com.alibaba:fastjson:1.2.83_noneautotype switches to a build that does not even include the risky auto-detection feature.
• Migrate to the successor, fastjson2—fastjson2 was redesigned from the ground up and is not affected by this flaw. It is the fundamental fix, and over the long term this migration is the real answer.
• Block outbound HTTP from the server—preventing the server from fetching the attacker's command closes off one of the prerequisites, as defense in depth.

As an emergency measure, enabling SafeMode is the quickest, and starting there is the realistic move. On top of that, plan the migration to fastjson2 over time. If you want to keep continuously surfacing what vulnerabilities lurk in the components you use, see our explainer on a system for automatically checking open-source components for vulnerabilities as well.

Has exploitation already started?

As of publication, there are no confirmed reports of this flaw being used in real attacks. But there is no room for complacency. After the discoverer's disclosure, third-party proof-of-concept (PoC) code has already been published, putting the technique within easy reach of anyone. The time from PoC circulating to real attacks starting keeps shrinking year over year, so "we haven't been attacked yet, so we're fine" is not a safe assumption.

The flaw is also not yet listed in the "catalog of flaws confirmed to be under attack (KEV)" published by the U.S. agency CISA. That, however, only means "not yet listed," and it could be added if the situation changes. You can check the latest listing status in our Japanese-language roundup of CISA's confirmed-attack list. Systems that match the affected conditions are safer acting ahead of time, without waiting for a KEV listing.

The discoverer's warning

The flaw was discovered and reported by Kirill Firsov of the security firm FearsOff. In a post on X, he explains the nature of the flaw as follows.

As the discoverer himself notes—calling it "one of the most widely-deployed" components—the true danger of this flaw is the breadth of its reach. Beyond the numeric severity, the point to watch is that "because it is a component found everywhere, you may be affected without realizing it."

What to watch from here

To sum up: the severity is at the critical level, but this is not a reason to hastily shut everything down. First confirm whether you use "Fastjson 1.2.68–1.2.83, as a Spring Boot fat-jar, together with an endpoint that reads external data"; if not, no action is needed this time. If you do, enable SafeMode as the top-priority emergency measure, then plan the migration to fastjson2.

The things to watch from here are whether real attacks begin to be observed, and whether it gets added to CISA's confirmed-attack list (KEV). Because no fix will be released, affected systems will eventually have no choice but to migrate to fastjson2. We will update this article as follow-ups or changes in listing status appear. It is also reassuring to check the official record for CVE-2026-16723 alongside this.

Sources

• ▸ NVD - CVE-2026-16723 Detail
• ▸ Alibaba - Security Advisory: Remote Code Execution in fastjson 1.2.68–1.2.83 (July 21, 2026)
• ▸ SC Media - Fastjson library affected by high-severity RCE bug
• ▸ SecurityOnline - Public PoC Exploit Released for fastjson 1.2.83 Remote Code Execution Flaw
• ▸ Kirill Firsov (FearsOff) - Post on X (July 19, 2026)
• ▸ GitHub - alibaba/fastjson2 (successor / migration target)