文章总结： 本文探讨了如何利用大型语言模型（LLM）自动化发现Java反序列化gadget链。作者团队在短时间内构建了一套由LLM驱动的工具，该工具通过静态分析、图查询和动态调试等组件协同工作，成功在WildFly等现代应用服务器上发现了包括全新远程代码执行（RCE）链在内的多条新gadget链。其中最关键的发现是，通过利用应用服务器中重打包（shaded）的Xalan库副本，可以绕过JDK9+引入的JPMS模块化安全限制，重新构造出基于TemplatesImpl的RCE链。这项研究展示了AI技术在传统安全研究领域的强大潜力。 综合评分： 95 文章分类： AI安全,WEB安全,渗透测试,漏洞分析,二进制安全
用 2026 的方式挖 Gadget 链
Stephen Breen Stephen Breen
securitainment
2026年3月19日 13:37 中国香港
| 原文链接 | 作者 | | — | — | | https://www.atredis.com/blog/2026/3/12/findings-gadgets-like-its-2026 | Stephen Breen |
引言
Java 反序列化漏洞是我关注了近十年的研究领域。2016 年，我所在的团队发表了一篇题为 “WebLogic、WebSphere、JBoss、Jenkins、OpenNMS 和你的应用有什么共同点？就是这个漏洞。” 的博文，在众多知名企业级应用中掀起了一场漏洞风暴。此后，Java 生态系统不断采取措施，一方面减少对不可信数据进行反序列化的情况，另一方面缩减可被恶意利用的反序列化 gadget 的数量。
在渗透测试社区中，ysoserial 等工具一直被视为 gadget 链的近乎完备的集合，原因在于发现新 gadget 链的难度极高。虽然偶尔仍有新链被发现，但整体研究过程依然以手工操作为主，复杂度高，且对于未深入该领域的人来说门槛很高。新 gadget 的发布速度已大幅放缓——例如 ysoserial 已多年未添加新 gadget。纵观现有研究，新提出的 gadget 链屈指可数。目前主流应用服务器的默认配置几乎不会受到已公开 gadget 链的影响。
作为主要从事平台安全评估的安全顾问，考虑到发现新 gadget 链的复杂性，我们的时间并不适合投入到这项工作中。于是我们思考：LLM 能否自动化 gadget 发现这一任务？这恰恰是 LLM 非常擅长的场景。仅用两天时间，我们就实现了一套全新的 gadget 发现方法，并验证了其有效性——我们发现了多条新链，其中包括一条可在 WildFly 应用服务器上利用的全新链，该链可能还会影响其他主流应用服务器和框架。
背景：60 秒了解 Gadget 链
对于不熟悉 Java 反序列化细节的读者，简单来说：Java 反序列化 gadget 链是一系列方法调用的序列，它在 ObjectInputStream.readObject()等方法处理攻击者控制的输入时触发，最终到达一个危险的 sink方法，执行对攻击者有利的非预期操作。sink方法能够触发命令执行、文件写入、XML 外部实体注入 (XXE) 等行为，或者调用其他会产生非预期后果的 Java 内部方法。反序列化链依赖于应用服务器 classpath 上已有的 Java 类，通过各种技术将它们串联起来。
发现可利用的反序列化链面临几个关键难点。一个典型的应用服务器 classpath 可能包含数千个实现了 Serializable接口的类，它们都是可以传递给初始 readObject调用的潜在入口。每个 Serializable类可以持有任意子类型，而这些子类型往往是抽象的，因此可能对应许多不同的具体类。再加上反射等动态语言特性，搜索空间会变得极为庞大。GadgetInspector 等现有工具通过静态分析来缩小搜索空间，使其能够进行人工验证，但可能会遗漏某些类型的链。即便如此，仍然需要大量人工分析来排除大部分误报结果。
本项目的核心思路是：在合理的架构设计下，LLM 可以综合运用静态分析、推理和编程能力，从零开始构建完整的 gadget 链。LLM 在具有反馈循环的场景中表现尤为出色，因为反馈循环使其能够不断验证自身的假设。
架构概述
工具的整体架构是通过与 LLM 反复交互设计出来的。其设计具有一些有趣的特性，充分发挥了 LLM 的优势。整个工具可以拆分为 5 个独立组件：
- 调用图构建器——用于构建 source (入口)、sink (汇聚点) 及其连接关系的图结构工具，数据当前存储在 SQLite 数据库中。
- 图查询服务器——一个提供 REST API 的轻量 HTTP 服务器，暴露用于查询调用图数据库的端点。LLM agent 通过它搜索可能的路径。
- LLM Agent——Claude Code 充当 LLM agent，负责查询图数据库、发现潜在链路，并可选地借助 “Dynamic Runner” 进行调试和评估。
- Dynamic Runner——一组用于执行和调试候选测试工具的工具集。LLM agent 不一定每次都会使用，但随时可用。
- 评估——首先使用针对目标 classpath 编译的测试类进行本地验证。链路在本地确认后，再部署到目标环境中的最小化 Web 应用上进行测试。
调用图构建器
构建调用图的目标是创建一张包含所有可能 source 和 sink 以及它们之间所有可达路径的完整图。但实际操作中需要做出一些取舍，因为可能的组合数量过于庞大。在构建调用图时，我们首先使用 IBM Watson Libraries for Analysis (WALA) 的类层次分析 (CHA)。CHA 是一种构建调用图的快速但不够精确的技术——CHA 调用图中并非所有边在真实的反序列化链中都是可达的。
CHA 会生成一张非常庞大的图，尤其是应用于应用服务器或复杂企业应用的 classpath 时。为了裁剪图的规模，我们将范围限定为实现了 Serializable或 Externalizable的类，然后通过字段类型和方法签名向外扩展三跳。超出此范围的内容将被排除在分析之外。
CHA 图是基础层。在此基础上，我们对所有目标类进行一轮扫描，注入额外的边以处理 Java 中的动态特性，具体通过 Java ASM 库检查类字节码来实现。随后使用 ASM 进行第二轮扫描，为可能的类型混淆场景创建对应的边。对于类型为接口或抽象类的每个 Serializable类，系统会记录其所有实现类。
图查询服务器
图查询服务器是一个基于 Python 的轻量 FastAPI 服务，为 LLM 提供 HTTP 查询端点。它暴露了以下接口：
-
/paths查找从入口到 sink 的所有简单路径，并标注边的类型
-
/type_confusion_targets返回可注入指定字段的所有具体类型
-
/decompile对任意类或方法运行 CFR 反编译器并返回源码
-
/serialization_constraints返回哪些字段能通过序列化保留，以及每个字段可接受的子类型
-
/predecessors从 sink 反向回溯，查找调用它的方法
-
/classes_implementing列出某个接口的所有具体实现类
这些 API 端点使 LLM 能够高效地探索调用图，而无需在上下文窗口中加载过多的调用链数据结构。
LLM Agent
本项目中的 agent 是 Claude Code。Claude Code 实质上负责驱动前述各阶段创建的工具。为了使结果具有一定的可重复性，我们创建了一份 Markdown 文件，其中详细说明了预期的工作流程以及各自定义工具的使用方法 (RUNBOOK.md)。
Runbook 指导 agent 构建调用图，并通过查询服务器搜索反序列化链。对于候选链，agent 会构建 Java 测试工具来验证；若验证失败，则使用 Dynamic Runner 组件中的工具进行调试并尝试修复。这一”发现候选链并验证”的过程构成了一个反馈循环，有效地排除误报并确保 agent 始终朝正确方向推进。
这种方法的一个不足之处在于分析过程是非确定性的。每次运行工具都可能产生不同的结果，有时需要多次提示 agent 继续深入探索，才能找到有效的链。
Dynamic Runner
Dynamic Runner 组件是一组 Python 工具，用于帮助 agent 确认候选链。它包括基于 JDWP 的调试工具、用于监控 DNS 查询的 DNS 服务器、污点跟踪工具等。Agent 会根据需要随时调用这些工具。
评估
LLM 使用针对目标 JAR 文件编译的最小化测试类，自主完成 gadget 链的发现和测试。对于验证失败的链，LLM 会利用 Java 调试工具进行迭代修复，获取链在何处以及如何失败的详细信息。通过验证的链随后会在部署于目标应用服务器上的最小化 Web 应用中进行测试。我们同样使用 LLM 来完成这一步骤，因为它通常涉及一些调试工作，但此步骤并不在 Runbook 工作流的范围内。
测试目标
我们最初计划使用一套标准基准测试来验证这套工作流和工具。在其他研究中，工具通常被指向 ysoserial JAR 文件，该文件包含大量已知 gadget 链的相关类。基准测试的思路是：看工具能从已知链的总数中发现多少条。然而这里我们遇到了第一个问题：agent 太聪明了。Claude Code 迅速识别出基准测试 classpath 上的 gadget 与 ysoserial 中已收录的已知 gadget 一致，实质上是在”作弊”。
与其解决基准测试的问题，我们决定将工具指向真实目标——没有已知公开 gadget 链的应用服务器。我们测试了以下应用：
IBM WebSphere 9.0.5.24 WildFly 39.0.1 Payara (GlassFish 分支) 6.2024.6
这些都是现代应用服务器，已针对已知 gadget 链实施了缓解措施。WildFly 和 Payara 使用 JDK21，JPMS 机制应当使依赖 TemplatesImpl类的 gadget 链无法生效。WebSphere 则具有庞大的 classpath，且运行在其自有的定制 JDK 上。
发现成果
该工具发现了大量新链，其中最引人注目的可能为其他常见框架和应用服务器上的远程代码执行 gadget 链打开新的突破口。值得注意的是，大部分新发现的链都是已知链的变体。
工具总共发现了 17 条经确认的 gadget 链，其中 6 条被认为是全新的。仅有一条链直接实现了远程代码执行——考虑到测试目标的选择和项目的有限时间，这一结果并不意外。
CB1-Shaded-RCE: TemplatesImpl 并未消亡
这是我们发现的最引人关注的 gadget 链，因为它可在 WildFly 应用服务器的常见配置下实现远程代码执行，同时为后续研究开辟了新的方向。
TemplatesImpl类是 Java JDK 的一部分，被广泛用于多条反序列化 gadget 链 (CC2、CC4、Spring1、Rome1、Hibernate1、CommonsBeanutils1 等)。在 JDK 9 及以上版本中，这些 gadget 链均被认为已经失效，原因在于 JDK 引入了名为 JPMS (Java Platform Module System) 的模块化特性。JPMS 将特定 JDK 类标记为内部类，禁止用户代码继承它们。例如，class Evil extends AbstractTranslet这样的类定义是非法的，因为 AbstractTranslet位于未导出的包 com.sun.org.apache.xalan.internal.xsltc.runtime中。JPMS 的设计初衷正是要阻止所有基于 TemplatesImpl的远程代码执行 gadget。
然而，WildFly 附带了一个名为 jakarta.servlet.jsp.jstl-3.0.1-jbossorg-1.jar的 JAR 文件，其中包含 Xalan XSLTC 库的 shaded (重打包) 副本，包路径被重定位为 org.eclipse.tags.shaded.org.apache.xalan。JAR 文件的 shaded 副本通常用于随应用发布特定版本的库，避免与 classpath 上的其他版本产生冲突。这份 shaded 副本包含了重新启用远程代码执行 gadget 链所需的全部类 (TemplatesImpl、TransletClassLoader、AbstractTranslet等)。由于这些类存在于应用程序 JAR 中而非 JDK 本身，JPMS 对其不起作用。在构造反序列化 gadget 时，我们可以继承 shaded 版本的 AbstractTranslet，由 shaded 版本的 TransletClassLoader完成类定义，最终 Class.newInstance()执行恶意的静态初始化器。该方法在 JDK 21 上验证可行。
PriorityQueue.readObject()
→ BeanComparator.compare("outputProperties")
→ PropertyUtils.getProperty(templates, "outputProperties")
→ TemplatesImpl.getOutputProperties() [shaded Eclipse Tags copy]
→ newTransformer()
→ defineTransletClasses()
→ TransletClassLoader.defineClass(evilBytecodes)
→ Class.newInstance()
→ <clinit> static initializer
→ Runtime.getRuntime().exec(cmd) [RCE]
此前的研究曾利用过 Xalan 的其他 shaded 副本，但据我们所知，从未用于基于字节码加载的远程代码执行。经检查已知的黑名单，我们未发现 org.eclipse.tags.shaded命名空间被列入其中。
| # | Shaded 命名空间 | 来源 | CVE / Issue |
| — | — | — | — |
| 1 | org.apache.xalan | Apache Xalan 独立版 | jackson-databind ^2469 |
| 2 | com.sun.org.apache.xalan.internal | JDK 内部 | jackson-databind #2704 |
| 3 | oadd.org.apache.xalan | Apache Drillshaded uber-JAR | jackson-databind #2688 |
| 4 | com.oracle.wls.shaded.org.apache.xalan | Oracle WebLogic Server | CVE-2020-35728, jackson-databind #2999 |
| 5 | org.docx4j.org.apache.xalan | docx4j 文档处理库 | jackson-databind #3003 |
上述所有已知利用都是通过 Jackson 的多态类型处理机制利用 JNDIConnectionPool(一个 JNDI gadget) 实现的；没有任何一个利用 TemplatesImpl进行字节码加载 RCE，也没有任何一个绕过了 JPMS。
任何在 java.xml模块之外附带了 Xalan XSLTC 库副本的服务器或应用程序，都会重新激活 TemplatesImpl攻击面。
我们在最新版本的 WildFly 上成功确认了命令执行，测试使用了一个部署到服务器上的小型应用程序，其 classpath 包含 Commons-BeanUtils 和 Commons-Collections。jakarta.servlet.jstl.api依赖由 WildFly 自动加载，部署目标应用时无需将其作为模块手动添加。
$ docker exec wildfly-deserialize-poc cat /tmp/rce-proof.txt
=== RCE via Shaded TemplatesImpl CB1 ===
Date: Tue Mar 10 12:53:28 AM UTC 2026
User: uid=1000(jboss) gid=1000(jboss) groups=1000(jboss)
Java: openjdk version "21.0.10" 2026-01-20 LTS
PriorityQueue-AttributeComparator-JNDI
这条链的独特之处在于它看起来是完全原创的，充分展示了 LLM 深入挖掘的能力。从入口到 JNDI 查询的调用链路非常长，涉及来自多个不同 Payara JAR 文件的类。
此类 JNDI 查询链在现代 JDK 版本中不会直接实现代码执行，但可以作为一个有价值的攻击原语。
PriorityQueue.readObject()
→ heapify() → siftDownUsingComparator()
→ AttributeComparator.compare(Attribute a1, Attribute a2)
→ a1.getName().compareTo(a2.getName()) // same name → returns 0
→ a1.getValue().toString() // falls through to value comparison
→ InjectableJMSContext.toString()
→ delegate()
→ isInTransaction() → false (no transaction context)
→ requestedManager.getContext(id) → null (empty contexts map)
→ requestedManager.getContext(ipId, id, metadata, getConnectionFactory(false))
→ getConnectionFactory(false)
→ connectionFactory == null (transient field, always null after deser)
→ new InitialContext().lookup(metadata.getLookup())
→ JNDI INJECTION with attacker-controlled URL!
反序列化链中使用的类来自 amx-core.jar和 gf-jms-injection.jar两个 JAR 文件。该链在部署了测试应用的实际 Payara 实例上进行了验证，我们如预期收到了 RMI 握手：
$ # TCP listener on attacker host captures RMI handshake:
CONNECTION CAPTURED from ('172.17.0.4', 53378)
Data (7 bytes): b'JRMI\x00\x02K'
Hex: 4a524d4900024b
*** RMI HANDSHAKE DETECTED - JNDI INJECTION CONFIRMED ***
这条链具有多个新颖之处。首先，它使用 AttributeComparator类作为 toString触发器——此前通常使用 BadAttributeValueExpException类来实现此目的，但该类在 JDK 18+ 中已失效。此外，通过 InjectableJMSContext作为到达 JNDI 查询的路径似乎也是一个新发现。
WildFlyDataSource-JNDI：一条并不那么新颖的链
WildFlyDataSource.readObject()直接调用 new InitialContext().lookup(jndiName)，其中 jndiName直接来自反序列化数据流——这是一条相当直接且简短的 JNDI 查询路径。
WildFlyDataSource.readObject()
→ new InitialContext().lookup(jndiName) [JNDI / SSRF]
经调查发现，尽管 LLM 认为这条链是全新的，但它此前已被 Synactiv 在博文中记录过 (https://www.synacktiv.com/publications/finding-gadgets-like-its-2022)。
CC4-BeanComparator 桥接 (多条链)
剩余四条链都使用了相同的技巧：将 commons-collections4的 TransformingComparator桥接到 commons-beanutils的 BeanComparator。这些链是已知 gadget 链的轻微变体。Ysoserial 中已经包含了适用于 commons-beanutils的 gadget，这些新链只是在 PriorityQueue类可能被反序列化过滤器阻止时，提供了一条替代路径。这种场景在实际中并不常见。此外，这些 gadget 的 RCE 在现代 JDK 中已被封堵，因为所需路径依赖于 TemplatesImpl(……除非你有一份 shaded 副本！)。
核心问题在于：ysoserial 的 CC2 和 CC4 链要求 InvokerTransformer是可序列化的。从 CC4 4.5.0 版本开始，Apache 维护者将 InvokerTransformer设为不可序列化。CC2 和 CC4 在现代 CC4 库上已经失效。但 TransformingComparator仍然是可序列化的，且未加入任何安全检查。
发现了两个入口点，每个入口点可到达两个 sink：
TreeBag可到达 TemplatesImpl(RCE) 和 JdbcRowSetImpl(JNDI)：
TreeBag.readObject()
→ TreeMap.put()
→ TransformingComparator.compare()
→ ConstantTransformer → BeanComparator → sink
DualTreeBidiMap可到达相同的两个 sink：
DualTreeBidiMap.readObject()
→ createBidiMap() → putAll() → TreeMap.put()
→ TransformingComparator.compare()
→ ConstantTransformer → BeanComparator → sink
总计发现了四条链：两条 RCE，两条 JNDI 注入。
| 属性 | ysoserial CC2/CC4 | CC4-TreeBag / CC4-DualTreeBidiMap | | — | — | — | | 需要 InvokerTransformer 可序列化 | Yes | No | | 适用于 CC4 4.5.0+ | No | Yes | | 入口点 | PriorityQueue | TreeBag / DualTreeBidiMap | | 跨库 | No (仅 CC4) | Yes (CC4 + commons-beanutils) |
与 ysoserial 的 CB1 gadget 相比，CB1 直接使用 PriorityQueue与BeanComparator组合。而本文发现的链通过ConstantTransformer将BeanComparator包裹在TransformingComparator内部，使用TreeBag作为入口点。当反序列化过滤器阻止了PriorityQueue但允许TreeBag时，入口点的差异就具有实际意义。
更广泛的影响：Shaded TemplatesImpl 生态
在 WildFly 上确认 CB1-Shaded-RCE 链后，我们希望进一步探索其他应用服务器是否也在 java.xml平台模块之外附带了 shaded 版本的 TemplatesImpl。
如前所述，我们在 WildFly 39.0.1 上确认了漏洞利用——JSTL JAR 对所有 WAR 部署都会自动加载。WildFly 附带了 Commons-BeanUtils库，该库提供了利用 shaded TemplatesImpl所需的触发器。虽然应用程序需要将 Commons-BeanUtils声明为依赖项，但该库本身随应用服务器一同分发。
JBoss EAP (Jakarta EE 10+)、GlassFish 7+、Payara 6+ 都包含 shaded 的 TemplatesImpl构件，但它们均不包含 Commons-BeanUtils。我们进行了有限的探索，尝试在这些应用服务器自带的库中寻找其他可行的触发器，但在项目的有限时间内未能找到。在评估过程中，我们发现了两个新的 shaded Xalan 命名空间：com.oracle.wls.shaded.org.apache.xalan(Jetty) 和 openejb.shade.org.apache.xalan(TomEE)。如果部署到这些应用服务器上的应用程序自带了包含 TemplatesImpl触发类的第三方库，那么应用服务器附带的 shaded TemplatesImpl就可能被利用。包含此类触发器的库包括 CommonsCollections 3 和 4、部分版本的 Jackson、ROME 和 Hibernate 等。
IBM WebSphere 不受此影响，无论是 Liberty 版还是传统版。两个版本的 WebSphere 服务器均不包含 shaded 的 TemplatesImpl。传统版 WebSphere 运行在 IBM J9 上，完全使用 com.ibm.xtq.xslt.jaxp.TemplatesImpl替代了 Oracle 的 TemplatesImpl。该类不实现 Serializable接口，没有 _bytecodes字段，且通过类名而非原始字节数组来加载 translet 类。
我们还注意到，Maven Central 上独立的 xalan:xalan构件拥有超过 112,000 个依赖方 (仅 2.7.2 版本)。任何直接或间接引入该构件的应用程序，都会在 JPMS 之外拥有一份 TemplatesImpl。此外，Apache Drill、Oracle WebLogic、docx4j 以及来自 Karaf、ServiceMix 和 SpringSource 的 OSGi bundle 中也存在 shaded 副本。
总结
我们的目标是评估 LLM 能否有效地在经过多年缓解措施加固的现代应用服务器中发现 Java 反序列化 gadget。我们认为这次初步的概念验证取得了成功。
一个出乎意料有效的机制是”测试、调试、推理”循环——它使 LLM 能够自动尝试调试失败的 payload。这一策略非常有效，且可以推广到 agent 使用的一般场景：只要条件允许，构建反馈循环始终是一个好策略。另一个令人意外的收获是，我们观察到 LLM agent 会在核心工具效果不佳时主动对其进行修改。这揭示了一种全新的思维方式：将源代码视为动态且可变的，而 Runbook才是定义实际流程和目标的核心。
Claude Code 的计划文件和 Runbook可在我们的 GitHub 仓库查阅：https://github.com/atredispartners/llmchainhunter。
免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：securitainment Stephen Breen Stephen Breen《用 2026 的方式挖 Gadget 链》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论