Security Alert: Active Exploitation of a Critical RCE (0-Day) Vulnerability in Fastjson 1.x

Introduction

Threat intelligence teams have detected a wave of active attacks targeting Java applications that still rely on the legacy Fastjson 1.x branch, the popular JSON serialization/deserialization library originally developed by Alibaba. The vulnerability, identified as CVE-2026-16723 with a CVSS score of 9.0 (Critical), affects Fastjson versions between 1.2.68 and 1.2.83 under specific Spring Boot deployment conditions, and can be exploited via malicious JSON without requiring authentication. Security vendors such as ThreatBook and Imperva have confirmed exploitation activity in production, representing a massive risk to exposed servers and web services that continue to operate on this legacy version. Most concerning: as of July 25, 2026, Alibaba had not published a fixed version for the 1.x branch, leaving thousands of organizations without an available official patch.

What Is the Fastjson 1.x Flaw?

Fastjson is a Java library widely adopted across the enterprise ecosystem for converting Java objects into JSON strings and vice versa, a fundamental process in REST APIs, microservices, and Spring Boot-based applications. Its popularity, especially among organizations that integrated technology of Chinese origin or legacy middleware, made it for years an almost invisible yet critical component of the software supply chain.

The underlying problem is that Fastjson, when deserializing JSON, sometimes needs to “resolve” which Java class a piece of data corresponds to. When that type-resolution process relies on information coming from the client-supplied message itself — that is, untrusted data — an attacker can manipulate that information to force the application to load arbitrary classes and, ultimately, execute malicious code remotely (RCE) on the target server, without needing credentials.

What’s distinctive about this new wave of attacks is that the flaw requires neither AutoType to be enabled nor the use of classpath gadgets; it works under the library’s default configuration, which drastically widens the attack surface compared to previous Fastjson vulnerabilities.

How Does It Work?

The exploitation mechanism relies on an insecure deserialization flaw that bypasses the library’s traditional protections:

• Entry point: the attacker sends an HTTP request with a specially crafted JSON body to an endpoint that processes data with Fastjson (for example, JSON.parseObject).
• Type-restriction bypass: although Fastjson 1.x disables AutoType by default and applies checks to prevent instantiation of untrusted classes, the vulnerability exposes an alternate path through its internal type-resolution logic. The attacker includes a manipulated @type value; during processing, the library can perform resource lookups based on that attacker-controlled class name.
• Abuse of the @JSONType annotation: this bypass is possible because Fastjson 1.x can treat the presence of a @JSONType annotation as a trust signal during type resolution, which normalizes the processing of a class that is actually hostile.
• Chaining in Spring Boot environments: in affected Spring Boot deployments packaged as fat-JARs, an attacker can manipulate this behavior using nested JAR URLs, bypass Fastjson’s normal type restrictions, and reach a code-execution path without needing a conventional deserialization gadget chain.
• Result: in affected Spring Boot applications, a malicious JSON request can execute code without authentication, with the privileges of the Java process, which in most corporate environments amounts to full control of the affected service and, potentially, lateral access to other systems on the internal network.

Unlike historical Fastjson vulnerabilities (such as the AutoType exploitation via JNDI in versions prior to 1.2.48), this attack chain does not depend on the developer explicitly enabling dangerous functions, which makes it especially insidious.

Affected Systems

• Vulnerable version range: Fastjson 1.2.68 through 1.2.83, the latter being the final version published within the 1.x branch and, paradoxically, the update that Alibaba had recommended in 2022 to fix an earlier AutoType bypass.
• At-risk deployment conditions: applications packaged as executable Spring Boot fat-JARs, with reachable network endpoints that process client-supplied JSON and with SafeMode disabled (default configuration).
• Impacted sectors: attacks exploiting this vulnerability are affecting a wide range of organizations in the Financial Services, Healthcare, Computing, Retail, and Business sectors, among others.
• Current geographic distribution: attacks are concentrated almost entirely on organizations headquartered in the United States, with isolated incidents in Singapore and Canada, though global expansion is expected.
• Typical corporate environments: legacy e-commerce systems, ERPs, middleware platforms, and Java microservices built years ago on Spring Boot that never migrated to Fastjson 2.x due to compatibility dependencies or lack of active library lifecycle management (software supply chain debt).
• Estimated exposure: the Chinese security vendor Qi’anxin, which tracks the flaw as QVD-2026-43021, estimates that millions of instances are potentially exposed globally.

Mitigation and Detection

Priority remediation recommendations

• Migrate to Fastjson 2.x: this is the most robust long-term measure, since Fastjson 2.x is not affected — its type-resolution architecture does not perform the same resource probing based on user-controlled class names, does not use @JSONType as a trust signal, and employs an allowlist-based model for handling polymorphic types.
• Enable SafeMode immediately: while migration is being planned, enabling SafeMode=true in the Fastjson 1.x configuration blocks polymorphic deserialization and mitigates exploitation of this specific chain.
• Restrict outbound traffic: blocking non-essential outbound HTTP/HTTPS connections from application servers reduces the impact of the remote resource-resolution phase used in the attack.
• Apply specific WAF rules: deploy signatures that detect @type, @JSONType patterns and suspicious jar:-type URLs or file-descriptor paths within incoming JSON payloads.
• Review official guidance: consult and apply the mitigations described in the security advisory published by the project maintainers in the official fastjson2 repository.

Auditing and detection

• Dependency inventory: administrators should audit pom.xml / build.gradle files and fat-JAR artifact manifests for references to com.alibaba:fastjson in the 1.2.68–1.2.83 range, using Software Composition Analysis (SCA) tools or dependency scanners (OWASP Dependency-Check, Snyk, GitLab Advisory Database).
• Web server log review: search logs for POST/PUT requests with JSON bodies containing @type or @JSONType fields with unusual class names, especially those referencing resource paths, nested JARs, or non-standard URL schemes.
• Monitoring for anomalous Java process behavior: alerts for unexpected child process creation from the JVM, unusual outbound connections from the application service, or file writes to system temp directories.
• Passive scanning tools: community-developed reachability scripts and scanners exist that allow non-intrusively identifying whether a deployment is potentially vulnerable, without needing to run proof-of-concept code against production systems.

Recap

This active exploitation campaign against Fastjson 1.x illustrates, once again, the constant danger posed by keeping outdated third-party libraries within production infrastructure. This is a library that, despite having spent years under scrutiny from the security community following multiple previous AutoType-related CVEs, continues to produce new exploitation paths due to the inherent complexity of its type-resolution logic. The fact that the vector requires neither authentication, nor explicit enabling of dangerous functions, nor additional gadgets, and that it also lacks — at the time of writing — an official patch for the 1.x branch, makes this incident a textbook case of software supply chain risk. Organizations must treat third-party dependency lifecycle management as a core component of their security posture, not as a secondary technical maintenance task.

References

Imperva. (2026, July 24). Imperva customers protected against CVE-2026-16723: Critical FastJson 1.x zero-day RCE. Imperva Blog. https://www.imperva.com/blog/imperva-customers-protected-against-cve-2026-16723-critical-fastjson-1-x-zero-day-rce/

The Hacker News. (2026, July 25). Fastjson 1.x RCE vulnerability targeted in attacks with no patch available. https://thehackernews.com/2026/07/fastjson-1x-rce-vulnerability-targeted.html

Security Boulevard. (2026, July 24). Imperva customers protected against CVE-2026-16723: Critical FastJson 1.x zero-day RCE. https://securityboulevard.com/2026/07/imperva-customers-protected-against-cve-2026-16723-critical-fastjson-1-x-zero-day-rce/

Son, D. (2026, July 22). Public PoC released for fastjson 1.2.83 RCE flaw. SecurityOnline. https://securityonline.info/fastjson-rce-1-2-83/

Alibaba. (2026, July 21). Security advisory: Remote code execution in fastjson 1.2.68–1.2.83 [Official security advisory]. GitHub. https://github.com/alibaba/fastjson2/wiki/Security-Advisory:-Remote-Code-Execution-in-fastjson-1.2.68–1.2.83