CVE-2026-78329 in Camel
Сводка
по VulDB • 24.08.2026
Уязвимость, связанная с некорректной проверкой входных данных (Improper input validation), в компоненте Apache Camel Undertow.
Эта проблема затрагивает Apache Camel: версии от 4.11.0 до 4.14.9 (не включая 4.14.9), от 4.15.0 до 4.18.4 (не включая 4.18.4) и от 4.19.0 до 4.22.0 (не включая 4.22.0).
В классе UndertowEndpoint поле headerFilterStrategy по умолчанию инициализировалось базовым HttpHeaderFilterStrategy, который затем передавался в создаваемый лениво объект UndertowHttpBinding, тем самым перезаписывая UndertowHeaderFilterStrategy, устанавливаемую DefaultUndertowHttpBinding в своем конструкторе. Если развертывание не предоставляло пользовательский binding или явную настройку headerFilterStrategy, то специфичная для undertow фильтрация никогда не выполнялась на маршрутах, настроенных через endpoint: объект стратегии создавался и немедленно заменялся до того, как он мог быть использован. Следствием этого является то, что префикс заголовков обмена websocket. устаревшего формата не фильтровался на границе транспорта undertow ни в одном направлении; поэтому HTTP-потребитель (consumer) undertow отображал входящие сетевые заголовки такого формата на объект Exchange, где производитель WebSocket (producer) undertow считывал их как директивы диспетчеризации и мог доставлять сообщения узлу, отличному от выбранного маршрутом. Кроме того, имена заголовков, которые сам undertow не принимает, отображались на объект Exchange вместо того, чтобы игнорироваться. Потребители Rest DSL никогда не были затронуты, поскольку UndertowComponent явно назначает UndertowRestHeaderFilterStrategy, которая расширяет стратегию для undertow.
Это не является регрессией уязвимости CVE-2025-30177: базовый HttpHeaderFilterStrategy самостоятельно настраивает фильтр префиксов Camel для входящих данных, поэтому защита, введенная в соответствии с тем advisory (советом по безопасности), продолжала работать через базовый класс и никогда не терялась. Изменение же привело к тому, что стратегия для undertow осталась «сиротой» на пути endpoint, из-за чего два последующих исправления, внесенные в нее — одно пропускает имена заголовков, которые отвергает undertow, а другое фильтрует префикс legacy websocket. в обоих направлениях — применялись к классу, который больше не использовался endpoint, и поэтому они не сработали в релизах, содержащих эти исправления.
Пользователям рекомендуется обновиться до версии 4.22.0, которая устраняет проблему. Если пользователи используют ветку LTS-релизов 4.14.x, им предлагается перейти на версию 4.14.9. Если пользователи находятся в ветке релизов 4.18.x, им рекомендуется обновиться до версии 4.18.4. Для развертываний, которые не могут сразу выполнить обновление, следует явно настроить стратегию вместо того, чтобы полагаться на значения по умолчанию; например, привязав UndertowHeaderFilterStrategy в реестре и указав ее на endpoint как undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy, а также дополнительно удалив заголовки диспетчеризации на границе доверия с помощью removeHeaders(“websocket.*”). Обратите внимание на остаточное ограничение, которое не устраняется обновлением: компонент undertow намеренно сохраняет значения websocket. как часть своего внешнего API-контракта, а UndertowProducer считывает их через in.getHeader(), который вообще не обращается к HeaderFilterStrategy. Следовательно, восстановленная фильтрация обеспечивает защиту только «в глубину» (defense in depth) на границе транспорта undertow. Маршрут, передающий недоверенное сообщение от потребителя, не являющегося частью undertow, производителю undertow, этой исправлением не защищен и должен самостоятельно удалять эти заголовки.
If you want to get best quality of vulnerability data, you may have to visit VulDB.