CVE-2026-66908

Резюме

Уязвимость некорректной аутентификации (Improper Authentication) в компоненте Platform HTTP Main проекта Apache Camel. Проблема затрагивает Apache Camel: от 4.8.0 до 4.22.0. Встроенный HTTP-сервер camel-main может защищать свои конечные точки аутентификацией JWT, настраиваемой через authenticationEnabled вместе со свойствами хранилища ключей JWT. JWTAuthenticationConfigurer.buildJwtOptions возвращал null, когда не были настроены ни jwtIssuer, ни jwtAudience, и вызывающий код полностью пропускал вызов JWTAuthOptions.setJWTOptions, поэтому экземпляр Vert.x JWTAuth создавался только на основе хранилища ключей. В результате входящие токены проверялись только на подпись и срок действия: утверждения iss и aud не проверялись вовсе. Ничто не сигнализировало об этом — сервер запускался нормально и не выдавал предупреждений, — поэтому развёртывание, настроенное задокументированным способом, незаметно применяло меньше ограничений, чем, как полагал оператор, было включено, а документация самого компонента описывала проверку подписи и срока действия как поведение по умолчанию, а issuer и audience — как необязательное дополнение. Затронуты были как сервер приложений, так и управляющий сервер, поскольку упущение присутствовало в каждом из двух путей configureAuthentication. Таким образом, принимался любой непросроченный токен, подписанный любым ключом, которому доверяет настроенное хранилище ключей, независимо от того, какой эмитент его выпустил или для какой аудитории он предназначался. Насколько далеко это заходит, зависит от набора доверия хранилища ключей: если ключ подписи принадлежит общему или мультитенантному поставщику удостоверений, принимается токен, легитимно выпущенный для совершенно другой аудитории, тогда как хранилище ключей, содержащее выделенного подписанта, сужает проблему до повторного использования токенов, выпущенных для других сервисов в пределах того же доверенного домена. Опции jwtIssuer и jwtAudience не существовали до версии 4.21.0, поэтому на более ранних релизах не было поддерживаемого способа принудительно проверять эти утверждения. Пользователям рекомендуется обновиться до версии 4.22.0, в которой проблема исправлена. Начиная с 4.22.0 сервер отказывается запускаться, когда настроено хранилище ключей JWT, но не заданы ни jwtIssuer, ни jwtAudience, с указанием задействованных свойств; развёртывание, которому действительно нужна только проверка подписи и срока действия, должно явно указать это с помощью новой опции jwtAllowMissingIssuerAndAudience, значение которой по умолчанию — false. Это поведение исправлено только в 4.22.0. Релизы 4.14.9 и 4.18.4 не меняют поведение по умолчанию: они добавляют опции jwtIssuer и jwtAudience, чтобы операторы на этих линиях сопровождения могли включать проверку утверждений через конфигурацию; установка, которая обновляется до 4.14.9 или 4.18.4 без задания хотя бы одного из этих двух свойств, по-прежнему принимает любой непросроченный токен, подписанный доверенным ключом. Пользователям версий 4.14.x или 4.18.x следует обновиться до 4.14.9 или 4.18.4, а затем задать jwtIssuer, jwtAudience или оба параметра. Релизы с 4.8.0 по 4.21.x включительно не дают возможности принудительно проверять эти утверждения — их следует перевести на версию, которая это поддерживает. Независимо от версии, ограничьте хранилище ключей JWT минимально возможным набором доверия — в идеале подписантом, выделенным для этого сервиса, а не общим ключом поставщика удостоверений, — а если шлюз уже проверяет issuer и audience перед сервером, убедитесь, что его нельзя обойти. Примечания: тикет JIRA: https://issues.apache.org/jira/browse/CAMEL-24281 ссылается на различные коммиты, устранившие проблему, и содержит больше подробностей. Защита в режиме fail-closed (с закрытием доступа при ошибке) не могла быть перенесена в более ранние ветки. Сами опции jwtIssuer и jwtAudience были введены только в 4.21.0 в рамках CAMEL-23525, поэтому на camel-4.18.x и camel-4.14.x оператору нечего было указать для удовлетворения этого требования, и такая защита сломала бы все JWT-развёртывания на этих ветках, не оставив доступного решения.