Fastjson 1.x Has No Patch — Your JAR Inventory Is the Remediation
Three of the highest-priority findings share a property that breaks standard SLA math: the vendor is not shipping a fix, and every control that still works is one you configure yourself.
Why enumeration is the hard part
This bug is not the earlier Fastjson deserialization flaws. The difference is configuration scope. Prior issues in the library needed non-default settings, so many teams closed them with a one-line "autotype is disabled" determination. CVE-2026-16723 fires in the default configuration, and in the most common real-world packaging model, a Spring Boot executable component. Every service cleared on the old basis is uncleared again.
Spring Boot's executable-JAR packaging bundles dependencies inside the artifact. Inventories built from OS packages, container image manifests, or top-level build files do not see what is nested there. That is how a library frozen at 1.2.83 since May 2022 survives four years in production as a transitive dependency nobody re-declared. Risky Business puts it bluntly: Fastjson 1.x is still in nearly every bank and government network you know. Probably accurate.
The exploitation clock already ran
Attacks began within one day of FearsOff's public disclosure. Two independent telemetry providers, Imperva and ThreatBook, place live exploitation against US finance, healthcare, computing and retail. Two vendors observing the same activity across different customer bases is the strongest corroboration available before a national CERT weighs in. So any internet-facing Java service that parses JSON belongs in a compromise assessment, not a remediation queue. Assume dwell time back to the disclosure date, not to the day the ticket opened.
Three findings, one shared property
| Issue | Vendor position | What actually remediates it | Clock |
|---|---|---|---|
| Fastjson 1.x (CVE-2026-16723) | 1.x branch frozen; SafeMode or 2.x migration only | Dependency inventory, then config flag or version migration, with WAF/RASP in front | Exploited now |
| macOS executable replacement | Apple declines to treat it as a security issue | Application allow-listing, code-signing verification, file-integrity monitoring | Compensating controls only |
| Certighost (CVE-2026-54121) | Fixed in July 2026 Patch Tuesday | Proving deployment coverage on every domain controller | Public write-up exists |
The Certighost row is the useful contrast. It is the only one of the three where "patched" is a defensible answer upward, and even there the answer is a coverage number, not a bulletin link. A low-privilege AD account impersonating a domain controller is a full domain-trust break. The technique is now publicly documented.
The smart move
Sequence by speed, not by elegance: virtual patch first, inventory second, code change last. A WAF or RASP rule for Fastjson deserialization payloads is the only control you can place in front of every internet-facing Java service inside a day. SafeMode is a configuration change shippable in a normal release cycle. The 2.x migration is a code project that will outlive the current exploitation window. The migration debate should not stall the two faster controls. That is the failure mode that turns an unpatchable library into an incident.
There is no patch level to report on this one — only the count of Java services you have actually enumerated, and the control you put in front of them.
What to do
Deploy WAF/RASP virtual-patch rules and SOC detections for CVE-2026-16723 deserialization payloads on all internet-facing Java services immediately, before remediation work begins.
Run an SBOM and dependency scan across every Java and Spring Boot service this week, ranking internet-facing JSON-ingesting endpoints first, and record the Fastjson version per service.
Verify July 2026 Patch Tuesday reached 100% of domain controllers this sprint and report the coverage figure, not the patch status, to close Certighost.