A critical, unauthenticated remote code execution flaw in the FastJson Java library is being actively exploited against enterprise networks, with no vendor patch available. UK organisations running Spring Boot fat-JAR deployments should treat this as an urgent vulnerability management services priority, not a routine advisory to file away.
View the data behind this chart
| Phase | Starts (week) | Duration (weeks) |
|---|---|---|
| FearsOff discovers flaw and… | 0 | 2 |
| Alibaba confirms vulnerabili… | 2 | 1 |
| ThreatBook and Imperva… | 3 | 2 |
| No vendor fix available to… | 5 | 1 |
What's actually happening
Hackers are exploiting FastJson, Alibaba's widely used open-source Java serialisation library, to gain remote code execution without needing user interaction or elevated privileges. The flaw, tracked as CVE-2026-16723, affects FastJson versions 1.2.68 through 1.2.83 and was flagged last week by agentic security firm ThreatBook, with Imperva confirming exploitation across Financial Services, Healthcare, Computing, Retail, Business and other sectors.
Imperva describes the campaign as currently "almost entirely targeting US-based organizations, with a few attacks in Singapore and Canada," adding that this will likely expand globally. That geographic pattern is exactly how many enterprise Java zero-days start before spreading to wherever the vulnerable software sits exposed — and FastJson's popularity in Alibaba-platform-adjacent and general Java projects means UK exposure is a matter of when, not if scanning begins here.
Why Spring Boot fat-JAR deployments are the exposure point
The technical detail matters for prioritisation. FearsOff, the offensive security firm that discovered and published the flaw earlier this month, found that the vulnerability sits in FastJson's type-resolution logic, which performs attacker-controlled resource lookups before AutoType restrictions are enforced. This lets an attacker load and execute malicious classes via @type processing without needing AutoType enabled or any third-party gadget chain.
Alibaba's own security bulletin confirms critical severity and states the only deployment prerequisite is that the target runs as a Spring Boot executable fat-jar — launched via java -jar xxx.jar. Crucially, specifying a target class during deserialisation does not mitigate the flaw, since attackers can smuggle payloads inside Object or Map fields. This narrows the practical UK risk focus to fat-JAR packaged Spring Boot services rather than every Java application that happens to reference FastJson somewhere in its dependency tree.
No fix means the burden sits with your team
There is currently no fix issued for CVE-2026-16723. Imperva notes that FastJson 1.x is no longer actively maintained, making an upstream patch unlikely. Alibaba's guidance for developers on an affected build is to immediately enable SafeMode or migrate to a non-impacted build. Versions 1.2.60 and earlier, and any non-fat-JAR deployment model, are not affected — and fastjson2 avoids the flaw entirely because it uses an allowlist-first model for polymorphic deserialisation and doesn't treat the @JSONType annotation as a trust signal.
For UK infrastructure buyers, this is the uncomfortable part: with no vendor patch coming, standard understanding patch management assumptions about waiting for a fix don't apply. The remediation path is migration or configuration hardening, and it needs to happen against a live exploitation clock rather than a scheduled maintenance window.
The UK angle: audit before attackers do it for you
Attacks are described as US-focused today, but FastJson's heavy footprint in enterprise Java and Alibaba-ecosystem projects means UK organisations with outsourced development, Chinese supply-chain software components, or legacy Spring Boot services built years ago are realistic targets as scanning activity broadens. Given the flaw requires no authentication and works against a default configuration in the affected version range, exposed services are trivially discoverable by automated scanners the moment exploitation tooling circulates more widely.
This is a case for immediate software composition analysis across your Java estate: identify every fat-JAR deployment, confirm the exact FastJson version in use, and treat anything in the 1.2.68–1.2.83 range as a live incident candidate rather than a backlog ticket. Firms without in-house capacity to run that audit at pace should lean on our cybersecurity solutions or a specialist review through our full range of IT services.
Building resilience beyond the immediate patch
Because no fix exists yet, compensating controls matter more than usual. Network-layer detection for anomalous @type payloads, egress restrictions on services running affected FastJson builds, and tighter monitoring through managed detection & response can reduce dwell time if a compromise does occur. Organisations should also revisit incident response planning specifically for unauthenticated Java RCE scenarios, given how quickly this class of flaw has historically moved from disclosure to mass exploitation.
Longer term, this incident reinforces the case for architectural controls that don't depend on any single library being patched in time. Segmenting internet-facing Java services, applying zero trust principles to internal service-to-service calls, and layering ransomware protection around business-critical Java platforms all reduce the blast radius when the next unpatched deserialisation flaw surfaces — and FastJson has a documented history of exactly this problem, including a prior AutoType-related RCE, CVE-2022-25845, patched back in version 1.2.83 in 2022.