# Fastjson Is Being Exploited Again — And This Time There's No Patch to Hide Behind
Some libraries accumulate CVEs the way bad neighborhoods accumulate incident reports. Fastjson, Alibaba's wildly popular Java JSON parser, has been on that list for years. This week, attackers stopped waiting for security researchers to finish their responsible disclosure paperwork.
An unpatched remote code execution vulnerability in Fastjson is being actively exploited in the wild. No authentication required. No obscure configuration needed. Default settings are enough.
---
## The Library That Won't Stay Fixed
If you've been tracking Java ecosystem security for any length of time, Fastjson feels like a recurring nightmare you keep waking up in the middle of. The library — used across hundreds of thousands of Java applications globally, and deeply embedded in Chinese enterprise software stacks — has an almost comically bad track record with deserialization attacks.
The root problem is autoType, a feature that lets Fastjson automatically determine the Java class to instantiate when deserializing JSON. It's a developer convenience that became a security catastrophe. The feature essentially lets an attacker-controlled JSON payload dictate what code the server runs. Alibaba has patched, restricted, and tried to wall off autoType repeatedly since 2019. Each time, researchers found bypasses. Each time, defenders scrambled to update. Each time, the window between disclosure and mass exploitation got shorter.
This latest vulnerability follows that pattern but with a particularly unwelcome twist: there is no patch. Exploitation is already underway, which means every Fastjson deployment running default configuration is currently a live target.
---
## What's Actually Happening When It Gets Exploited
The technical shape of this attack is worth understanding concretely, because it informs where defenders should look.
RCE via Fastjson in its classic form works through the deserialization chain. An attacker sends a crafted JSON payload to any endpoint that parses user-controlled JSON with Fastjson. The payload references a malicious class — often through JNDI lookup chains, LDAP callbacks, or direct class instantiation — and the library dutifully tries to load it. Once that class loads on the server JVM, the attacker has code execution in the application's security context.
The "no authentication required" detail is what elevates this from serious to immediate. Authentication is the first gate. When that gate doesn't exist — when a public-facing endpoint accepts and processes JSON before it even checks who's asking — you're not talking about a breach that requires spearphishing or credential theft. You're talking about drive-by exploitation at scale.
The "stock default configurations" qualifier is equally damning. It means there's no complex setup defenders need to audit for. If you're running Fastjson and you haven't explicitly hardened it, you're likely vulnerable. The library's defaults are the attack surface.
---
## Who Should Be Losing Sleep Right Now
The immediate exposure pool skews toward:
Java-heavy enterprise applications — particularly those built during the 2015–2022 period when Fastjson was at peak adoption in the Chinese tech ecosystem, and when the library was frequently recommended as a faster alternative to Jackson.
APIs and microservices — REST endpoints that accept JSON payloads from external clients are the natural attack surface. Internal-only services are somewhat insulated, but "internal only" is a claim that rarely survives contact with a compromised perimeter.
Applications that haven't updated Fastjson recently — the library's security posture has improved over its history, but only for teams actively maintaining their dependency trees. Abandoned projects or codebases with frozen dependencies are running whatever version they shipped with.
Supply chain targets — this is worth flagging. Fastjson shows up in transitive dependencies: your application might not directly import it, but a library you use might. Maven and Gradle dependency trees can obscure this. A ./gradlew dependencies | grep fastjson is not a bad fifteen minutes to spend today.
---
## The Patch Problem
When a zero-day lands in something like OpenSSL or Log4j, the vendor typically races to ship a fix. The framing is: patch fast, and you're protected.
Fastjson's situation is messier. The library has a complex relationship with backward compatibility, and previous security fixes broke real production applications. Some organizations explicitly chose older, vulnerable versions because the "fixed" versions changed behavior they depended on. That's not theoretical — it's documented in GitHub issues and Stack Overflow threads going back years.
More fundamentally: there is no patch available yet. That means the defender's toolkit right now is mitigation, not remediation.
---
## What Defenders Can Actually Do Right Now
Since patching isn't currently an option, the response has to be layered:
grep -r "fastjson" pom.xml across your repos is a start; a proper SCA scan is better.${jndi: strings or unusual LDAP/RMI connection attempts from app servers, add those detections now.---
## HackWire Analysis
Fastjson's security history is a case study in what happens when a feature designed for developer convenience has no safe exit ramp. The autoType feature was useful enough that millions of developers adopted it; it was also dangerous enough that Alibaba has spent half a decade trying to lobotomize it without breaking the libraries that depend on it. That tension — between utility and security — is precisely why the fixes have never felt final.
What's different this time is the exploitation-before-patch dynamic. In the Log4Shell playbook, there was a brief window between disclosure and widespread exploitation where defenders who moved fast could get ahead of attackers. That window appears to have closed before it opened here. Active exploitation in the wild without a patch means this is a first-responder situation, not a patch-Tuesday situation.
There's also a geographic dimension worth naming. Fastjson's heaviest concentration is in applications built by or for Chinese enterprises — tech companies, financial services, government-adjacent vendors. Those organizations are frequently targeted by both nation-state actors and financially motivated ransomware crews. The intersection of a popular library, a critical unpatched RCE, and a target-rich environment in that sector is not a coincidence anyone should dismiss.
For the broader Java ecosystem, this is another argument for dependency hygiene as a security discipline, not just a maintenance chore. Java's richness is partly the richness of its library ecosystem. That ecosystem's vulnerabilities are inherited by every application that touches them. An unauthenticated RCE in a JSON parser is a reminder that the attack surface doesn't start at your application code — it starts at your dependency tree.
Until Alibaba ships a fix, this is a containment problem. Treat it like one.
— HackWire Editorial
---
## Related Coverage