If you run Java services built on Spring Boot, the new Fastjson RCE vulnerability deserves an inventory check today, not next sprint. CVE-2026-16723 lets an unauthenticated attacker run code on affected servers. It works under Fastjson’s default settings, and there is currently no patched version of the library to upgrade to.
The Fastjson RCE vulnerability, in brief
Fastjson 1.2.68 through 1.2.83, bundled inside a Spring Boot executable fat-JAR, can be tricked into loading and running attacker-supplied code from a crafted JSON request. That’s true whenever SafeMode is left off, which is the default. No AutoType flag needs to be enabled. No pre-existing gadget class is required. Alibaba disclosed the flaw on 21 July 2026, crediting researcher Kirill Firsov of FearsOff Cybersecurity. By 25 July, ThreatBook and Imperva had both confirmed active exploitation against production targets.
It’s the second unauthenticated pre-auth-to-RCE disclosure to land with no patch or workaround available in recent weeks. The pattern is the same. A widely embedded component turns out to be exploitable under its own default configuration, and defenders are left to mitigate rather than patch.
How the exploit actually works
Older Fastjson RCE bugs relied on AutoType being switched on, letting an attacker specify an arbitrary Java class to instantiate. This one takes a different route. Fastjson parses a JSON object carrying a @type field alongside a @JSONType annotation. It treats that annotation as proof the type is safe, then performs a class-resource lookup using the attacker-supplied value.
Inside a Spring Boot fat-JAR, application classes and dependencies sit in nested JAR paths rather than a flat classpath. That nested structure gives the attacker a way to point the lookup at a resource they control, sidestepping the type checks Fastjson normally relies on. From there, the parser loads and executes code with whatever privileges the Java process holds.
The whole chain lives inside default configuration. Any team that installed Fastjson and never touched SafeMode is a candidate, whether or not they remember using AutoType.
Four questions to answer this week
These four questions size up your exposure to the Fastjson RCE vulnerability without waiting on a formal audit.
1. Are we running Fastjson 1.x? Check build files for com.alibaba:fastjson and confirm the version falls between 1.2.68 and 1.2.83. Fastjson2 is a separate, unaffected codebase, so don’t stop the search at the artifact name alone.
2. Is it packaged as a Spring Boot fat-JAR? The confirmed chain needs an executable fat-JAR deployment specifically. Plain JARs, uber-JARs built with shade/assembly plugins, and WAR deployments fall outside the confirmed exploit path, though Imperva still recommends mitigating regardless of packaging.
3. Is SafeMode enabled? Look for -Dfastjson.parser.safeMode=true in your JVM startup flags. If it is missing, the default (disabled) applies and the exploit path is open.
4. Does anything reachable from the internet feed JSON into this parser? Any public API endpoint, webhook receiver, or internal service exposed through a load balancer counts. The exploit needs no authentication, so exposure alone is enough.
What to do if you’re exposed
Mitigating the Fastjson RCE vulnerability doesn’t require a code rewrite, just a configuration change applied consistently. Enable SafeMode first: it is a one-line JVM flag and directly closes the confirmed exploit path. If SafeMode breaks legitimate parsing behaviour in your application, fall back to the restricted com.alibaba:fastjson:1.2.83_noneautotype build instead. Alibaba’s advisory on the project’s GitHub security page documents both options.
Neither is a long-term answer. Fastjson 1.x has reached the end of its practical support life. The only durable fix is migrating to Fastjson2, which uses a different architecture and is not affected by this flaw. Treat that migration as planned work, not urgent work, once the immediate mitigation is in place.
Finally, check your logs. ThreatBook’s telemetry shows attackers currently favour browser-impersonation traffic, with Ruby and Go-based scanning tools behind roughly 30% of observed attempts. Financial services, healthcare, computing and retail targets in the US, Singapore and Canada make up most of the activity so far. If you find a JSON payload carrying an unexpected @type value in your access logs, assume compromise. Investigate it rather than assuming the request simply failed.
Common mistakes when triaging this
The most frequent misstep so far is scoping the search to services where developers remember choosing Fastjson. The library often arrives as a transitive dependency pulled in by something else. A build tool dependency-tree command (mvn dependency:tree or the Gradle equivalent) will surface instances that a manual code search misses entirely. Run it against every service, not just the ones you suspect.
A second mistake with the Fastjson RCE vulnerability is assuming that disabling AutoType in the past covers this bug. It doesn’t. Mitigation notes from a previous Fastjson incident that only mention AutoType are incomplete. Re-check SafeMode specifically, since it’s a separate setting with a separate default.
A third is testing for the flaw only against internet-facing endpoints. Internal services are still exploitable once an attacker has any foothold that can reach them, whether that’s a compromised host, a partner network, or another internal application. If your threat model includes lateral movement, internal-only Fastjson instances belong on the same remediation list as public ones, just with a later deadline.
If you manage a fleet, not one server
Teams running many services should prioritise by exposure and blast radius rather than trying to patch everything simultaneously. Rank affected services on three factors. Is the service internet-reachable? What data or systems could an attacker reach once inside? And can SafeMode be set through existing configuration management without a full redeploy? Services where SafeMode is a config-only change should go first, since that mitigation can often land within hours. Services that need an image rebuild take longer to update. For those, enabling a web application firewall rule to block suspicious @type payloads buys useful time in the interim.
Treat the Fastjson RCE vulnerability as a fleet-wide inventory problem first and a patching problem second. The inventory work tells you exactly how much risk you’re carrying. Patching only starts paying off once you know where to point it.
