netty-resolver-dns-check

Автономный статический анализатор, который проверяет упакованные Java-архивы на наличие уязвимых версий netty-resolver-dns и определяет, действительно ли Spring WebClient использует DNS-резолвер Netty.

И он не просто присутствует в classpath. HttpClient из Reactor Netty — коннектор, который Spring Boot выбирает для WebClient всякий раз, когда присутствует Reactor Netty — разрешает имена хостов с помощью собственного DnsAddressResolverGroup из Netty, а не резолвера JDK:

• HttpClientConfig.defaultAddressResolverGroup() → HttpResources.getOrCreateDefaultResolver()
• TcpResources.getOrCreateDefaultResolver() → NameResolverProvider.newNameResolverGroup(...)
• NameResolverProvider.newNameResolverGroup → new DnsNameResolverBuilder() → new DnsAddressResolverGroup(builder)

(То же самое в reactor-netty 1.1.x, 1.2.x, 1.3.x и main.) Порядок определения коннектора в Spring Boot — reactor > jetty > httpComponents > jdk, поэтому Reactor Netty побеждает всякий раз, когда он есть.

Мы не остановились на чтении исходников. В контролируемом эксперименте ниже приложение на стандартном Spring Boot 3.5.14, выполняющее один запрос через WebClient, отправило один реальный DNS-запрос через резолвер Netty (WRITE: UDP ... DefaultDnsQuestion(example.com.)).

В рекомендациях по CVE-2026-45674 и CVE-2026-47691 сказано прямо: «Любое приложение, использующее DNS-резолвер Netty, затронуто».

2. Какие версии Spring Boot поставляются с уязвимой версией по умолчанию

Все три CVE имеют одно и то же исправление: 4.1.135.Final (линейка 4.1) / 4.2.15.Final (линейка 4.2). Данные взяты из каждого spring-boot-dependencies-<v>.pom (<netty.version>), 2026-09-11:

Исправленные версии есть в Maven Central. Обновление работает; этот инструмент не утверждает обратного.

3. Что статический анализ может и чего не может сказать

Номер версии — это одна строка из mvn dependency:tree. Более сложный вопрос — действительно ли резолвер используется. Поэтому мы собрали четыре реальных fat jar на Spring Boot 3.5.14 и один на 3.5.16 и измерили истину в последней инстанции — DNS-запросы, фактически отправленные Netty — в сравнении с тем, что этот инструмент выводит из одного лишь jar:

Честный результат: инструмент надёжно говорит «используется», когда переопределения нет, и находит следы переопределения в вашем коде и конфигурации (3 из 3, без ложного срабатывания на A). Он не может отличить B (всё переопределено) от D (один клиент всё ещё на стандартном резолвере) — их байткод-свидетельства идентичны. Поэтому переопределение никогда не заставляет его сказать «не уязвимо»; он говорит «проверьте вручную» и даёт вам одноминутную проверку ниже.

Самопроверка за одну минуту

1. Запустите приложение с --logging.level.io.netty.resolver.dns=DEBUG
2. Заставьте его отправить исходящий запрос через каждый имеющийся у вас WebClient
3. Ищите WRITE: UDP в логе — есть: резолвер Netty используется; нет: этот запрос его не использовал

Не судите по критерию «загружался ли DnsNameResolver?». Приложение B заменило резолвер и всё равно загрузило этот класс, потому что группа резолверов по умолчанию создаётся заранее. Доказательство — только строки запросов.

Использование

Он читает то, что фактически упаковано (fat jar BOOT-INF/lib, war WEB-INF/lib, вложенные jar), а не pom.xml — зависимость транзитивная, поэтому pom сказал бы вам, что её там нет. Наличие определяется по классу io/netty/resolver/dns/DnsNameResolver.class, а не по манифестам версий. Следы переопределения ищутся только в ваших собственных классах и application*.properties/yml (библиотечные jar сами ссылаются на эти классы).

Вывод на китайском; строки вердикта и идентификаторы CVE — то, на что должны ориентироваться скрипты.

Чего он вам не скажет

• Может ли злоумышленник до вас добраться. CVE-2026-47691, из рекомендаций: злоумышленник, контролирующий авторитативный сервер имён для поддомена, может отравить кэш для родительских доменов — поэтому ваше приложение должно разрешать имя, контролируемое злоумышленником (например, загружая URL, предоставленные пользователем). CVE-2026-45673 — средняя (6.8) и требует поддельных ответов, чтобы достичь вашего резолвера. Серьёзность по рекомендациям: две высокие (8.7), одна средняя.
• Переопределения, заданные через переменные окружения или внутри библиотечного jar, невидимы для статического анализа. В таких случаях инструмент склоняется к «используется».
• Библиотеки, использующие HttpClient из Reactor Netty напрямую (например, шлюз), не анализируются отдельно — если Reactor Netty присутствует, предполагается стандартный путь.
• Версии вне линеек 4.1 и 4.2 помечаются как «невозможно судить», а не угадываются.

Откуда берутся правила

GitHub advisory API, прочитано 2026-09-11:

Таблица Spring Boot находится в BootTable.java; модульный тест заново выводит три утверждения из раздела 2 на её основе, поэтому таблица и утверждения не могут незаметно разойтись.

Контролируемый эксперимент

evidence/ содержит пять приложений (A–E) и runtime.sh, который подсчитывает строки WRITE: UDP для каждого приложения. tools/e2e_real_jars.py запускает этот инструмент против тех же пяти jar и проверяет каждый вердикт. Для сборки приложений требуется Maven 3.6.3 или новее.

Коды выхода

Лицензия

Apache License 2.0