FastJSON Broke Again. Why?

EnnEmmEss1 pts0 comments

FastJSON Broke Again. Why? · Vonng&darr;<br>Skip to main content

Vonng

Vonng

Table of Contents<br>Table of Contents

On July 21, Alibaba published a FastJSON security advisory for CVE-2026-16723, rated 9.0 by its CNA and affecting versions 1.2.68 through 1.2.83.<br>The advisory explained the flaw, its trigger conditions, and why a specified target type was not necessarily safe. It also said fastjson2 was unaffected: no equivalent resource-probing path, an allowlist-first design, and the now-deprecated AutoType disabled. Its users needed to take no action for this CVE.

Six days later, a separate AutoType bypass in fastjson2 became public. On July 29, the project released 2.0.63, adding checks on type names, verification after allowlist hash matches, and stricter rules for dangerous base classes.<br>The advisory was not false: the bugs had different causes, and fastjson2 remains unaffected by CVE-2026-16723. But it felt like proving a new building could not burn through the old one&rsquo;s chimney, only to see its electrical panel catch fire six days later. Different cause, same headline.

Since 2019, the pattern spans seven years, three vulnerabilities, and two implementations. How can a JSON parser still produce RCEs after a decade? The answer is neither JSON nor simply “Alibaba writes bad software.” It is a style I will call ship rough, scale hard, move fast : release the incomplete design, entrench it through scale, and book today&rsquo;s gains while deferring the risk. The Chinese phrase 糙猛快 compresses those instincts into three characters.<br>Too Long; Didn&rsquo;t Read<br>Letting external data choose a class was a mistake shared by Java&rsquo;s native serialization, Jackson, FastJSON, and .NET&rsquo;s BinaryFormatter.

The difference is the exit: Jackson replaced its entry point; Microsoft removed the implementation; Java added filters; FastJSON built SafeMode but left it off by default.

Different bugs can still reveal the same broken security boundary, even across a rewrite.

“Ship rough, scale hard, move fast” is an accounting system: record benefits now and defer risk. A successful shortcut becomes doctrine.

AI adds leverage and removes the old speed limit: humans writing code.

1. This Is Not JSON. It Is Control.<br>Consider what AutoType does when it sees this input:<br>{"@type": "com.foo.Bar"}

The program loads com.foo.Bar, creates an instance, and fills it from the input. This restores polymorphic object trees without callers mapping every type. But ordinary deserialization asks how values fill an object; AutoType asks which object the program should create. It moves input from the data plane into the control plane. With untrusted JSON, a stranger helps decide which code your program loads.

Alibaba did not invent this mistake. Java&rsquo;s ObjectInputStream already let a stream choose object types; JDK 9 added filters in JEP 290, and Java 17 added context-specific policies in JEP 415. Jackson&rsquo;s polymorphic deserialization and .NET&rsquo;s BinaryFormatter had the same problem.<br>What distinguished FastJSON was how far it pushed convenience and speed. In a 2019 interview, author Shaojin Wen named high performance and ease of use as its first two advantages. “Ship rough, scale hard, move fast” enters through such respectable choices: make the API effortless, win benchmarks, preserve compatibility, add another check, postpone the exit. Each can be reasonable alone. The combined ten-year bill is not.<br>2. One Mistake, Four Responses<br>The industry made the same mistake. What matters is what happened next.<br>Jackson: Replace the Entry Point<br>Early Jackson releases also played denylist whack-a-mole. Jackson 2.10, released in 2019, introduced PolymorphicTypeValidator and began deprecating the old default-typing APIs. Rules may match a base class, package, or custom predicate, but callers must explicitly define them: if input helps choose a type, the application must say which types are eligible.<br>Java: Lock the Explosives Cabinet<br>JEP 290 provides process-wide and per-stream filters for allowed classes, object depth, references, and array size; JEP 415 selects filters by context. The capability remains, so someone must configure and maintain the lock.<br>Microsoft: Remove the Implementation<br>Microsoft retired BinaryFormatter explicitly: .NET 5 marked it obsolete; .NET 7 turned calls into compile-time errors; .NET 8 disabled it at runtime for most projects; and .NET 9 removed the implementation. A separate unsupported package preserves the old behavior—and its risks. The migration guide says, in effect: you may continue, but the platform will not call it safe.<br>FastJSON: Leave a Switch<br>FastJSON had a real solution too. Version 1.2.68 introduced SafeMode, which rejects every AutoType request; SafeMode=true blocks CVE-2026-16723 before its vulnerable path. But affected releases shipped with both AutoType and SafeMode off. The first setting suggested the dangerous feature was disabled; only the second guaranteed its type-resolution...

fastjson rsquo type autotype jackson java

Related Articles