Your Spring Boot application uses Fastjson 1.x for JSON parsing. Threat actors are exploiting CVE-2026-16723 in the wild. The CVSS score is 9.0. As of July 25, Alibaba hasn't released a patched version.
What do you do?
This isn't a theoretical exercise. It's the exact situation security teams faced when ThreatBook reported active exploitation of this remote code execution vulnerability. No patch. Active attacks. Production systems at risk.
What Happened
CVE-2026-16723 allows remote code execution in Fastjson 1.x when specific conditions align. The vulnerability requires the target application to use Spring Boot and have certain configuration settings. Alibaba, the library's maintainer, confirmed the issue but hasn't shipped a fix for the 1.x branch.
ThreatBook's detection indicates attackers are scanning for vulnerable endpoints and attempting exploitation. The vulnerability affects JSON deserialization, a common attack surface in web applications that process external input.
Timeline
- Pre-July 25: Vulnerability exists in production Fastjson 1.x deployments
- July 25: ThreatBook reports in-the-wild exploitation; CVE-2026-16723 assigned with CVSS 9.0
- Post-disclosure: No patch available for Fastjson 1.x; Alibaba recommends migration to Fastjson2 or enabling SafeMode
The compressed timeline between disclosure and exploitation left no buffer for gradual response. Teams had to make mitigation decisions immediately.
Which Controls Failed or Were Missing
Dependency inventory and risk assessment: Organizations didn't know which applications used Fastjson 1.x or couldn't quickly identify affected services. When a critical vulnerability drops, you need an answer in hours, not days.
Configuration hardening: Many deployments ran Fastjson with default settings. SafeMode, which restricts deserialization behavior, wasn't enabled. Even if the library has a vulnerability, restrictive configuration can limit exploitability.
Library lifecycle management: Teams lacked a documented process for handling end-of-life or unmaintained dependencies. Fastjson 1.x is effectively unsupported for security fixes, but applications continued using it without a migration plan.
Input validation at the application layer: Applications trusted Fastjson to safely handle all JSON input without implementing their own validation or filtering. Your deserialization library shouldn't be your only line of defense against malicious payloads.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that software development practices address security vulnerabilities throughout the application lifecycle. This includes tracking and managing third-party components. If you're processing payment data and can't identify which services use a vulnerable library, you're non-compliant.
OWASP ASVS v4.0.3 V14.2.3 requires applications to maintain an inventory of all components, including libraries and frameworks. The verification level demands you can produce this inventory during an assessment. "We think some apps use Fastjson" doesn't meet the standard.
NIST 800-53 Rev 5 control SA-22 addresses unsupported system components. It requires organizations to replace components that are no longer supported by developers or vendors. When Alibaba stopped patching Fastjson 1.x for security issues, the clock started on your replacement timeline.
ISO/IEC 27001:2022 Annex A.8.31 covers security requirements in development. Your secure development lifecycle must include procedures for evaluating and addressing vulnerabilities in dependencies, including scenarios where patches aren't available.
Lessons and Action Items
Build a complete dependency inventory today. Use tools like OWASP Dependency-Check, Snyk, or GitHub's dependency graph. For each service, document:
- Library name and version
- Where it's used (which applications, environments)
- Who owns the service
- Last security review date
Run this inventory weekly. When the next CVE drops, you need to know your exposure in under an hour.
Enable restrictive configurations by default. For Fastjson specifically, enable SafeMode in all deployments. More broadly, review every third-party library's security settings. Default configurations optimize for ease of use, not security. Your baseline should be the most restrictive setting that doesn't break functionality, then relax constraints only when necessary.
Document your library upgrade path. For each dependency, answer:
- What's the supported migration target? (For Fastjson 1.x, it's Fastjson2)
- What breaking changes will we face?
- What's our testing approach?
- How long will the migration take?
Don't wait for a vulnerability to force this analysis. If you're using Fastjson 1.x today, schedule the Fastjson2 migration now. If you're using any library that's more than two major versions behind, add it to your technical debt backlog with a target quarter.
Implement defense in depth for deserialization. Don't rely solely on your JSON library to reject malicious input. Add application-layer validation:
- Validate JSON structure against a schema before deserialization
- Restrict which classes can be instantiated during deserialization
- Log deserialization attempts for security monitoring
- Consider implementing a allowlist of acceptable input patterns
Create a no-patch playbook. The Fastjson situation won't be the last time you face a critical vulnerability with no immediate fix. Your incident response plan should include:
- Who decides whether to disable the vulnerable component?
- What's your rollback procedure?
- How do you communicate risk to business stakeholders?
- What temporary compensating controls can you implement?
For Fastjson specifically, your options were: migrate to Fastjson2 (breaking changes, testing required), enable SafeMode (immediate but may break some functionality), or remove Fastjson entirely (requires code changes). Each option has a different timeline and risk profile. Document this decision framework before the next incident.
Test your vulnerability response time. Run a tabletop exercise: "A critical RCE in [library] is being exploited. You have four hours to identify affected systems and implement mitigations." Can your team do it? If not, fix the gaps now.
The Fastjson incident demonstrates a fundamental truth: you can't patch your way out of every vulnerability. Sometimes the patch doesn't exist. Your security posture depends on how quickly you can identify exposure, assess options, and execute mitigation, even when the ideal solution isn't available.
