netty-resolver-dns-check

أداة فحص دون اتصال لثلاث ثغرات تسميم ذاكرة DNS المؤقتة في io.netty:netty-resolver-dns — CVE-2026-45674 وCVE-2026-47691 وCVE-2026-45673 — وللسؤال الذي لا يستطيع رقم الإصدار الإجابة عليه: هل يستخدم تطبيقك هذا المُحلِّل فعلاً؟

إذا كنت تستخدم Spring WebClient، فالإجابة على الأرجح نعم، حتى وإن لم يظهر netty-resolver-dns في pom.xml الخاص بك ولم يستدعه أي شيء في شفرتك.

java -jar netty-resolver-dns-check-0.1.0.jar path/to/your-app.jar

لماذا توجد هذه الأداة

1. لم تُعلن عنه قط. WebClient يستخدمه افتراضياً.

يصل netty-resolver-dns عبر أربعة مستويات:

spring-boot-starter-webflux
 └ spring-boot-starter-reactor-netty
    └ reactor-netty-http
       └ reactor-netty-core
          └ netty-resolver-dns        (كل رابط: compile scope)

وهو ليس موجوداً على مسار الفئات (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 تأتي بإعداد افتراضي متأثر

تشترك الثغرات الثلاث في الإصلاح ذاته: 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 استبدل المُحلِّل ومع ذلك حمّل تلك الفئة، لأن مجموعة المُحلِّل الافتراضية تُبنى بحماس. أسطر الاستعلام وحدها هي الدليل.

الاستخدام

java -jar netty-resolver-dns-check-0.1.0.jar <directory | jar | war>
java -jar netty-resolver-dns-check-0.1.0.jar --version-of 4.1.132.Final

تقرأ ما هو مُحزَّم فعلاً (fat jar BOOT-INF/lib، war WEB-INF/lib، jars متداخلة)، وليس 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 هذه الأداة مقابل الملفات الخمسة ذاتها ويؤكد كل حكم. بناء التطبيقات يتطلب Maven 3.6.3 أو أحدث.

رموز الخروج

الترخيص

Apache License 2.0