Fastjson CVE-2026-16723: Enable SafeMode on 1.x Now

Fastjson CVE-2026-16723 can allow unauthenticated remote code execution in a specific but common Spring Boot setup. The maintainer lists Fastjson 1.2.68 through 1.2.83 as affected when the application runs as an executable fat JAR, processes attacker-controlled JSON, and has SafeMode disabled—the stock default [1].

ThreatBook says its platform captured exploitation activity, while Imperva separately reported attack attempts against several industries. Those reports justify urgent triage, but they do not publish victim counts or prove that every observed request achieved code execution. The practical task is to verify the full exposure chain, enable SafeMode immediately, and move away from the unsupported 1.x branch.

Who Is Affected by CVE-2026-16723?

The maintainer verified the chain with Spring Boot 2.x, 3.x, and 4.x on JDK 8, 11, 17, and 21. Binding input to a named class is not a sufficient defense when that object contains an Object or Map field where a malicious value can be nested.

Why Turning AutoType Off Is Not Enough

Fastjson normally uses an @type field for polymorphic deserialization. In this chain, an attacker-controlled type value reaches a resource lookup inside a Spring Boot fat JAR. A crafted nested-JAR path can supply remote bytecode, and an @JSONType annotation can be treated as a trust signal. That combination bypasses the protection administrators expect from leaving AutoType disabled.

Fastjson2 does not use the same resource-probing and annotation-trust path. It follows an allowlist-first model, which is why the maintainer says all fastjson2 versions are outside the scope of CVE-2026-16723.

How to Check Exposure Without Running an Exploit

1. Inventory direct and transitive dependencies. Search the build and the deployed artifact, not only the top-level pom.xml. For Maven, mvn dependency:tree -Dincludes=com.alibaba:fastjson can reveal a transitive copy. For Gradle, inspect the runtime dependency report and lockfiles.
2. Confirm the running artifact. Check the container image, service command, and deployed JAR. A Spring Boot archive containing BOOT-INF/ and nested libraries deserves priority review.
3. Find the real parser entry points. Review calls to JSON.parse, JSON.parseObject(String), and JSON.parseObject(String, Class), then trace whether an unauthenticated or internet-facing request can reach them.
4. Verify SafeMode at runtime. Check JVM arguments, fastjson.properties, and application initialization. Do not assume a repository setting reached the production process.
5. Review evidence safely. Look for suspicious @type values, nested JAR URL patterns, unexpected outbound connections, Java child processes, new files, or web shells. Do not send a proof-of-concept request to production.

The dependency step matters because Java exposure is often inherited. Earlier Log4j package analysis showed how transitive dependencies keep vulnerable code in application graphs, while a separate Spring Framework vulnerability illustrates why the framework version and bundled libraries must be reviewed independently.

What to Do Now

1. Enable SafeMode immediately. Use the JVM option -Dfastjson.parser.safeMode=true, set fastjson.parser.safeMode=true in the properties file, or enable it through ParserConfig.getGlobalInstance().setSafeMode(true). Confirm the setting in the running service.
2. Use the restricted build if migration cannot start today. The maintainer lists com.alibaba:fastjson:1.2.83_noneautotype as an alternative because the vulnerable AutoType-related code is removed at compile time.
3. Plan and test migration to fastjson2. Treat SafeMode and WAF rules as temporary risk reduction, not a maintained 1.x patch. Test serialization behavior and package-name changes before production rollout.
4. Restrict reachability. Require authentication where possible, remove unnecessary public parser endpoints, and block suspicious @type plus nested-JAR URL patterns at the WAF or API gateway. Perimeter filtering is not a substitute for migration.
5. Investigate suspicious hosts. Preserve application, proxy, WAF, container, and egress logs. If the Java process spawned commands, fetched remote resources, wrote unexpected files, or exposed secrets, isolate the workload and rotate credentials after containment.

What the Exploitation Reports Prove—and Do Not Prove

ThreatBook says its detection platform captured in-the-wild exploitation and reproduced full RCE in a Spring Boot fat JAR on JDK 8. Its embedded Tomcat test produced a remote JAR fetch or SSRF rather than full code execution [2]. That difference reinforces the need to verify packaging and runtime conditions instead of treating every Fastjson installation as equivalent.

As of July 26, CVE-2026-16723 is not in CISA’s Known Exploited Vulnerabilities catalog. The NVD record shows a July 23 CISA-ADP assessment with exploitation marked none, which conflicts with the later vendor telemetry claims [3]. The safest interpretation is that exploit attempts have been observed, while public evidence of successful real-world compromise remains limited. Administrators should remediate exposure without describing unverified requests as confirmed breaches.

References

1. Alibaba Fastjson maintainers. “Security Advisory: Remote Code Execution in fastjson 1.2.68–1.2.83.” GitHub, July 21, 2026, accessed July 26, 2026. Official advisory.
2. ThreatBook Research Team. “Fastjson RCE (≤1.2.83): Active Exploitation Detected — Detection & Mitigation.” ThreatBook, July 22, 2026, accessed July 26, 2026. Research report.
3. National Institute of Standards and Technology. “CVE-2026-16723 Detail.” National Vulnerability Database, published July 23, 2026, accessed July 26, 2026. CVE record.