Alibaba's Fastjson is one of the most widely deployed JSON libraries in the Java world, prized for raw parsing speed. That speed came with a defining feature — autoType — that has also been its most persistent security liability. Over the years, autoType has been the source of a long line of deserialization vulnerabilities, and the library's maintainers have responded with an escalating series of defenses. CVE-2022-25845 is a landmark entry in that arms race: a bypass of the autoType protection itself, disclosed by researchers at JFrog, that reopened the door to remote code execution in applications that parse untrusted JSON.
Vulnerability identity and severity
CVE-2022-25845 is a deserialization-of-untrusted-data flaw in com.alibaba:fastjson before 1.2.83 (in practice, affecting 1.2.80 and earlier). It carries a CVSS 3.x base score of 8.1 (High). The vulnerability lets an attacker bypass Fastjson's autoType shutdown restrictions, and where a suitable gadget class is available, achieve remote code execution against any Java application that passes attacker-controlled data to JSON.parse or JSON.parseObject without specifying a concrete target class.
Timeline and impact
- May 23, 2022 — Fastjson 1.2.83 is released, addressing the security issue.
- June 2022 — JFrog publishes its analysis of the "AutoType bypass," and coverage spreads across the security press given how ubiquitous Fastjson is.
The blast radius is large because of how the library is used. Any endpoint, message consumer, or cache layer that feeds externally sourced JSON into Fastjson's generic parse methods — a very common pattern — is a candidate entry point. When the runtime also carries a class that can be abused as a gadget, the result is unauthenticated remote code execution.
Root cause: autoType and its bypass
autoType is Fastjson's mechanism for polymorphic deserialization. When a JSON document includes a special @type field, Fastjson reads the class name it contains and instantiates that class, populating its fields from the JSON. This is convenient for round-tripping typed objects, but it hands an attacker a primitive: name a dangerous class, control its properties, and trigger side effects during construction or setter invocation.
Because arbitrary type instantiation is so risky, Fastjson disables autoType by default and guards it with a checkAutoType() routine that maintains a list of denied class-name hashes and expected-type checks. CVE-2022-25845 is a bypass of that check — a crafted input that slips past the validation logic and reaches the dangerous instantiation path despite autoType's protections being in place. The 1.2.83 fix strengthened checkAutoType(), expanding the set of blocked class hashes and tightening how classes derived from certain base types are handled. The conceptual shape of an autoType payload looks like this (safe illustration, not a working exploit):
{
"@type": "com.example.SomeDangerousClass",
"propertyThatTriggersASideEffect": "attacker-controlled-value"
}
The pattern is nearly identical to the jackson-databind gadget problem: an attacker who can choose the class being deserialized turns "parse this JSON" into "construct this object of my choosing." As with any blocklist-based defense, each patch closes the specific bypass that was found — which is why the durable protection is safeMode, discussed below, rather than trusting the deny list to be complete.
Detection
- Grep for generic parse calls. Search for
JSON.parse(andJSON.parseObject(invocations that receive external input without a fixed targetClassargument. Those are the exploitable entry points. - Enumerate Fastjson versions. In
mvn dependency:treeorgradle dependencies, flag anycom.alibaba:fastjsonresolving to 1.2.80 or earlier. - Check whether autoType or safeMode is configured. Look for
ParserConfigusage in your codebase; the absence of any safeMode setting means you are relying entirely on the built-in deny list. - Trace data flow from network boundaries — controllers, queue consumers, webhooks — into Fastjson parse calls.
Remediation and patched versions
- Upgrade to Fastjson 1.2.83 or later at minimum. This closes the specific bypass.
- Enable safeMode, which disables autoType entirely and is the strongest durable mitigation. You can turn it on in any of three ways:
// In code ParserConfig.getGlobalInstance().setSafeMode(true); // As a JVM startup flag -Dfastjson.parser.safeMode=true // Via the fastjson.properties file fastjson.parser.safeMode=true - Always deserialize to a known concrete type where possible — pass the expected
ClasstoparseObjectso autoType is never consulted. - Consider migrating to Fastjson 2 or to a library whose default posture does not include type-directed instantiation, if your architecture allows it.
- Re-verify after upgrading that no transitive dependency pulls an older Fastjson back into the build.
How Safeguard helps
Fastjson autoType bypasses are a recurring pattern, not a one-time event, which makes continuous inventory and configuration awareness the real defense. Safeguard's software composition analysis tracks every Fastjson version across your repositories, container images, and transitive dependency trees, so a service still pinned to 1.2.80 is flagged the moment CVE-2022-25845 applies — and again when the next bypass lands. Griffin AI inspects the code itself, surfacing the JSON.parseObject entry points that take untrusted input and the absence of safeMode, so you fix the reachable, unprotected parsers first instead of triaging by version alone. Auto-fix remediation drafts the version bump and safe-configuration change as a reviewable pull request, cutting the time between "we know" and "it's fixed." To see how this compares to a single-vendor scanner, read Safeguard versus Snyk.
The autoType story teaches the same lesson as every deserialization CVE: never let untrusted input choose which class you build. Turn on safeMode, pin to a fixed type, and keep watching. Create a free Safeguard account or read the documentation to find your Fastjson exposure.