The Fastjson 2.x line has a critical flaw of its own. NSFOCUS CERT reports that an unauthenticated attacker can send specially crafted JSON to a vulnerable application and get code running on the server, with a severity rating of 9.8 out of 10. Every release up to and including 2.0.62 is affected, and the technical details are already circulating publicly.
Fastjson is Alibaba's open source JSON library for Java. It is fast, it is free, and it is embedded in an enormous number of Java applications and services, which is exactly why bugs in it matter well beyond the teams that chose it deliberately. Plenty of organizations are running it as a transitive dependency they never picked.
How the flaw works
JSON normally carries plain data. Fastjson has long supported a feature called autoType, where a JSON document can name the Java class it should be converted into using an @type field. That is convenient for developers and dangerous in the wrong hands, because an attacker who controls which class gets built can steer the application into constructing something harmful. Fastjson's answer has been to keep autoType switched off by default and to police class names with a built in whitelist.
According to NSFOCUS, that is where this goes wrong. Fastjson 2.x may still process @type through the built in whitelist even when the autoType support flag has not been enabled, which is the configuration most deployments assume is safe. The notice adds a detail that raises the stakes: exploitation does not require any third party dangerous classes to be present on the target. In other words, the usual reassurance that an application is safe because it does not ship a known exploitable library does not apply here.
What to do
Upgrade past 2.0.62. Alibaba has published a fix, and any release after that version is unaffected. To find out what you are running, check for a fastjson JAR in the project directory, inspect pom.xml on Maven builds, or look at the loaded libraries on a running host.
Where an immediate upgrade is not realistic, NSFOCUS points to Fastjson's safeMode, which disables autoType outright regardless of whitelist or blacklist rather than trying to filter class names. As a stopgap at the network edge, web application firewall rules can look for the @type key in incoming JSON, but the notice is explicit that the rules must inspect the request body and not just URL parameters, and that encoding based bypasses need to be accounted for. Treat that as buying time, not as a fix.
This is the second serious Fastjson problem in a month. In late July we covered an autoType bypass in the older 1.2.x line that attackers were already exploiting. NSFOCUS does not report exploitation of the 2.x issue yet, but the pattern from previous Fastjson deserialization bugs is that public technical detail is followed quickly by opportunistic internet wide scanning, so the gap between disclosure and attack is usually short. Teams that patched the 1.x flaw and assumed the newer major version left them clear should check again.
The advisory is available in the original NSFOCUS CERT notice, which links the upstream issue and patch on the Fastjson project.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.