Hackers Hit Unpatched Fastjson Bug in Spring Boot Apps, No Fix Yet

Key points

• Attackers are exploiting CVE-2026-16723, a critical flaw in Fastjson, Alibaba's popular JSON library for Java applications.
• The bug lets a specially crafted web request run code on the server with no login required, rated 9.0 out of 10 by Alibaba.
• Security firms ThreatBook and Imperva say the attacks are targeting Spring Boot apps, a widely used Java web framework.
• No official patch is available at the time of writing.
• Any organisation running Fastjson 1.x behind a Java web app should assume it is a target.

Security researchers say criminals are actively attacking a serious flaw in Fastjson, a piece of software from Alibaba that Java applications use to read and write JSON data (the plain-text format websites and apps use to shuffle information around).

The bug is tracked as CVE-2026-16723. Alibaba rates it 9.0 out of 10 on the standard severity scale, which puts it firmly in "drop everything" territory.

There is no patch yet.

What does the bug actually let attackers do?

It lets an unauthenticated attacker run their own code on a vulnerable server. In plain terms: someone on the internet can send a booby-trapped web request to a website using Fastjson, and the server will execute whatever commands the attacker chose, without ever asking who they are.

The code runs with the same permissions as the Java process handling the request. On many servers, that is enough to read files, install malware, or pivot deeper into the network.

According to security firms ThreatBook and Imperva, the confirmed attack chain targets Spring Boot applications. Spring Boot is a very common framework developers use to build Java web services, so the pool of potential victims is large.

Who is affected?

Anyone running Fastjson 1.x inside a Java web application that accepts JSON from users. That covers a lot of internal tools, APIs, and public-facing sites built over the last decade.

Fastjson has a rough history with this class of bug. The 1.x branch has been patched repeatedly for similar deserialization flaws, where the library is tricked into building dangerous objects out of attacker-supplied data. Alibaba shipped Fastjson 2 partly to draw a line under those problems. Teams that never migrated are now exposed again.

What should defenders do right now?

Assume exploitation and act. With no vendor fix, the practical options are containment and detection, first reported by The Hacker News as an active-exploitation story rather than a theoretical one.

Inventory first. Find every service using Fastjson 1.x. Java build files (pom.xml for Maven, build.gradle for Gradle) will list it as a dependency. Do not trust memory: dependencies pull in other dependencies, and Fastjson often arrives that way.

For exposed services, put a web application firewall rule in front of any endpoint that parses JSON, and log JSON payloads containing suspicious type hints (Fastjson exploitation historically abuses the @type field to force the library to build attacker-chosen Java classes). Block outbound traffic from application servers to anything they do not need to reach, which cuts off a common exploitation step where the server is told to fetch a malicious payload from an attacker-controlled host.

Migration to Fastjson 2 remains the durable fix. It is not a drop-in replacement, but it removes an entire category of risk that the 1.x line has never truly shaken.

Does this affect ordinary people?

Not directly, but indirectly yes. If a company you use runs a vulnerable Java service, attackers could reach customer data behind it. There is nothing for a home user to patch. Watch for breach notifications from services you use, and treat any unexpected password-reset or "unusual login" email in the coming weeks with the usual caution: go to the site directly rather than clicking the email.