针对 Apache Camel 漏洞的可运行概念验证复现程序：当未配置 serializer 选项时，camel-spring-redis 会构建一个裸的 JdkSerializationRedisSerializer，且没有 java.io.ObjectInputFilter，并将其用于每一次读取。RedisConsumer.setBody 会在 Exchange 构造之前，将其应用于发布到订阅频道的每条消息的原始字节——因此，能够在订阅频道上发出 PUBLISH 的攻击者可以直接到达反序列化接收点，并能够执行任意序列化对象图的 readObject（远程代码执行，CWE-502）。同一个默认序列化器还支撑着生产者读取命令（GET/HGET/HGETALL/HVALS）以及 SpringRedisIdempotentRepository。
| 运行时 | 目录 | 技术栈 |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-spring-redis 4.22.0（受影响；修复版本 4.22.1） |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.29.0 + camel-quarkus-spring-redis 3.29.0（Camel 4.15.0，受影响） |
该缺陷可追溯至该组件在 2.11.0 中的引入，因此每个受影响的版本以及最新 Camel Quarkus 中的 Camel 4.15.0 均存在漏洞。修复随 Camel 4.18.5 / 4.22.1 / 4.23.0 发布；Spring Boot 模块同时运行受影响构建（4.22.0）和修复构建（4.22.1）。目前尚无已发布的 Camel Quarkus 捆绑修复后的 Camel。
该应用运行一条 Camel 路由，该路由在没有 serializer 选项的情况下 SUBSCRIBE 到 cve-channel（因此使用默认的 JdkSerializationRedisSerializer）。攻击者是一个普通的 Redis 客户端，只能向该频道 PUBLISH——它无法访问 Camel 进程。它发布一个刻意无害的 com.example.PwnMarker 的原始序列化字节，其 readObject 仅翻转一个 JVM 全局标志（无 gadget，无命令）。在受影响的构建上，消费者会反序列化它并执行 readObject；在修复的构建上，默认允许列表（标准 java./javax. 和 org.apache.camel. 类型）会以 InvalidClassException: filter status: REJECTED 拒绝 com.example.PwnMarker。
cd camel-spring-boot
mvn clean package
docker compose up -d --build # starts Redis + the reproducer
curl -s http://localhost:8080/exploit/attack
docker compose down
受影响构建上的预期输出：
Attacker connects to Redis redis:6379 and PUBLISHes a serialized com.example.PwnMarker to channel 'cve-channel'.
PUBLISH delivered to 1 subscriber(s).
Result:
>>> PROVEN: the Redis consumer deserialized the attacker-published, non-allow-listed class
>>> (com.example.PwnMarker) with no ObjectInputFilter — its readObject executed.
| 属性 | 值 |
|---|---|
| 组件 | camel-spring-redis（camel-spring-redis-starter / camel-quarkus-spring-redis） |
| CWE | CWE-502（不可信数据的反序列化） |
| 严重性 | 高 |
| 攻击向量 | 向 Camel spring-redis 消费者订阅的频道执行 PUBLISH（或控制生产者读取的 Redis 键）；默认序列化器在无任何过滤的情况下反序列化载荷 |
| 影响 | 在任何路由逻辑运行之前，通过 gadget 类在 Camel 进程内实现远程代码执行 |
| 受影响版本 | 从 2.11.0 起至 4.18.5 之前，从 4.19.0 起至 4.22.1 之前 |
| 修复版本 | 4.18.5、4.22.1、4.23.0 |
| JIRA | CAMEL-24421 |
| 致谢 | Leon Zlobecki |
公告：https://camel.apache.org/security/CVE-2026-78165.html
新增的 deserializationFilter 端点选项用于控制默认序列化器读取载荷时所应用的过滤器。当未设置时，若存在 JVM 范围的 jdk.serialFilter 则遵循该设置，否则应用一份保守的允许列表（标准 Java 和 Apache Camel 类型；拒绝 java.net），并且在 4.23.0/4.22.1 上还会额外强制执行 JEP-290 的图结构限制。序列化器通过其基于 Converter 的构造函数构建，并传入一个反序列化转换器，该转换器在读取图之前将过滤器设置到流上。将 serializer 设置为自定义的 RedisSerializer 仍会绕过过滤器，因为此时 Camel 不再控制载荷的读取方式。
设置 JVM 范围的 -Djdk.serialFilter=...（受影响的路径会遵循该设置），或将 serializer 端点选项设置为非 Java 序列化器，例如 StringRedisSerializer（作为 serializer 选项设置，而不仅仅是在自定义 redisTemplate 上设置）。在 Redis 上启用身份验证，并限制可向所订阅频道发布消息的主体。
本仓库出于教育和防御目的发布：帮助 Apache Camel 用户理解该漏洞、验证自身是否受影响，并确认升级可解决该问题。载荷是一个良性标记，不执行任何代码。请勿将本材料用于您不拥有或运营的系统。