FastJson zero-day actively exploited, and no fix exists

A zero-day vulnerability in the open-source Java library FastJson is being exploited in active attacks against US organisations, BleepingComputer reported on 27 July 2026. The vulnerability is tracked as CVE-2026-16723 and affects versions 1.2.68 through 1.2.83. It enables remote code execution without user interaction and without elevated privileges. Alibaba has confirmed the flaw is critical, and no fix is currently available.

What happens technically

FastJson is a widely used library for turning JSON documents into Java objects. According to BleepingComputer, the flaw sits in the type-resolution logic: the library performs attacker-controlled resource lookups before AutoType restrictions are enforced. An attacker can therefore abuse @type processing to load malicious classes, without AutoType being enabled and without known gadget chains from third-party libraries. According to the coverage, the flaw is particularly exploitable in Spring Boot applications packaged as executable fat-JAR files, which Alibaba describes as the most common Spring Boot deployment model.

The vulnerability was discovered by the offensive security company FearsOff, which published a technical write-up earlier in July. Imperva reports attacks against financial services, healthcare, computing, retail and several other industries, almost entirely targeting US-based organisations, with a few attacks in Singapore and Canada. Versions 1.2.60 and earlier are not affected according to the coverage, and the same goes for the successor fastjson2 and deployments that do not use fat JARs. FastJson 1.x is no longer actively maintained, and Alibaba's advice is to enable SafeMode immediately or switch to a build that is not affected.

What this means for you if you run Java applications

The attacks reported so far target US organisations. Our assessment is that a library this widespread also sits in Norwegian system portfolios, often without anyone knowing. If you run Java applications, it is worth knowing that FastJson frequently arrives as a dependency of other components. The fact that your own code never calls the library directly counts for little in that case. A vulnerability with no fix, in a library with no active maintenance, is not a situation you can wait out. There is no update to wait for, and the risk is yours to handle now.

We want to highlight the value of an up-to-date software inventory. With a maintained SBOM you can answer within minutes whether you are affected. Without one you have to search build files and container images while the attacks are ongoing. The NIS2 directive sets requirements for supply chain security and vulnerability handling. An abandoned library in production is exactly the kind of risk your management is expected to have visibility into.

Berigo recommends

• Search the dependencies of all Java applications for FastJson, including transitive dependencies that arrive with other components.
• Enable SafeMode where affected versions are in use, or switch to a build that is not affected, as Alibaba advises.
• Prioritise Spring Boot applications packaged as fat JARs, since the attacks according to the coverage target precisely these.
• Plan a migration away from FastJson 1.x, which is no longer actively maintained.
• Establish a software inventory (SBOM) so the next library vulnerability can be answered with a lookup, not a search campaign.