CVE-2026-71569

Резюме

Уязвимость Server-Side Request Forgery (SSRF) в компоненте A2A Apache Camel. Проблема затрагивает Apache Camel: с 4.21.0 до 4.22.2. WebhookUrlValidator классифицировал хост webhook push-уведомлений в двух местах, которые не согласовывались между собой. Хост, записанный как IP-литерал, сопоставлялся со списком строковых префиксов, в котором был указан диапазон уникальных локальных адресов IPv6 fc00::/7, тогда как хост, полученный через имя, разрешался, и результирующий адрес классифицировался с помощью предикатов InetAddress isLoopbackAddress, isAnyLocalAddress, isLinkLocalAddress и isSiteLocalAddress. Эти предикаты не покрывают ту же область, что и список префиксов: isSiteLocalAddress сообщает об устаревшем блоке fec0::/10, а не об уникальных локальных адресах fc00::/7, которые его заменили, и в JDK для них вообще нет предиката. Поэтому один и тот же адрес принимался или отклонялся в зависимости от того, как он был записан, и URL webhook, имя хоста которого разрешалось в fc00::/7, проходил проверку, которая отклоняла идентичный адрес, заданный как литерал. Затем PushNotificationDispatcher отправлял push-уведомление на этот адрес вместе с любым заголовком Authorization, содержащимся в той же конфигурации, схему и учётные данные которого предоставляет регистрирующий вызывающий. URL webhook поступает как TaskPushNotificationConfig.url от вызывающего, регистрирующего push-уведомление, поэтому он контролируется атакующим, а allowLocalWebhookUrls по умолчанию имеет значение false — это та конфигурация, в которой ожидается, что проверка будет действовать. Ответ не передаётся обратно вызывающему, зарегистрировавшему конфигурацию, поэтому в результате этого пробела возникает слепой исходящий HTTPS-запрос от процесса Camel к внутреннему адресу, который проверка была написана отклонять; для достижения сервиса таким способом дополнительно требуется, чтобы имя разрешалось в fc00::/7 в целевой среде, чтобы на этом адресе прослушивался HTTPS-сервис и чтобы TLS-рукопожатие для запрашиваемого имени прошло успешно, поэтому серьёзность оценивается как средняя. Та же строковая предварительная проверка была ошибочной и в другом направлении: она сопоставляла необработанную строку хоста, не установив предварительно, что хост является IP-литералом, поэтому любое имя, лишь начинающееся с fc или fd, например fcm.googleapis.com, отклонялось безоговорочно. Пользователям рекомендуется обновиться до версии 4.23.0, в которой исправлена эта проблема. Если пользователи находятся на ветке выпусков 4.22.x, им предлагается обновиться до 4.22.2. Линейка выпусков 4.21.x достигла окончания срока поддержки до того, как эта проблема была решена, и исправление для неё не будет выпущено, поэтому развёртывания на ней должны перейти на поддерживаемый выпуск. Теперь и путь литерала, и путь разрешённого адреса классифицируют адрес по его необработанным байтам с помощью единого общего классификатора, который распознаёт fc00::/7 и общее адресное пространство 100.64.0.0/10, а также IPv4-совместимые адреса, адреса NAT64 (64:ff9b::/96) и 6to4 (2002::/16), встроенный IPv4-адрес которых не является глобально маршрутизируемым. Для развёртываний, которые не могут обновиться немедленно, следует разместить аутентификацию перед путём конфигурации push-уведомлений A2A, чтобы URL webhook не поступал от недоверенного вызывающего, и запретить исходящий трафик от процесса Camel к fc00::/7 на сетевом уровне; если развёртывание не нуждается в IPv6, запуск JVM с -Djava.net.preferIPv4Stack=true устраняет класс адресов, на котором основан этот пробел. Обратите внимание, что allowLocalWebhookUrls=false уже является значением по умолчанию и само по себе не закрывает пробел.