Fastjson 1.x Hit by New Gadget-Free RCE, Default Configs Exposed
Fastjson has recently exposed another serious security vulnerability:
It's still a critical severity level. Fastjson just can't seem to stop having vulnerabilities... Fastjson is Alibaba's open-source, high-performance Java JSON serialization/deserialization library, widely used for converting between Java objects and JSON. The Fastjson 1.x branch was discontinued in 2024, and the latest version is 2.0.64.
The problem this time mainly lies in Fastjson's deserialization mechanism.
Simply put, if a project uses the default configuration without enabling SafeMode, and an attacker can control the JSON data passed to Fastjson, they can craft malicious content that exploits Fastjson's own deserialization logic to ultimately execute arbitrary code.
What's more troublesome is that this vulnerability is different from previous ones.
Many past Fastjson vulnerabilities required specific gadget classes, so deleting or disabling those dangerous classes could provide some protection.
But this time it's a "gadget-free" exploitation method, meaning it doesn't need those specific classes to complete the attack.
So the old approach of mitigating risk by deleting dangerous classes is basically useless here.
Affected Versions
| Condition | Description |
|---|---|
| fastjson version | 1.2.68 – 1.2.83 |
| Configuration | AutoType OFF + SafeMode OFF (i.e., default configuration) |
| Deployment method | Spring Boot executable fat-jar |
| JDK | 8 / 11 / 17 / 21 all verified |
| Spring Boot | 2.x / 3.x / 4.x all verified |
| Entry point | JSON.parse, JSON.parseObject(String), JSON.parseObject(String, Class) all reachable |
The main impact is on Spring Boot executable fat-jar deployments. Spring Boot projects should check themselves immediately.
Fastjson 2.x default configuration is not affected; fastjson2 has architecturally avoided this vulnerability.
Fastjson 2.x no longer performs resource probing via user-controllable class names, nor does it bypass type checking through the @JSONType annotation. At the same time, type resolution uses a whitelist-first mechanism, allowing only explicitly permitted types.
Additionally, fastjson2 disables autoType by default, and SupportAutoType has been deprecated and marked with a security risk.
Remediation Suggestions
For Fastjson 1.x, it is recommended to prioritize upgrading to 1.2.84. If an immediate upgrade is not possible, you can also enable SafeMode or switch to the noneautotype version.
In the long term, it is more recommended to migrate directly to fastjson2. Fastjson2 has architecturally avoided this vulnerability, and its default configuration is more secure.
However, for fastjson2, also note:
- Do not explicitly enable the deprecated
SupportAutoType; - If autoType is truly needed, use
ContextAutoTypeBeforeHandlerto configure a strict whitelist.
So, if you can upgrade Fastjson 1.x, upgrade to 1.2.84. It's best to migrate to fastjson2, which is not affected by this vulnerability by default.
Fortunately, Spring Boot uses Jackson as its default JSON serialization and deserialization framework and does not depend on Fastjson. I personally don't use Fastjson either, otherwise there would be endless vulnerabilities to fix.
If your Spring Boot project uses Fastjson, check and upgrade immediately.