Alibaba fastjson deserialization RCE (CVE-2022-25845)

In May 2022, Alibaba's fastjson project quietly shipped version 1.2.83 with a fix that would soon be tracked as CVE-2022-25845 — a critical deserialization vulnerability that lets an unauthenticated attacker achieve remote code execution against any Java application that hands untrusted JSON to fastjson's JSON.parse() or JSON.parseObject() without pinning a target class. Fastjson is one of the most widely embedded JSON libraries in the Java ecosystem, shipped inside countless Spring Boot services, e-commerce platforms, and internal microservices across enterprises that have never audited it directly because it arrived as a transitive dependency. That ubiquity, combined with a network-exploitable, no-authentication, no-user-interaction attack path, is what pushed this bug to a CVSS 3.1 base score of 9.8 (Critical) under the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and an EPSS score hovering near 0.89 — placing it above the 99th percentile of all scored CVEs for predicted exploitation likelihood. If fastjson is anywhere in your dependency tree, this is not a theoretical finding to triage later.

What's actually broken

Fastjson has a long, well-documented history of "AutoType" bypasses. AutoType is a feature that lets a JSON payload specify the concrete Java class to deserialize into via a @type field — convenient for polymorphic APIs, and a gift to attackers, because it lets them instruct the parser to instantiate arbitrary classes on the classpath. Alibaba's response over several years has been to disable AutoType by default and layer in a denylist of dangerous class names, checked through ParserConfig.checkAutoType().

CVE-2022-25845 is a bypass of that denylist enforcement. The flaw lives in how ParserConfig.getDeserializer() routes classes that extend Throwable. Exception-derived classes are handed off to ThrowableDeserializer, a code path that was written under the assumption that exceptions are inert data objects — so it skips the standard blacklist checks and happily populates fields via constructor arguments and setter methods based on attacker-controlled JSON. In effect, any class on the classpath that extends Exception or Throwable becomes a viable deserialization target regardless of AutoType being "off."

That alone doesn't guarantee code execution — an attacker still needs a "gadget": an exception subclass, reachable on the target's classpath, whose constructor or setters trigger dangerous behavior (file writes, JNDI lookups, reflection, script engine invocation, etc.). Finding a usable gadget on a given application's classpath takes some research, which is why public write-ups describe the vulnerability as requiring "specific conditions" — but gadget chains for popular libraries (Groovy, MyBatis, various logging and templating frameworks) circulate quickly once a bypass like this goes public, and this is precisely the kind of flaw where exploit reliability improves fast after disclosure.

Affected versions and components

• Component: com.alibaba:fastjson (Maven Central), the standalone fastjson 1.x library.
• Affected releases: All fastjson 1.2.80 and earlier that have AutoType disabled by default (the standard, "safe" configuration most teams believe protects them).
• Fixed in: 1.2.83, released May 23, 2022.
• Exploitation prerequisite: The application must call JSON.parse() or JSON.parseObject() on attacker-influenced input without specifying an explicit target class (i.e., relying on fastjson to infer or accept a @type hint).
• Note on fastjson2: Alibaba's rewritten fastjson2 line uses a different AutoType/denylist implementation and is not affected by this specific bypass, but teams should not assume that migration alone closes every historical fastjson issue without separate verification.

Because fastjson ends up embedded transitively — pulled in by API gateways, Alibaba Cloud SDKs, internal RPC frameworks, and countless third-party JARs — many organizations running this vulnerable range don't have fastjson in their direct pom.xml or build.gradle at all, which is exactly the class of exposure that shows up in an SBOM scan but not in a manual dependency review.

Timeline

• ~2017–2021: A recurring pattern of fastjson AutoType bypasses is disclosed and patched (e.g., CVE-2017-18349, CVE-2020-35887 among others), each closing one bypass technique while the denylist model itself remains structurally fragile.
• May 23, 2022: Fastjson 1.2.83 is released, silently containing the fix for the Throwable-deserializer bypass.
• June 2022: CVE-2022-25845 is publicly assigned and disclosed; independent researchers (including JFrog's security research team) publish technical analyses of the bypass mechanism and its exploitation constraints shortly after.
• Ongoing: The CVE is not currently listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, but its EPSS score near the 99th percentile signals a high modeled probability of exploitation activity, consistent with fastjson's long track record as an active target for opportunistic and targeted scanning.

Remediation

1. Upgrade fastjson to 1.2.83 or later (or migrate to a currently maintained fastjson2 release) across every application and every transitive dependency that bundles it — not just services your team owns directly. Shading or version-pinning in a parent POM/BOM can help enforce this fleet-wide.
2. Enable Safe Mode if an immediate upgrade isn't feasible. Fastjson's ParserConfig.getGlobalInstance().setSafeMode(true) (or the equivalent JVM system property) disables @type-driven class instantiation entirely, which neutralizes this bypass and the broader AutoType attack surface, at the cost of breaking any legitimate polymorphic deserialization your application relies on.
3. Never deserialize untrusted input without a bound target class. Wherever feasible, replace generic JSON.parse(input) / JSON.parseObject(input) calls with JSON.parseObject(input, KnownClass.class), which removes the ambiguity attackers rely on.
4. Audit for exception-derived gadget classes on your classpath (custom Exception/Throwable subclasses with side-effecting constructors or setters), particularly from logging, templating, ORM, and RPC libraries — these are the raw material this bypass needs to turn into RCE.
5. Add outbound/egress monitoring and WAF rules as compensating controls: look for JSON payloads containing @type fields referencing exception classes, and restrict outbound connections from JSON-parsing services where unnecessary, since many practical fastjson RCE chains still route through JNDI or similar network callbacks.
6. Re-scan after remediation. Because fastjson so often arrives transitively, a fix applied to your direct dependency list can leave vulnerable copies bundled inside vendor SDKs or shaded JARs untouched — verify the fixed version is what actually loads at runtime, not just what's declared in your manifest.

How Safeguard Helps

Legacy scanners will flag fastjson < 1.2.83 in an SBOM and stop there, leaving your team to manually figure out whether the vulnerable ParserConfig/ThrowableDeserializer path is actually reachable from an internet-facing endpoint. Safeguard's reachability analysis traces whether your application's call graph actually invokes the vulnerable JSON.parse/JSON.parseObject code path with untrusted input, so you can separate the handful of genuinely exploitable services from the dozens of dependency alerts that pose no real risk. Griffin AI correlates that reachability signal with your deployment context — internet exposure, authentication boundaries, and blast radius — to prioritize CVE-2022-25845 findings the way an attacker would, not just by CVSS score. Safeguard's continuous SBOM generation and ingest surface every transitive copy of fastjson hiding inside vendor SDKs and shaded JARs, closing the exact blind spot that lets this vulnerability persist unnoticed. And when a fix is confirmed, Safeguard opens an auto-fix pull request bumping fastjson to a patched release (or enabling Safe Mode as an interim control), so remediation ships in minutes instead of sitting in a backlog.

Sources:

• CVE-2022-25845 - Fastjson RCE vulnerability analysis
• High-Severity RCE Vulnerability Reported in Popular Fastjson Library
• Deserialization of Untrusted Data in com.alibaba:fastjson | CVE-2022-25845 | Snyk
• Unsafe deserialization in com.alibaba:fastjson · CVE-2022-25845 · GitHub Advisory Database
• CVE-2022-25845 Detail - NVD
• CVE-2022-25845: Alibaba Fastjson Remote Code Execution Vulnerability - Sangfor