Декодер протокола HTTP/1.x в Eclipse Vert.x принимает часть заголовков за другие, если в имени отличается один символ. Из-за этого обратный прокси (сервер, который принимает внешние запросы и передаёт их приложению) и сам Vert.x по-разному определяют, где заканчивается тело запроса. Расхождение открывает путь к контрабанде HTTP-запросов - технике, при которой остаток одного запроса читается как начало следующего. Затронуты приложения на Vert.x ветки 5.x, которые работают за обратным прокси и держат соединения к бэкенду (серверной части) открытыми для повторного использования.
Механика CVE-2026-102479 и контрабанда HTTP-запросов
Причина в ускоренной проверке имён заголовков. Чтобы не создавать лишние строки, декодер сверяет длину имени и отдельные байты, а не каждый символ подряд. Для имён длиной 14 байт проверка пропускает байт на восьмой позиции, то есть букву L. В результате заголовок Content-Xength проходит как Content-Length, который задаёт длину тела запроса в байтах.
На практике расхождение проявляется сразу. Обратный прокси считает Content-Xength произвольным пользовательским заголовком и не придаёт ему значения. Vert.x, напротив, отсчитывает объявленное число байт тела и ждёт их поступления. Если тело не отправлено, соединение зависает, а серверный поток остаётся занятым. Так ошибка разбора превращается в отказ в обслуживании: приложение перестаёт отвечать другим клиентам.
Более сложная схема оставляет в теле ровно один недополученный байт. Декодер приостанавливается и не формирует ответ, поэтому прокси считает соединение чистым и возвращает его в пул (набор открытых соединений для повторного использования). Следующий посетитель приходит со своим запросом, его первый байт закрывает чужой долг, и Vert.x отдаёт ему ответ, подготовленный для другого обращения. Возникает рассинхронизация очереди ответов: получатель и содержимое ответа не совпадают.
Числовой оценки CVSS ни запись CVE, ни разбор не приводят; авторы разбора оценивают её как high (высокий уровень). Условия атаки запись CVE не описывает. Из разбора следует, что запросы приходят по сети, учётные данные не нужны, а участие пользователя ограничивается его обычным обращением через тот же прокси.
Исправление вышло в vertx-core 5.1.10 и 5.2.1; более новые выпуски содержат ту же правку. Запись CVE исправленную версию не называет, номера исправлений приведены в разборе. Уязвимы выпуски 5.0.0-5.0.12, 5.1.0-5.1.9 и 5.2.0, а выходили они на протяжении нескольких месяцев. Более ранние ветки в перечне не указаны, и по предварительным данным вендор считает их не затронутыми.
Для практического результата нужен обратный прокси, который переиспользует соединения к бэкенду. Кроме того, число байт должно совпадать с тем, что прокси реально отправляет в соединение: nginx и аналоги добавляют свои заголовки. Наивный вариант с настоящим Content-Length и поддельным Content-Xength не проходит. Netty, на которой работает Vert.x, отклоняет второй Content-Length и отвечает ошибкой 400; эта защита связана с CVE-2019-20445.
Дальше расходятся варианты использования. При фиксации сессии (навязывании чужой сессии) жертва получает cookie учётной записи атакующего и работает внутри его аккаунта, оставляя там покупки и документы. Межсайтовый скриптинг (XSS, внедрение чужого скрипта в страницу) приходит в браузер жертвы при обычном просмотре, без перехода по подозрительной ссылке. Скрытый фишинг опирается на перенаправление: переход на сторонний сайт выглядит как доверенный маршрут внутри сервиса.
Авторы разбора проверили семь прокси: nginx, HAProxy, Envoy, Traefik, Caddy, Apache httpd и nghttpx. В первой схеме все они отбрасывали соединение с не до конца прочитанным ответом; обход с одним недополученным байтом сработал на всех, включая Caddy и nghttpx. Атаку воспроизвели и на проектах с открытым кодом: TechEmpower/FrameworkBenchmarks, strimzi-kafka-bridge версии 0.33.0 и apache/camel-quarkus за фронтальным прокси. На одном соединении срабатывание было стабильным. При пуле из 16 соединений доля отравленного трафика оценивается примерно в 25-35%.
Сведений об эксплуатации в реальных атаках нет. Разбор описывает лабораторное воспроизведение, а публикация записи CVE 14 октября 2026 года означает раскрытие деталей, но не использование уязвимости. Обходных мер, кроме обновления, источники не приводят.
Значимость уязвимости определяется не только дефектом разбора, но и тем, что для эксплуатации хватает обычного пользовательского трафика. Администратору нужно сверить версию vertx-core в сборке и обновить её до 5.1.10 или 5.2.1, а обновления записи CVE отслеживать отдельно.
Ссылки
- https://www.cve.org/CVERecord?id=CVE-2019-20445
- https://www.cve.org/CVERecord?id=CVE-2026-102479
- https://research.jfrog.com/post/byte-debt-vertx-header-typo-session-fixation/
