Fastjson 1.x Hit by New Gadget-Free RCE, Default Configs Exposed
Any Spring Boot service that swapped in Fastjson 1.x for JSON parsing is reachable with default settings. The gadget-free nature of the exploit means the usual stopgap—purging dangerous classes—provides no protection, so only a version upgrade or a move to Fastjson 2.x closes the hole.
Fastjson versions 1.2.68 to 1.2.83 contain a critical RCE that works under default configurations—AutoType off and SafeMode off—when an attacker controls the JSON input. Unlike earlier Fastjson flaws that relied on specific gadget classes on the classpath, this exploit is gadget-free, meaning deleting or blocking known dangerous classes no longer stops it. Spring Boot fat-jar deployments across JDK 8, 11, 17, and 21 are confirmed reachable through standard parse entry points.
Fastjson 2.x is immune by design. It refuses to probe resources using attacker-supplied class names, enforces a whitelist-first type resolution, and ships with autoType disabled. The deprecated SupportAutoType flag is explicitly flagged as unsafe.
The immediate fix for 1.x users is upgrading to 1.2.84 or enabling SafeMode. The recommended long-term path is migrating to fastjson2, which carries safer defaults and architectural protections against this class of attack.
Gadget-free deserialization attacks shift the threat model: the library itself becomes the attack surface, not the classpath. This makes version upgrades the only reliable fix.
Fastjson 1.x was officially discontinued in 2024, yet production exposure remains widespread enough that a critical advisory still triggers urgent patching campaigns.
The architectural gap between Fastjson 1.x and 2.x is stark—2.x's whitelist-first design and disabled autoType are table-stakes defenses that 1.x never adopted by default.