Apache Software Foundation исправляет уязвимости в Kafka и ещё нескольких продуктах

В Apache Kafka и связанных с ней компонентах устранили несколько уязвимостей. Часть из них позволяет удалённо остановить брокер или контроллер кластера. Другие дают возможность обойти проверку подлинности клиента и прочитать файлы на хосте брокера. Затронуты брокер, клиентская библиотека, Kafka Streams, Kafka Connect и контроллер KRaft.

Отказ в обслуживании, обход аутентификации и раскрытие файлов

Оценку CVSS вендор не приводит, уровень серьёзности в записях также не указан. В уведомлении перечислены нарушения целостности и конфиденциальности данных, обход политики безопасности и удалённый отказ в обслуживании. Условия атаки описаны словами: в ряде случаев нужен только сетевой доступ, в остальных требуется действующая учётная запись, иногда с правом записи в топик. Участие пользователя не требуется ни в одном из сценариев.

Выделение памяти при разборе запросов

Брокер разбирает входящий запрос раньше, чем проверяет права. Генераторы протокола заранее выделяют память под массивы и служебные поля по числу, которое объявил отправитель. Число сверяется только с остатком буфера запроса, поэтому небольшое сообщение заставляет выделить в несколько раз больше памяти. На слушателе без аутентификации это делает любой, у кого есть сетевой доступ.

Похожая картина с распаковкой. В интерфейсе телеметрии проверяется лишь сжатый размер полезной нагрузки, а распакованный остаётся неограниченным. Для сжатых пакетов записей заявленный размер тела сообщения не сверяется с доступными данными: сообщение размером около девяноста байт вызывает попытку выделить примерно два гигабайта. Предел размера записи и квоты здесь не помогают, потому что считают сжатый размер.

Ещё одна ошибка касается Kafka Streams. Одна запись с меткой времени у верхней границы диапазона вызывает переполнение при расчёте следующего срабатывания, и поток обработки зависает с удержанной блокировкой. После перезапуска зависание возвращается, поскольку запись остаётся в топике. Отказ в обслуживании контроллера KRaft требует учётной записи с правом CLUSTER_ACTION.

Проверка токена доступа

Несколько проблем касается SASL/OAUTHBEARER, механизма аутентификации по токену доступа. Если у брокера не задан адрес источника ключей проверки подписи, валидатор по умолчанию молча переключается на реализацию без проверки подписи. Такой брокер принимает любой структурно корректный токен, включая токен без подписи, и пускает клиента под произвольной учётной записью, вплоть до суперпользователя. Сетевой доступ нужен, учётные данные не нужны; уязвимость описана под идентификатором CVE-2026-110985.

Второй случай мягче. Подпись токена проверяется всегда, а издатель и получатель только при явно заданных ожидаемых значениях. Риск возникает там, где один источник ключей обслуживает несколько издателей токенов: токен, выпущенный для чужого издателя, проходит проверку. Закрыто это лишь в выпуске 4.4.0.

Похожий по смыслу обход есть в Kafka Connect. Когда административный интерфейс вынесен на отдельный слушатель, расширения безопасности к нему не применяются. Точка управления журналами принимает запросы без аутентификации: видно, какие классы загружены, а уровни логирования можно менять, в том числе сразу для всех узлов кластера.

Чтение файлов и значений конфигурации

Запрос на изменение конфигурации брокера доходит до проверки значений раньше, чем до проверки прав. Через подстановку переменных конфигурации он заставляет брокер прочитать файл или переменную окружения и вернуть содержимое в тексте ошибки. Достаточно учётной записи без единого права. Раскрываются ключи, хранилища сертификатов и прочие секреты, доступные процессу брокера.

В Kafka Connect точка проверки коннектора возвращает значения, которые провайдеры конфигурации должны подставлять только во время работы. Любой, у кого есть доступ к этой точке, получает секреты в открытом виде.

Исправления вышли в версиях 4.2.2, 4.3.2 и 4.4.0. Проверку подписи токена и ограничение распаковки телеметрии закрывает уже 4.3.1. Для ветки 4.1.x и более старых исправлений нет, вендор советует перейти на 4.2.2 или новее.

Обновления в одном случае мало. Параметр max.decompressed.message.bytes задаёт предел размера распакованной записи, однако по умолчанию он практически не работает: значение близко к двум гигабайтам. После перехода на новую ветку его выставляют вручную, чуть выше самого большого законного сообщения и заметно ниже размера кучи, делённого на число потоков обработки и очистки журнала. Эта уязвимость описана под идентификатором CVE-2026-114349.

Часть проблем закрывается настройкой, без обновления. Для проверки подписи токена достаточно задать адрес источника ключей для каждого слушателя либо указать валидатор, который проверяет подпись. Для проверки издателя и получателя задают ожидаемые значения в двух параметрах. Начиная с 4.4.0 брокер с настроенным источником ключей не запустится без этих значений, если администратор явно не разрешил обратное.

В Kafka Connect обходной путь проще: убрать настройку admin.listeners. Тогда административные ресурсы работают через общий слушатель и наследуют его фильтры безопасности.

Сведений об эксплуатации перечисленных уязвимостей в реальных атаках нет. Записи опубликованы 28 октября 2026 года. Уведомление CERTFR-2026-AVI-1415 выпущено 29 октября 2026 года и ссылается на бюллетень безопасности Apache Kafka cve-list от 28 октября 2026 года.

Проблемы затрагивают брокер, клиентов, Streams и Connect одновременно. Многие сценарии не требуют прав в кластере, а один обходится вовсе без учётных данных. Для администратора главное сводится к переходу на 4.2.2, 4.3.2 или 4.4.0 и к проверке настроек аутентификации по токену доступа.

Отказ в обслуживании, обход аутентификации и раскрытие файлов

Выделение памяти при разборе запросов

Проверка токена доступа

Чтение файлов и значений конфигурации

Ссылки