Fastjson CVE-2026-16723: RCE exploited in the wild

The critical CVE-2026-16723 vulnerability in Alibaba Fastjson 1.x is being exploited in real attacks. The most important message for Java teams is not merely “another RCE in a JSON parser.” The flaw can work with AutoType disabled, in a configuration many organisations treated as their baseline protection against Fastjson’s historical security issues.

According to Alibaba’s official advisory, versions 1.2.68–1.2.83 are vulnerable when an application runs as a Spring Boot executable fat JAR while both AutoType and SafeMode are disabled. Fastjson 2 is not affected. With ThreatBook reporting observed exploitation attempts, administrators should treat mitigation and compromise assessment as urgent work.

What is actually vulnerable

The vendor’s conditions are narrower than “all Fastjson 1.x,” but they occur in a very common Java deployment model. The at-risk configuration combines:

• Fastjson 1.2.68 through 1.2.83;
• Spring Boot packaged as an executable fat JAR;
• AutoType disabled;
• SafeMode disabled, which is the default;
• processing of JSON input an attacker can control.

Alibaba verified the vulnerability on JDK 8, 11, 17 and 21 and in applications built with Spring Boot 2, 3 and 4. It may be reachable through common methods including JSON.parse, JSON.parseObject(String) and JSON.parseObject(String, Class).

The last point matters operationally. Deserialising into an explicitly named DTO is not sufficient protection when the object contains generic fields such as Object, Map or nested structures that are resolved dynamically. The trust boundary covers the entire object graph, not just its top-level type.

Why disabling AutoType is not enough

Historically, many Fastjson attacks abused AutoType to name a class the parser should instantiate. Disabling the feature became the natural response. CVE-2026-16723 bypasses that assumption in the affected Spring Boot environment: the parser can reach a dangerous path while resolving types available inside the executable JAR structure.

This does not mean every Fastjson application instantly gives an attacker a shell. Exploitation still requires attacker-controlled JSON, a suitable class layout and the documented deployment conditions. Risk owners should not wait to confirm the exact path in every service, however. Active exploitation combined with remote code execution moves qualifying systems to the front of the queue.

What is outside this scenario

According to the vendor advisory, this specific variant does not affect:

• Fastjson 2;
• applications with SafeMode enabled globally;
• special Fastjson 1.x builds carrying the _noneautotype suffix;
• deployments that do not use a Spring Boot executable fat JAR;
• Fastjson 1.x versions outside the stated 1.2.68–1.2.83 range.

This is a list of conditions for CVE-2026-16723, not a general certificate of safety for the old branch. Fastjson 1.x is a legacy line with a history of deserialisation problems. Migration remains the long-term answer even when a current assessment shows that one instance does not meet every exploitation condition.

What to do today

1. Find the library you actually run

Search pom.xml, build.gradle, lockfiles, container images, SBOM manifests and built artefacts. Do not stop at direct dependencies: Fastjson may arrive transitively. Confirm the version inside the artefact deployed to production, because a repository declaration and the contents of a running JAR can differ.

2. Enable SafeMode as an emergency control

Alibaba recommends enabling SafeMode globally, including through this JVM property:

-Dfastjson.parser.safeMode=true

The library’s global configuration can also be used. Test the change because it may affect code that legitimately relied on dynamic type resolution. Do not set the flag in only one controller—the protection should cover every deserialisation path in the process.

3. Consider the noneautotype build

Where immediate migration is impossible, the vendor identifies com.alibaba:fastjson:1.2.83_noneautotype as an alternative artefact. It is a risk reduction measure for the old branch, not an architectural destination. Test application compatibility and make sure the ordinary legacy build does not remain in the image alongside it.

4. Plan a move to Fastjson 2

Fastjson 2 is not vulnerable to CVE-2026-16723 and has a redesigned security model. Migration needs compatibility, serialisation, date-format, custom converter and performance testing. It should nevertheless have an owner and a deadline rather than remaining an indefinite “after the incident” task.

5. Determine whether exploitation already occurred

Turning on a control does not remove the effects of an earlier intrusion. For public endpoints accepting JSON, investigate:

• unusual deserialisation exceptions and class-loading failures;
• child processes spawned by the JVM;
• new or modified files in application and temporary directories;
• unexpected outbound connections from the server;
• access to secrets, cloud tokens and configuration data after the earliest possible entry time.

If telemetry indicates code execution, isolate the host, preserve evidence, rotate secrets available to the process and follow a complete incident response plan. We do not reproduce the exploit payload or exploitation instructions—defenders do not need to test a production system with a weaponised request to prioritise the risk.

Reducing the next deserialisation risk

Deserialisation of untrusted data deserves its own threat model. Prefer precise DTOs without Object fields, validate a schema before mapping, restrict the classes available to the parser and treat serialisation libraries as high-risk components. CI can block known vulnerable versions using an SBOM, but dependency scanning must be connected to where the component runs and whether its endpoint is Internet-reachable.

This is a useful example of why CVSS alone should not determine priority. A mature vulnerability management process also weighs active exploitation, exposure, process privileges and the value of the data behind the application.

Frequently asked questions

Does disabling AutoType protect against CVE-2026-16723?
Not in the configuration documented by Alibaba. The flaw was confirmed with AutoType disabled. Enable SafeMode or use the specified noneautotype build, then plan the migration.

Is deserialising into a concrete class enough?
Do not assume so. Nested generic fields can reopen a dynamic path. Review the full data model and every endpoint that accepts untrusted JSON.

Must Fastjson 2 be updated because of this flaw?
Fastjson 2 is not affected by CVE-2026-16723. It should still be kept current and securely configured, but this advisory applies to Fastjson 1.x.

Is the issue closed once SafeMode is enabled?
No. SafeMode limits further exploitation but does not tell you whether an attacker entered earlier. Log review, threat hunting and a migration plan are still required for systems that meet the affected conditions.

Conclusion

CVE-2026-16723 breaks the comfortable assumption that disabling AutoType solves dangerous deserialisation in Fastjson 1.x. The sensible order is: inventory, immediately enable SafeMode or the noneautotype variant, look for attack evidence and migrate to Fastjson 2. If you need to confirm a Java application’s exposure or investigate suspected compromise, talk to the BreachRoad team.

---

Sources: Alibaba’s official Fastjson 1.x security advisory, ThreatBook on observed active exploitation, Imperva’s CVE-2026-16723 analysis.