Fastjson RCE: Spring Boot Dependency Check for SMBs

Here is the uncomfortable question this vulnerability forces every business running Java software to answer: do you actually know every library inside your applications? Not the ones your developers chose on purpose — the ones pulled in automatically, three or four levels deep, by something else you installed. Because a critical flaw in one such library, Alibaba's Fastjson, is being actively exploited against U.S. organizations right now, and the most dangerous versions are exploitable in their default configuration inside the single most common way Java apps ship: the Spring Boot fat-JAR.

On July 21, 2026, Alibaba published an advisory for a remote code execution flaw in Fastjson 1.x, and on July 23 the National Vulnerability Database recorded it as CVE-2026-16723 — a critical-severity bug (CVSS 9.0) affecting versions 1.2.68 through 1.2.83. Security researchers report attacks already hitting financial services, healthcare, retail, and other sectors, overwhelmingly in the United States. As of late July there was no fixed Fastjson 1.x release, which makes this a live problem you mitigate rather than simply patch. This article walks SMB leaders and IT owners through finding Fastjson in your stack, containing the risk, and confirming you were not already hit — the kind of exposure review ITECS runs as part of managed cybersecurity.

The riskiest dependency is often the one you never chose — buried deep inside a fat-JAR you shipped months ago.

Why This Fastjson Flaw Is Different

Fastjson has a long history of deserialization vulnerabilities, and over the years the standard defense became "turn AutoType off." That mental model is exactly what makes CVE-2026-16723 so dangerous — it sidesteps the defense everyone relied on.

According to the disclosure, the flaw stems from Fastjson's type-resolution logic performing attacker-controlled resource lookups before it enforces AutoType restrictions. Under a Spring Boot fat-JAR's class loader, a crafted request can drive a remote class load and code execution — with AutoType left off and no traditional "gadget" library on the classpath. The confirmed conditions are narrow but extremely common: Fastjson 1.2.68–1.2.83, a Spring Boot executable fat-JAR, a network-reachable endpoint that parses attacker-controlled JSON, and SafeMode left at its disabled default [Alibaba / The Hacker News].

That "extremely common" part deserves emphasis. The executable fat-JAR — a single self-contained archive bundling your app and every dependency, launched with java -jar — is the default and dominant way Spring Boot applications are packaged and shipped. It is what most build pipelines produce without any special configuration. So the vulnerable condition is not an exotic edge case an SMB can assume it avoided; it is the mainstream deployment model, which is a large part of why researchers are seeing exploitation land across so many different industries rather than one niche.

Step 1: Inventory Your Java and Spring Boot Apps for Fastjson

You cannot mitigate a library you do not know you have. Start by finding every Java application your business runs — internal tools, customer-facing services, vendor-supplied appliances — and check each for Fastjson, paying special attention to transitive dependencies that arrived indirectly. A framework, connector, or SDK you added for an unrelated reason may have pulled Fastjson in without anyone noticing.

# Maven — show every path that pulls in fastjson
mvn dependency:tree -Dincludes=com.alibaba:fastjson

# Gradle — inspect the runtime classpath
./gradlew dependencies --configuration runtimeClasspath | grep -i fastjson

Source builds are only half the picture. The artifact actually running in production is what matters, so also inspect the built fat-JAR itself — the Fastjson JAR lives inside it whether or not your source makes the dependency obvious:

# List bundled libraries and look for the fastjson version
unzip -l app.jar | grep -i fastjson

# Spring Boot bundles dependencies under BOOT-INF/lib/
# e.g. BOOT-INF/lib/fastjson-1.2.83.jar

For each hit, record the exact version and whether the app parses JSON from any network-reachable input. Match versions against the affected range:

Once you have the list, prioritize by exposure rather than treating every hit equally. An affected app that accepts JSON from the public internet is a five-alarm fire and should be mitigated first; an internal-only service reachable solely from a trusted network is lower urgency but still on the list, because attackers who gain a foothold elsewhere pivot to internal targets. Rank your findings by whether the app is internet-facing, whether it parses untrusted JSON, and how sensitive the data it touches is — then work top-down.

Step 2: Mitigate Now — Three Options, No Patch Required

With no fixed 1.x version available, you have three practical paths. They are not mutually exclusive — a common approach is to apply the fastest one immediately as a stopgap, then follow with the durable fix.

# Add to your JVM startup arguments
java -Dfastjson.parser.safeMode=true -jar app.jar

Step 3: Detect and Investigate — Before You Declare It Clean

Mitigation stops future exploitation; it says nothing about whether you were already hit. Because attacks are active and this bug enables remote code execution, treat any affected, internet-reachable app as potentially compromised until your logs say otherwise. Investigation runs on two fronts: the requests coming in and the behavior going out.

The tell-tale pattern: attacker JSON goes in, and the server unexpectedly reaches out to fetch a remote class.

Review WAF and application logs for suspicious JSON

Search your web application firewall and application logs for request bodies containing @type keys, especially paired with class names, nested JAR URL patterns, or references to remote hosts. Legitimate traffic to most endpoints rarely contains @type at all, so its presence is a strong lead worth running down. If you operate a WAF or managed firewall, add or confirm rules that reject JSON payloads carrying @type and similar deserialization markers as an additional layer in front of the app.

Hunt for unexpected outbound activity and process execution

Successful exploitation of this class of flaw typically forces the server to reach outward — to fetch a malicious class or open a callback. Those outbound signals are often easier to spot than the inbound payload. Look for:

• Outbound LDAP, RMI, or HTTP connections from application servers to unfamiliar external IP addresses — a classic remote-class-load or callback pattern.
• JNDI-related errors or lookup warnings in application logs, indicating attempted remote resource resolution.
• Unexpected Java class files appearing in temporary directories or cache locations.
• Anomalous child processes spawned by the Java process — shells, scripting interpreters, or network utilities the app has no reason to launch.
• New or modified files, accounts, or scheduled tasks around the timestamps of any suspicious JSON requests.

This correlation of inbound payloads with outbound behavior and process activity is precisely what endpoint detection and response and continuous network monitoring are built to surface. If you find evidence of exploitation, preserve the relevant logs and a system snapshot before you remediate, so the investigation into scope and lateral movement is not erased by the cleanup.

From Fire Drill to Dependency Discipline

CVE-2026-16723 is a stark reminder that your risk is not limited to the software you wrote or the libraries you deliberately chose — it extends to everything those choices dragged along behind them. The organizations that will handle the next transitive-dependency zero-day calmly are the ones that already maintain a software bill of materials, can answer "where do we run library X?" in minutes, and monitor their applications closely enough to notice a server reaching somewhere it never should.

Most SMBs do not have spare engineering hours to build that discipline while also shipping their actual product. Standing up dependency inventory, WAF tuning, and application-layer monitoring — and running the exposure hunt when the next critical CVE lands — is exactly the work a managed application hosting and security partner absorbs on your behalf.

Sources

• Alibaba — "Security Advisory: Remote Code Execution in fastjson 1.2.68–1.2.83" (July 21, 2026)
• Tenable — CVE-2026-16723 record
• The Hacker News — "Fastjson 1.x RCE Vulnerability Targeted in Attacks With No Patch Available"
• BleepingComputer — "Hackers target US firms in FastJson RCE zero-day attacks"
• Imperva — "Protected Against CVE-2026-16723: Critical FastJson 1.x Zero-Day RCE"