There is no patch. That is the first thing to understand about the remote code execution vulnerability currently being exploited in Fastjson 1.x. Attackers are hitting the flaw right now, it requires no authentication and the only fix is to stop using the affected version of the library.
The vulnerability affects all Fastjson versions up to and including 1.2.83. It is exploitable under the library’s default configuration which means any application running Fastjson 1.x without additional hardening should be treated as exposed until migration is complete. No CVE number has been publicly assigned and no CVSS score is available though SentinelOne’s vulnerability database lists a related AutoType RCE flaw as CVE-2025-70974. ThreatBook’s research team confirmed active exploitation in the wild in a published analysis, and The Hacker News reported in July 2026 that attacks on unpatched Java applications are ongoing.
The absence of a CVE is a practical problem. Teams that rely on vulnerability scanners and CVE feeds to triage their patch queue will not see this flaw surface automatically. The exploitation is real regardless of what the databases say.
What the Flaw Actually Does
Fastjson is a Java library developed by Alibaba for serialising and deserialising JSON data. It is widely used in enterprise Java applications across backend services, APIs and data pipelines. The vulnerability sits in the AutoType feature which allows Fastjson to deserialise JSON into specific Java class types. An unauthenticated attacker who can send a crafted JSON payload to an endpoint using Fastjson 1.x can trigger arbitrary class loading and achieve remote code execution on the underlying server.
No credentials. No prior access. A malformed HTTP request is sufficient if the application exposes a Fastjson-backed endpoint to the network.
AutoType has been the source of multiple critical Fastjson vulnerabilities going back to 2019. The Alibaba engineering team addressed the structural risk in Fastjson 2.x by disabling AutoType by default. The 1.x branch never received an equivalent architectural fix and it is not going to. The branch is effectively unmaintained for security purposes.
Two Options, One Deadline You Set Yourself
Migrate to Fastjson 2.x. That is the only permanent resolution. Fastjson 2.x disables AutoType by default and is not affected by this class of vulnerability. The migration requires code changes in any application that relies on 1.x-specific behaviour so it is not a one-line dependency bump but it is the only option that closes the exposure permanently.
If migration cannot be completed immediately, enable SafeMode in Fastjson 1.x. SafeMode disables AutoType entirely which breaks the exploit chain. It will also break any application functionality that depends on AutoType so test thoroughly before enabling it in production. SafeMode is a containment measure, not a fix. The 1.x branch remains unpatched and unsupported for this vulnerability.
Check your network perimeter. Any Fastjson-backed service that should not be publicly accessible needs to be confirmed as not publicly accessible. Active exploitation suggests attackers are scanning for exposed endpoints not targeting specific organisations.
The Wider Context: Cl0p Is Also Scanning Java Applications Right Now
The timing is not ideal. Security Week reported that the Cl0p ransomware group is currently exploiting a separate vulnerability in PTC Windchill while Fastjson RCE attacks are hitting unpatched Java applications. These are distinct campaigns but they reflect the same pattern: criminal groups are actively hunting for unpatched Java-stack vulnerabilities in enterprise environments, and they are moving quickly once a working exploit is confirmed in the wild.
Organisations running legacy Java application stacks with dependency debt accumulated over years of development are the ones most likely to have Fastjson 1.x buried somewhere in a transitive dependency they did not choose directly. Run a dependency audit before assuming you are not affected. A software composition analysis tool will surface it faster than a manual review of pom.xml files.
The lack of a CVE for this specific exploitation wave makes it easy for organisations to deprioritise. That is exactly the wrong call when active exploitation is confirmed and no patch exists.
References
- Unpatched Fastjson Vulnerability Exploited in Attacks
- Fastjson 1.x RCE Vulnerability Targeted in Attacks With No Patch Available
- Fastjson RCE (≤1.2.83): Active Exploitation Detected
- CVE-2025-70974 Fastjson AutoType RCE
This post is also available in:
Svenska
