Summary
- Artificial intelligence has fundamentally altered the threat model for Java deserialization attacks by making the discovery of new gadget chains fast and inexpensive.
- AI tools and large language model reasoning have automated this process, allowing researchers to discover hundreds of novel chains in seconds for pennies per analysis.
- This rapid automated discovery renders traditional defensive mitigations ineffective, as tools like blocklists, vendor denylists, and allowlists rely on identifying previously known classes and gadgets.
- The mean time to exploit has dropped to negative seven days, meaning attackers are actively exploiting flaws well before vendors release patches.
- Organizations must adopt dynamic runtime protections to counter this automated threat.
- Solutions like Waratek’s Deserial security rule confine deserialization operations to restricted micro-compartments and block malicious behavior without relying on signatures or prior knowledge of the attack.
For security researchers, CISOs and AppSec architects
For the last few years, the deserialization security research ran on an assumption: finding a new gadget chain is expensive. It took a skilled security researcher weeks of analyzing data flows, method bodies, tracing call graphs and hand-building payloads one byte at a time. Most discoveries ended up as a single CVE, or as a new entry in a toolkit like ysoserial.
In 2026 that assumption failed. Although ysoserial hasn’t merged a new gadget chain since 2021, the pace of deserialization research has accelerated sharply. Many new chains have been discovered since then.
This blog post explains the impact of AI in deserialization security research and why for defenders, the practical question is no longer whether a gadget chain exists for their stack. It is what still protects them when a zero-day gadget chain can be found on demand.
New gadget chains are now cheap
Recent security research on LLM-based tools shows that finding new gadget chains is now dramatically faster and cheaper than before. Chains that once took months of manual effort can now be identified in days using LLM-based security tools. What used to be expert craft is becoming an automated process.
In March 2026, Atredis Partners’ Stephen Breen, whose 2015 FoxGlove Security write-up helped start the Java deserialization era, published the results of pointing an AI coding agent at modern application servers. In just two days the team confirmed 17 gadget chains, 6 of them believed to be novel, including one that bypasses the Java Platform Module System (JPMS) boundaries on JDK 21 through a shaded library in WildFly. The targets, WildFly, WebSphere and Payara, were already hardened against the known chains. The decisive factor was a closed loop in which the model tested the candidate chains, challenged its own hypotheses, debugged the failures and iterated without a human in the middle.
Academia shows the same curve at scale. GadgetHunter (ACM FSE 2026) pairs static taint analysis with LLM reasoning at the points where static analysis traditionally gives up, such as reflection and dynamic dispatch.
It reports 197 previously unknown gadget chains and 12–85% fewer false positives than GadgetInspector, Tabby, Crystallizer, ODDFuzz and other tools. It costs about $0.04 and 23.5 seconds to analyze each candidate chain. A full benchmark run costs around $95 using a mid-tier commercial model. Anyone can afford gadget discovery at this scale.
The bottleneck was never exploitation of deserialization vulnerabilities. It was discovery, and discovery is where AI has changed the economics.
Today’s mitigations can be bypassed
The Atredis JPMS research matters more than its count. JPMS was not designed as a deserialization defense, but it was widely assumed to have killed TemplatesImpl-based chains on modern JDKs. Atredis showed why that assumption fails: any application that ships its own copy of the Xalan XSLTC library outside the JDK’s java.xml module brings TemplatesImpl back. The exposure was very broad. The shaded namespace they exploited (org.eclipse.tags.shaded) appeared on none of the blocklists they checked, and the standalone xalan:xalan artifact alone has over 112,000 dependents on Maven Central, any of which can pull a non-JDK Xalan onto the classpath directly or transitively.
That is the core problem with today’s mitigations. In practice, filters (e.g. JEP 290) and vendor denylists are configured around known class names and known gadgets. If novel gadget chains can be generated against a hardened configuration, a defense that was “good enough” may become a speed bump.
Sleeping Giants (ACM CCS 2025) adds a supply-chain dimension. Across 533 dependencies, 26.08% contained dormant chains that minor, stealthy code changes could activate. The reason is that class serializability shifts substantially over a library’s lifecycle. A clean SBOM today says little about the attack surface even after a minor version upgrade.
The patch window has closed
Faster discovery arrives in a world where exploitation already outpaces patching. Fixing a deserialization vulnerability is still a largely slow and manual process for vendors. They have to trace the root cause, then change the code, which can mean redesigning the serialization protocol, allowlisting permitted types, or blocklisting known malicious gadgets. Even after a fix ships, it only helps once users upgrade, and that usually means rebuilding and redeploying their applications. Attackers don’t wait for the patching cycle to finish.
CVE-2025-24813, an Apache Tomcat flaw that leads to remote code execution (RCE) through session deserialization, was exploited in the wild 30 hours after disclosure. It also shows why blocking the published gadget chain is not enough. The advisory documented a single gadget chain (via Commons Collections 3.2.1), but when the GadgetHunter team analyzed the same CVE, their tool found 12 additional exploitable variants. Every published chain has variations that attackers could find cheaply.
Google’s latest M-Trends 2026 puts mean time-to-exploit at negative seven days. You read that right. That’s a negative timeframe. On average, exploitation begins a week before a patch is available. In 2018, that timeframe was 63 days. The traditional cycle of discovering, disclosing, patching and deploying was working for that timeframe. Today this timeframe is gone. The threat model has changed. VulnCheck’s 1H-2026 report finds that 23.43% of known-exploited vulnerabilities were attacked on or before the day their CVE was published. Even after the CVE publication, the gap is shrinking: VulnCheck measured the average time from CVE publication to exploitation falling from 120 days in 2025 to 80 days in the first half of 2026.
The current evidence doesn’t show AI driving breaches yet. Mandiant didn’t consider 2025 the year breaches became a direct result of AI, and VulnCheck found that AI-discovered vulnerabilities are exploited at roughly the same rate as any others. That’s worth taking seriously, but it describes the past, not the direction of travel. So far, AI has mostly scaled discovery, while weaponization has remained slower and more manual. Deserialization is one striking exception: a confirmed gadget chain is already a working payload. When Atredis’s agent found new chains, it also built, debugged and validated the exploits in the same loop. For deserialization gadget chains, getting better at discovery means getting better at weaponization.
What has to change
If discovering new chains is becoming cheap, arriving before disclosure and can be activated by a dependency update, then any control that works by enumerating known chains (denylists, WAF signatures, gadget look-up tables) is betting against the curve above. The durable control constrains what deserialization is allowed to do, not which serialized bytes it receives.
Blocklists only stop gadget chains that someone has already published. When new chains are cheap, blocklist-based defense falls behind by design.
Allowlist-based filters (e.g. JEP 290) are sound in principle, but they only work if the application knows and maintains the exact set of classes it should ever deserialize, applies the filter at every deserialization entry point (not just ObjectInputStream), and none of the allowed classes can themselves be chained into a gadget. At enterprise scale, few teams manage this complexity for long. Even so, an allowlist can only permit the classes an application legitimately needs, and those classes can themselves be assembled into a chain. Atredis’s 2026 research is a direct illustration: JPMS was assumed to have killed TemplatesImpl-based chains on modern JDKs, yet any application shipping its own copy of the Xalan library outside the java.xml module re-enables them, and the shaded namespace they used appeared on no known blocklist.
Waratek’s Deserial security rule enforces a privilege boundary at runtime. It places every deserialization operation in a dynamically created, restricted micro-compartment, so legitimate use of classes like InvokerTransformer continues normally while any malicious gadget chain, whether published, zero-days, AI-detected, golden, or dormant, is blocked at runtime. It needs no profiling, no code changes, no user-defined filters or denylists of classes or gadgets, and it covers blind, deferred and stored variants. Waratek’s solution does not depend on signatures and does not need to have seen the malicious chain before. This is why it is so valuable in today’s reality where AI has made the discovery and creation of new gadget chains an automated routine.
The takeaway
AI has not invented a new vulnerability class. It has removed the scarcity that made CWE-502 look manageable. Defenders today must plan for an unbounded gadget chain catalogue, exploitation before disclosure and dependencies that become vulnerable between versions. Every class in the classpath is a potential attack surface for deserialization attacks. Security controls against deserialization must never just depend on a static list of class names or known gadgets. We must not forget that the root cause of the vulnerability is about deserializing untrusted data. In 2026 we can hit the nail on the head by using security controls that protect the runtime and the application even if untrusted data is deserialized and even if zero-days are discovered by AI tools.
Frequently Asked Questions
What is the primary way AI has changed deserialization attacks?
AI has transformed the discovery of gadget chains from a slow, manual, and expensive expert craft into an automated, fast, and cheap process. Tools utilizing large language models can now identify, test, and validate new chains in a fraction of the time and cost compared to human researchers.
Why are current security mitigations failing against these new threats?
Standard defenses like blocklists, vendor denylists, and filters are designed around known malicious gadgets and class names. Because AI can generate novel, zero-day gadget chains on demand against hardened configurations, these signature-based defenses are easily bypassed.
How fast are deserialization vulnerabilities being exploited in the current landscape?
Exploitation now frequently outpaces the patching cycle entirely. The mean time to exploit is currently negative seven days, indicating that attacks often begin a week before a vendor can provide a software patch.
Did the Java Platform Module System solve the problem of deserialization chains?
No, the Java Platform Module System was widely assumed to stop certain chains, but recent research demonstrated that applications shipping their own copies of libraries outside the core modules can easily reintroduce these vulnerabilities.
What type of defense is recommended for stopping novel and AI-generated gadget chains?
Defenders are advised to use solutions that enforce privilege boundaries at runtime rather than relying on static lists. For example, Waratek’s Deserial security rule places deserialization operations into dynamically created, restricted micro-compartments to block both known and unknown malicious chains without requiring code changes or signatures.
References (2025–2026)
- Breen, “Finding Gadgets Like It’s 2026,” Atredis Partners, Mar 2026, https://atredis.com/blog/2026/3/12/findings-gadgets-like-its-2026/
- “GadgetHunter: Region-Based Neuro-symbolic Detection of Java Deserialization Vulnerabilities,” ACM FSE 2026, https://dl.acm.org/doi/10.1145/3797065
- Kreyssig et al., “Sleeping Giants: Activating Dormant Java Deserialization Gadget Chains through Stealthy Code Changes,” ACM CCS 2025, https://arxiv.org/abs/2504.20485
- CERT-EU, “AI is changing the economics of vulnerability discovery,” Apr 2026, https://www.cert.europa.eu/blog/ai-vulnerability-discovery-defenders-must-adapt
- VulnCheck, “State of Exploitation 1H-2026,” Jul 2026, https://www.vulncheck.com/blog/state-of-exploitation-1h-2026
- The Hacker News, “Apache Tomcat vulnerability actively exploited 30 hours after disclosure,” Mar 2025, https://thehackernews.com/2025/03/apache-tomcat-vulnerability-comes-under.html
