Fastjson 1.2.83 “Gadget-Free” RCE — What It Means and How to Defend

1. Background: what did Fastjson 1.2.83 actually fix?

Fastjson is one of the most widely deployed JSON libraries in the Chinese Java ecosystem. Since 1.2.24, the 1.x branch has co-existed with a long trail of autoType deserialization issues. 1.2.83 (released August 2022) is the final major 1.x hardening; it did three things:

• Extended the internal autoType deny-list to cover historical JNDI, JDBC, template-engine and RMI class prefixes;
• Strengthened checkAutoType against name obfuscation (case tricks, L...; array notation, inner-class $, etc.);
• Officially recommended enabling safeMode, which fully disables autoType and only allows the declared static types.

The official stance for 1.2.83 users is unambiguous: if you must stay on 1.x, enable safeMode; if safeMode is not viable, migrate to Fastjson2 as soon as possible.

2. What does “gadget-free” actually mean?

Classical Java deserialization RCE rides on a gadget chain: the attacker stitches together side-effectful method calls from classes already present on the classpath, ending in command execution (think CommonsCollections, Groovy, ROME). The 1.2.83 deny-list was built around exactly these historical chains.

“Gadget-free” does not literally mean “no third-party class involved”. It means not depending on a historically known, signature-visible chain. It shifts the attack surface from “which chain is still un-blacklisted” to:

• Semantic primitives implicitly triggered by Fastjson's parsing (getter/setter invocations, constructor side effects, dynamic-proxy callbacks);
• The trust funnel where expectClass and autoTypeSupport interact;
• Classes present in the JDK or common frameworks that are not part of any CommonsCollections-style chain — resource loading, class loading, proxy injection, and similar semantics.

The core insight: instead of head-butting the deny-list, researchers hunt the tiny set of semantics Fastjson must trust (for example the code paths reached via expectClass), and disguise the payload as a legitimate input of that semantic.

3. Who is actually exposed?

Not every 1.2.83 deployment is equally dangerous. From highest to lowest risk:

1. High: internet-facing APIs / gateways that pass request bodies directly into JSON.parseObject(String) or lenient parses (e.g. Feature.SupportNonPublicField), without safeMode.
2. Medium: internal service-to-service JSON traffic (MQ / RPC bridges) on 1.2.83 without safeMode, but shielded by network ACLs.
3. Low: serialisation-only usage, or parsing strictly-typed POJOs with safeMode=true enabled.
4. Effectively N/A: already migrated to Fastjson2 (com.alibaba.fastjson2) 2.0.x or newer, where autoType is off by default.

4. Detection: find out what you actually run

Enterprise dependency graphs are messy. Do the four checks in order:

1. Dependency scan: run mvn dependency:tree / gradle dependencies across every Java service; capture the resolved com.alibaba:fastjson version.
2. Runtime confirmation: read the Implementation-Version in the JAR containing com.alibaba.fastjson.JSON. This catches transitive pulls that don't surface in dependency:tree.
3. Config inventory: search JVM args / env vars for -Dfastjson.parser.safeMode=true, or code for ParserConfig.getGlobalInstance().setSafeMode(true).
4. Entry-point audit: grep every call site of JSON.parse, parseObject, parseArray; flag any that ingest external input.

5. Enterprise fix plan (by priority)

P0 (this week): shrink the surface immediately

• For every 1.2.83 service, force safeMode=true. No code change needed — a JVM flag is enough; it is the official recommendation for 1.x.
• If autoType is truly required, replace it with an explicit allow-list: ParserConfig.getGlobalInstance().addAccept("your.package.prefix."). Narrow autoType to known business types only.
• Add a WAF / gateway rule: for application/json bodies, reject or alert on "@type" as a top-level key. If real polymorphism is needed, resolve it server-side rather than trusting the client.

P1 (this quarter): migrate to Fastjson2

Fastjson2 is the official successor. Package renamed to com.alibaba.fastjson2, autoType off by default, tighter type resolution. Suggested playbook:

• Bring in the fastjson2-extension shim first; migrate APIs incrementally under feature-flag / canary.
• Watch behaviour differences of parseObject(String, TypeReference); audit any legacy code that used @type for polymorphic deserialization.
• After migration, if autoType is still needed, use Fastjson2's JSONReader.Feature.SupportAutoType with an allow-list — never enable a global autoType.

P2 (this half): defense in depth

• Network: enforce egress control. Production hosts should not initiate outbound LDAP / RMI / arbitrary DNS. This is the single choke-point that turns "second-stage payload" attacks into inert traffic.
• Runtime: deploy Java RASP (OpenRASP or a commercial equivalent). Hook ClassLoader.defineClass, ScriptEngine.eval, Runtime.exec.
• Data: analyse the last 6 months of traffic for "@type" frequency. Most teams discover that zero business endpoints actually need polymorphic deserialisation.

6. Common misconceptions

1. "WAF alone is enough." WAF filters known-signature payloads; gadget-free research is designed to evade signatures. Defense in depth is not optional.
2. "Internal networks are safe." Deserialization flaws frequently surface in internal RPC, MQ bridges, and data-sync jobs. One compromised node can pivot straight into production.
3. "1.2.83 is the finish line." 1.2.83 is a stop-the-bleed version, not an end state. The end state is Fastjson2 + safeMode + minimal autoType allow-list.
4. "safeMode will break everything." In practice 90%+ parse paths don't rely on autoType. Run safeMode in staging for a week, collect the autoTypeSupport is disabled errors, then allow-list the true positives.

Halocent field view: across 100+ customer asset reviews, we find that fewer than 25% of Fastjson 1.x deployments actually have safeMode enabled. A single day of "flip the switch" work would immediately erase most of the Java RCE surface in Chinese enterprises.

7. Copy-paste action checklist

1. This week: inventory every Java service's Fastjson version + safeMode status.
2. This week: add -Dfastjson.parser.safeMode=true to the startup template of every 1.x service.
3. Within 2 weeks: ship a WAF rule that blocks top-level "@type". Run in audit mode for 7 days first.
4. Within 1 month: block outbound LDAP / RMI / unapproved risky egress from production.
5. This quarter: publish a Fastjson2 migration plan with milestones and owners.
6. This half: land a RASP / EDR combo and run a Java-deserialisation-focused red-team drill.

If you'd like this checklist mapped onto your actual assets, Halocent can produce a Fastjson Exposure & Remediation Priority report using our automated scanner — typical turnaround is 3–5 business days.

← Back to News & Insights