Fastjson RCE: Spring Boot Dependency Check for SMBs

CVE-2026-16723 affects Fastjson 1.2.68 through 1.2.83 under documented conditions. Inventory transitive dependencies, upgrade or remove the library, and distinguish reported exploitation from KEV status.

Back to Blog
(Updated )
2 min read
Conceptual illustration of a Java application archive with a deeply nested dependency glowing as the weak link

CVE-2026-16723 affects Alibaba Fastjson 1.x versions 1.2.68 through 1.2.83 when applications use the affected default behavior. Alibaba says SafeMode and the noneautotype build are not affected, and Fastjson2 is not affected by this CVE. That does not establish that every Fastjson2 release is free of every security issue.

Current as of 2026-08-15

Alibaba’s advisory is the primary vendor source. NVD records CVSS 9.0 and currently does not mark the CVE as CISA KEV. Reports of exploitation should be attributed to the researchers that observed them.

Decision summary

  • Search application and transitive dependency inventories for Fastjson 1.x.
  • Confirm version, build, SafeMode, and actual deserialization path before stating exposure.
  • Upgrade or remove the affected library following vendor guidance.
  • Do not present researcher-reported activity as CISA- or vendor-confirmed exploitation.

Find the dependency accurately

  • Inspect Maven and Gradle dependency trees and lock files.
  • Scan built JARs, fat JARs, containers, and deployed artifacts.
  • Record the resolved version, not only the declared top-level dependency.
  • Identify code paths accepting untrusted JSON and the configuration used.
  • Check vendor applications that may embed the library.

Interpret affected conditions

The vendor’s published range is 1.2.68 through 1.2.83. SafeMode and noneautotype are not affected by this issue. Exposure still depends on the application path and input. Do not treat a package-name match alone as proof of successful exploitation.

Remediate and test

  1. Create a reproducible dependency inventory.
  2. Upgrade or migrate according to Alibaba’s guidance.
  3. Rebuild the complete artifact and rescan it.
  4. Run application, serialization, integration, and security tests.
  5. Deploy through normal change control with rollback.
  6. Verify the deployed artifact no longer contains the affected version.

Investigate reported exploitation carefully

If named security vendors report exploitation, cite the vendor, observation period, geography, and limitations. Preserve application, WAF, JVM, container, endpoint, and network evidence when suspicious deserialization behavior appears.

For related guidance from ITECS, see ITECS cybersecurity services.

Sources and update trigger

Review trigger: Recheck Alibaba, NVD, CISA KEV, and deployed dependency evidence before every remediation decision.

continue reading

More ITECS blog articles

Browse all articles

About ITECS Team

The ITECS team consists of experienced IT professionals dedicated to delivering enterprise-grade technology solutions and insights to businesses in Dallas and beyond.

View full profile and articles

Share This Article

Continue Reading

Explore more insights and technology trends from ITECS

View All Articles