Fastjson 1.x Zero-Day RCE: No Patch, Active Exploitation

Key Takeaways

Security researcher Kirill Firsov of FearsOff Cybersecurity disclosed a critical, unauthenticated remote code execution vulnerability, now tracked as CVE-2026-16723 with an Alibaba-assigned CVSS score of 9.0, affecting every release of Fastjson from version 1.2.68 through 1.2.83, the final release of the 1.x line [1][3][4]. The flaw requires no classpath gadget and does not depend on the AutoType feature being enabled, instead abusing the @JSONType annotation as a false trust signal during type resolution to redirect Fastjson’s resource-lookup logic toward attacker-controlled bytecode packaged inside a Spring Boot executable fat-JAR [3][4]. ThreatBook confirmed active exploitation in production environments on July 22, 2026, one day after Alibaba’s advisory, and Imperva subsequently observed attack traffic against financial services, healthcare, computing, and retail organizations concentrated in the United States, with additional activity in Singapore and Canada [1][2]. As of July 25, 2026, Alibaba had not released a patched 1.x build, and the project’s development focus has shifted entirely to the architecturally distinct Fastjson2, meaning organizations still running Fastjson 1.x inside a fat-JAR deployment have no vendor fix to apply and must rely on configuration-level mitigation or migration [1][4]. The vulnerability had not yet appeared in the CISA Known Exploited Vulnerabilities catalog as of July 25, despite corroborated in-the-wild exploitation reported by two independent security vendors, illustrating the kind of enrichment and tracking lag that CSA’s prior research on AI-accelerated exploitation has identified as a structural weakness in vulnerability management [1][5].

Background

Fastjson is a JSON serialization and parsing library for Java, originally developed by Alibaba, that saw broad adoption in Chinese and global enterprise Java applications over the last decade. Its history has been shaped by a recurring pattern: the library’s AutoType feature, which allows a JSON payload to specify the Java class it should be deserialized into, has repeatedly proven exploitable for remote code execution when an attacker can control that class name and chain it to a gadget already present on the application’s classpath. CVE-2022-25845, patched in version 1.2.83 in May 2022, was among the most consequential of these prior AutoType bypasses, given its wide exploitation and the fact that 1.2.83 became the branch’s final release and is now the version bundled with the newly disclosed flaw [6]. In the years since, Alibaba redirected development effort to Fastjson2, a rewritten library with a different, allowlist-first architecture for polymorphic type handling, even though Fastjson 1.x, given its long tenure as a default choice for Spring Boot JSON handling, likely remains embedded in a meaningful number of production applications that have not completed migration to Fastjson2 [3][4].

Firsov’s disclosure, made responsibly to Alibaba before the July 21, 2026 public advisory, describes a technique that sidesteps the defenses organizations had come to rely on after the 2022 fix [3]. Rather than requiring AutoType to be explicitly enabled, or a dangerous gadget class already present on the classpath, the new technique exploits how Fastjson resolves types when it encounters a @JSONType annotation, treating the annotation’s presence as sufficient evidence that a referenced class is safe to load. Within a Spring Boot application packaged as an executable fat-JAR, a structure in which the application and all its dependencies are bundled into nested JAR files inside a single archive, an attacker can craft a JSON payload whose type reference points to a nested JAR path under their control, causing the JVM’s class-resource lookup to fetch and execute attacker-supplied bytecode [3][4]. The vulnerable code paths run through the library’s most commonly used entry points, JSON.parse(), JSON.parseObject(String), and JSON.parseObject(String, Class), which means any Spring Boot service that deserializes untrusted JSON through Fastjson without SafeMode enabled is potentially exposed regardless of whether developers believed they had disabled the risky AutoType behavior [2].

Security Analysis

What distinguishes CVE-2026-16723 from the library’s prior deserialization flaws is the combination of a gadget-free exploitation path with the complete absence of a vendor patch. Earlier Fastjson AutoType vulnerabilities, including CVE-2022-25845, could be closed by upgrading to a fixed release; this one cannot, because the flaw lives in the final release Alibaba shipped for the 1.x branch and no newer 1.x version exists to upgrade to [1][6]. The GitHub security advisory that accompanied the public disclosure confirms the technical root cause, describing a type-resolution path that performs a resource-probing call on a user-controlled class name, and notes that Fastjson2 eliminates the underlying weakness by removing that resource-probing behavior entirely in favor of an allowlist model [4]. The advisory frames its own remediation guidance around configuration workarounds, enabling SafeMode or adopting a restricted “noneautotype” build, rather than a patched artifact, which is itself an implicit acknowledgment that no code-level fix for the 1.x branch is forthcoming [4].

The exploitation conditions are narrower than a library-wide flaw would suggest, but they align closely with a common Java deployment pattern. The vulnerability requires Fastjson 1.2.68 through 1.2.83, packaging as a Spring Boot executable fat-JAR (compatible with Spring Boot 2.x, 3.x, and 4.x and with JDK 8, 11, 17, and 21), SafeMode left at its default disabled state, and a network-reachable endpoint that passes attacker-controlled JSON to one of the vulnerable parsing methods [1][2]. Plain non-fat JARs, generic uber-JARs built with different packaging tools, and applications deployed as WAR files inside Tomcat or Jetty fall outside the confirmed exploit path, since they lack the nested-JAR resource structure the attack depends on — though Imperva’s guidance recommends mitigating these packaging formats as well, since the absence of a confirmed exploit path is not the same as a proven-safe configuration [1][3]. That said, fat-JAR packaging is the default and most common distribution format for Spring Boot microservices, which means the population of exposed applications within organizations that have not inventoried their Fastjson usage is likely substantial and difficult to estimate without direct dependency analysis.

The gap between confirmed exploitation and formal vulnerability tracking is itself a notable feature of this incident. ThreatBook added detection signatures two days before confirming exploitation in the wild on July 22, 2026, and Imperva independently corroborated active attacks against production targets, observing that roughly seventy percent of attack traffic came from browser-impersonating tools and the remainder from Ruby and Go-based scanning utilities, with targeting concentrated in financial services, healthcare, computing, and retail sectors [1][2]. Despite this corroborated evidence from two independent vendors, CISA’s assessment as of July 23, 2026 characterized exploitation status as “none,” and the vulnerability had not been added to the CISA Known Exploited Vulnerabilities catalog as of July 25 [1]. This lag mirrors a broader dynamic CSA’s AI Safety Initiative research has documented elsewhere: as vulnerability discovery and early exploitation accelerate, the infrastructure that enterprises rely on for authoritative, timely confirmation of active exploitation increasingly trails the ground truth that commercial threat intelligence vendors are already observing [5]. Organizations that wait for KEV inclusion or an official patch before acting on this vulnerability will, in this case, be waiting for signals that may not arrive on a useful timeline.

Recommendations

Immediate Actions

Security and platform teams should inventory every Java application, including transitive dependencies, for Fastjson versions between 1.2.68 and 1.2.83, with particular attention to services packaged as Spring Boot executable fat-JARs and exposed to any network path, internal or external, that accepts JSON input. For every application confirmed to run an affected version in an affected packaging format, enable SafeMode immediately, either through the -Dfastjson.parser.safeMode=true JVM flag or programmatically via ParserConfig.getGlobalInstance().setSafeMode(true), since this is the fastest available control and requires no code changes beyond a configuration or startup-flag update [2][3]. Where SafeMode cannot be enabled without breaking legitimate polymorphic deserialization the application depends on, teams should adopt the restricted com.alibaba:fastjson:1.2.83_noneautotype build, which removes the AutoType code path at compile time, as an interim measure [1].

Short-Term Mitigations

Beyond the affected applications identified in the initial inventory, organizations should review logs across their Java estate for suspicious @type field values and jar:http or jar:file URL patterns in incoming JSON payloads, since these are the observable artifacts of attempted exploitation of this technique and may reveal probing activity against applications not yet confirmed as vulnerable [2]. Web application firewall rules and equivalent inline inspection controls should be updated to identify malicious JSON payloads carrying suspicious @type or @JSONType values and nested JAR URL patterns, following the detection logic vendors have already published for this specific technique [2]. Given that public proof-of-concept exploit code and defensive scanning tools for this vulnerability are already circulating, incident response teams should treat any confirmed exposure as a priority investigation and look specifically for unauthorized process execution, unexpected outbound connections, or webshell artifacts on systems that meet the vulnerable configuration profile [2][3].

Strategic Considerations

The absence of a vendor patch for Fastjson 1.x is not a temporary gap; it reflects Alibaba’s shift of development resources to Fastjson2, and organizations should treat this incident as the forcing function to complete a migration that, for many organizations still running Fastjson 1.x, has likely been deferred for years. Fastjson2 is not affected by this vulnerability class because its type-resolution architecture does not perform equivalent resource probing against user-controlled class names, and migrating removes the recurring AutoType-adjacent risk that has produced multiple critical CVEs against the 1.x line rather than closing a single instance of it [1][4]. More broadly, this incident is a useful case study in the limits of patch-centric vulnerability management: when a vendor has effectively end-of-lifed a component still in wide production use, security programs that measure their exposure purely by patch availability will systematically undercount their real risk, and should instead build dependency inventories granular enough to flag unmaintained components before those components become the subject of active exploitation.

CSA Resource Alignment

This incident is a direct, concrete illustration of the dynamic described in CSA’s AI-Accelerated Exploitation and Asymmetric Vulnerability Velocity, which documents patch debt as the growing population of known, unremediated vulnerabilities organizations carry forward because remediation capacity has become structurally insufficient relative to the pace of disclosure and exploitation [5]. That paper’s finding that exploitation increasingly begins before a fix exists, and that federal tracking infrastructure such as the CISA KEV catalog lags corroborated vendor telemetry, describes precisely the sequence observed here: ThreatBook and Imperva confirmed active exploitation days before CISA’s own assessment caught up, and no patch has been issued at all [1][5]. CVE-2026-16723 differs from the exploitation-velocity cases that paper primarily examines in one important respect, in that there is no patch race to lose; the vendor has already ended active maintenance of the affected line, making this less a story of remediation lagging disclosure and more one of remediation infrastructure never arriving.

CSA’s “AI Vulnerability Storm”: Building a Mythos-Ready Security Program is similarly relevant for its treatment of the structural strain AI-accelerated discovery and exploitation are placing on enterprise vulnerability management, including its argument that organizations will increasingly be overwhelmed by patching demands that legacy processes cannot absorb [7]. While Fastjson’s vulnerability was found through traditional manual security research rather than AI-assisted discovery, the operational consequence, an unauthenticated, low-complexity RCE in a widely deployed component with no vendor remediation path, is exactly the category of finding that paper argues security teams must be prepared to triage and contain without waiting for an upstream fix. Finally, CSA’s AI Controls Matrix (AICM v1.1), including domains addressing threat and vulnerability management and application and interface security, provides the governing framework for the dependency-inventory, configuration-hardening, and monitoring controls this note recommends, and organizations formalizing their response to unmaintained-component risk more broadly should anchor that work in AICM’s control structure rather than treating each unpatched library as an isolated incident [8].

References

[1] Ravie Lakshmanan. “Fastjson 1.x RCE Vulnerability Targeted in Attacks With No Patched Available.” The Hacker News, July 25, 2026.

[2] Imperva. “Imperva Customers Protected Against CVE-2026-16723: Critical FastJson 1.x Zero-Day RCE.” Imperva Blog, July 2026.

[3] Latest Hacking News. “How the Fastjson RCE Vulnerability Actually Works, and How to Check You’re Exposed.” Latest Hacking News, July 26, 2026.

[4] Alibaba/Fastjson2 Project. “Security Advisory: Remote Code Execution in fastjson 1.2.68–1.2.83.” GitHub, July 21, 2026.

[5] Cloud Security Alliance. “AI-Accelerated Exploitation and Asymmetric Vulnerability Velocity.” CSA AI Safety Initiative, May 30, 2026.

[6] The Hacker News. “High-Severity RCE Vulnerability Reported in Popular Fastjson Library.” The Hacker News, June 2022.

[7] Cloud Security Alliance. “‘AI Vulnerability Storm’: Building a ‘Mythos-Ready’ Security Program.” CSA AI Safety Initiative, 2026.

[8] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” Cloud Security Alliance, 2026.