Fastjson 1.x Zero-Day RCE Under Active Exploitation — No Patch Available

Fastjson 1.x Is Being Actively Exploited for Unauthenticated RCE — And There's No Fix Yet

Attackers are actively exploiting a critical remote code execution vulnerability in Fastjson 1.x, Alibaba's widely used JSON parsing library for Java. Security firms ThreatBook and Imperva have confirmed the flaw is being targeted in the wild — and as of now, no patch exists for the 1.x branch.

What Happened

Researchers at ThreatBook and Imperva identified active campaigns exploiting an unpatched RCE flaw in Fastjson versions 1.x. In vulnerable Spring Boot applications, an attacker can send a crafted malicious JSON payload to any endpoint that deserializes input using the library — no authentication required. Successful exploitation runs arbitrary code with the privileges of the Java process, which in many production deployments means root or a highly privileged service account.

Fastjson 1.x has a long history of deserialization vulnerabilities (CVE-2022-25845 being a notable prior example), and many organizations never migrated to the 2.x branch. That legacy footprint is now the attack surface.

Why It Matters

Fastjson is extraordinarily common in Java ecosystems, particularly in Chinese-origin and enterprise Spring Boot stacks, but its use is global. The combination of factors here is about as bad as it gets:

• No authentication barrier — any network-reachable endpoint is exposed
• No patch available — the 1.x branch has no vendor fix at time of writing
• Active exploitation in the wild — this is not theoretical; attacks are happening now
• Code runs as the Java process — in containers or misconfigured services this often means full host compromise

If your organization runs any Java applications built on Fastjson 1.x — directly or via a transitive dependency — assume you are exposed until proven otherwise.

What To Do

1. Audit your dependency tree immediately. Search all Java projects for fastjson in pom.xml, build.gradle, or lock files. Don't forget transitive dependencies — run mvn dependency:tree | grep fastjson or the Gradle equivalent.

1. Migrate to Fastjson 2.x if at all possible. The 2.x branch is a near-complete rewrite with a different security model. Migration is not always trivial, but it is the only durable fix.

1. If migration is not immediately feasible, isolate and restrict. Place vulnerable services behind strict network controls. Block external access to any endpoint that accepts arbitrary JSON input. Consider a WAF rule targeting known Fastjson gadget chain patterns — Imperva's research will inform signature development.

1. Enable JVM-level deserialization filters. Java 9+ supports jdk.serialFilter to block dangerous class hierarchies at the JVM level. This is a defense-in-depth measure, not a complete fix.

1. Monitor for exploitation indicators. Look for anomalous outbound connections from Java processes, unexpected process spawning from your app server, and JNDI/LDAP lookup attempts in logs.

Do not wait for a patch. With no fix on the 1.x branch and confirmed active exploitation, the window between "we'll deal with it later" and "we have an incident" is closing fast.