Apache Camel: Camel-JGroups: небезопасная десериализация Java сообщений кластера в потребителе JGroups может привести к удалённому выполнению кода
nvd · CVSS 3.1
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HНизкий · следующие 30 дней
EPSS – это статистическая оценка, а не достоверность или мера воздействия. Объедините это с CVSS, статусом KEV, воздействием и вашей средой.
Уязвимость десериализации недоверенных данных в компоненте Apache Camel Camel-Jgroups. Проблема затрагивает Apache Camel: с 4.0.0 до 4.18.5, с 4.19.0 до 4.22.1. JGroupsEndpoint.createExchange(Message), который CamelJGroupsReceiver вызывает для каждого сообщения, получаемого потребителем jgroups, до маршрутизации exchange, устанавливал тело exchange из org.jgroups.Message.getObject(). Для ObjectMessage — типа сообщения, который отправляет производитель Camel jgroups, — JGroups выполняет Java-десериализацию полезной нагрузки через ObjectInputStream в собственном потоке приёма по мере поступления сообщения, а getObject() возвращает полученный объект. На этом пути не применялся java.io.ObjectInputFilter, если только в развёртывании не был установлен общесистемный для JVM фильтр сериализации: camel-jgroups не устанавливал никакого, а версии JGroups, поставляемые с затронутыми выпусками, не применяют собственных, поэтому любой сериализуемый класс в classpath приложения мог быть инстанцирован и его колбэки десериализации выполнены. Если не настроен канал или опция channelProperties, потребитель создаёт свой канал через new JChannel() — стандартный стек протоколов JGroups, который осуществляет многоадресную рассылку по UDP без протокола AUTH и без шифрования, поэтому любой хост, способный достичь multicast-группы или порта привязки кластера, может присоединиться к кластеру и отправлять сообщения потребителю без учётных данных. Такой хост мог бы отправить специально сформированный сериализованный объект, приводящий к удалённому выполнению кода в процессе Camel при наличии в classpath пригодной цепочки гаджетов десериализации, причём на стороне потребителя не требовалось никаких нестандартных опций. Поскольку JGroups материализует объект до запуска приёмника Camel, проверка, выполняемая Camel, может лишь исследовать десериализованный результат и не способна остановить код, выполняемый во время десериализации, поэтому закрытие проблемы также требует механизма контроля, применяемого до чтения полезной нагрузки, как описано в рекомендациях по устранению. Эксплуатация требует сетевого доступа к multicast-группе или порту привязки кластера, что при стандартном транспорте UDP multicast означает хост в смежной сети, а также пригодной цепочки гаджетов в classpath, поэтому серьёзность оценивается как высокая, а не критическая. Пользователям рекомендуется обновиться до версии 4.23.0, в которой проблема исправлена. Если пользователи находятся на ветке выпусков 4.22.x, им предлагается обновиться до 4.22.1. Если пользователи находятся на ветке выпусков 4.18.x, им предлагается обновиться до 4.18.5. Ветка выпусков 4.14.x и более ранние, а также линейки выпусков 4.15.x–4.17.x и 4.19.x–4.21.x достигли окончания жизненного цикла до устранения этой проблемы и не получат исправления, поэтому развёртывания на этих линейках должны перейти на поддерживаемый выпуск.
Запускаемый proof-of-concept на Spring Boot, воспроизводящий CVE-2026-88900 — уязвимость небезопасной десериализации Java в camel-jgroups, — демонстрирующий поведение уязвимой и исправленной версий.
Используйте информацию об уязвимостях только в тех системах, которыми вы владеете или имеете право тестировать. Kitploit ссылается на метаданные общедоступных исследований и не хранит код эксплойта или вредоносные полезные данные.