netty-resolver-dns-check

io.netty:netty-resolver-dns में तीन DNS कैश पॉइज़निंग CVE के लिए ऑफ़लाइन चेकर — 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        (every link: compile scope)

और यह केवल क्लासपाथ पर ही नहीं है। Reactor Netty का HttpClient — वह कनेक्टर जिसे Spring Boot WebClient के लिए चुनता है जब भी Reactor Netty मौजूद हो — होस्ट नामों को Netty के अपने DnsAddressResolverGroup से रिज़ॉल्व करता है, न कि 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 अनुरोध करता है, ने Netty के रिज़ॉल्वर के माध्यम से एक वास्तविक DNS क्वेरी भेजी (WRITE: UDP ... DefaultDnsQuestion(example.com.))।

CVE-2026-45674 और CVE-2026-47691 के एडवाइज़री इसे स्पष्ट रूप से कहते हैं: "Netty के DNS रिज़ॉल्वर का उपयोग करने वाला कोई भी एप्लिकेशन प्रभावित है।"

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 की एक पंक्ति है। कठिन प्रश्न यह है कि क्या रिज़ॉल्वर वास्तव में उपयोग में है। इसलिए हमने चार वास्तविक Spring Boot 3.5.14 फैट जार और एक 3.5.16 पर बनाया, और ग्राउंड ट्रुथ को मापा — Netty द्वारा वास्तव में भेजी गई DNS क्वेरीज़ — बनाम जो यह टूल केवल जार से अनुमान लगाता है:

ईमानदार परिणाम: टूल विश्वसनीय रूप से "उपयोग में" कहता है जब कोई ओवरराइड न हो, और यह आपके कोड और कॉन्फ़िग में ओवरराइड के निशान ढूँढ लेता है (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

यह वह पढ़ता है जो वास्तव में पैकेज किया गया है (फैट जार BOOT-INF/lib, war WEB-INF/lib, नेस्टेड जार), न कि pom.xml — निर्भरता ट्रांज़िटिव है, इसलिए pom आपको बताएगा कि यह वहाँ नहीं है। उपस्थिति का निर्णय क्लास io/netty/resolver/dns/DnsNameResolver.class से होता है, न कि वर्शन मैनिफ़ेस्ट से। ओवरराइड के निशान केवल आपकी अपनी क्लासेस और application*.properties/yml में खोजे जाते हैं (लाइब्रेरी जार स्वयं इन क्लासेस को संदर्भित करते हैं)।

आउटपुट चीनी में है; वर्डिक्ट पंक्तियाँ और CVE आईडी वही हैं जिन पर स्क्रिप्ट को कुंजी बनानी चाहिए।

यह आपको क्या नहीं बताता

• क्या कोई हमलावर आप तक पहुँच सकता है। CVE-2026-47691, एडवाइज़री से: एक हमलावर जो किसी सबडोमेन के लिए एक आधिकारिक नेम सर्वर को नियंत्रित करता है, पैरेंट डोमेन के लिए कैश को ज़हर कर सकता है — इसलिए आपके ऐप को हमलावर द्वारा नियंत्रित नाम को रिज़ॉल्व करना होगा (उदाहरण के लिए, उपयोगकर्ता-आपूर्ति किए गए URL प्राप्त करना)। CVE-2026-45673 मध्यम (6.8) है और आपके रिज़ॉल्वर तक पहुँचने के लिए स्पूफ़ किए गए प्रतिक्रियाओं की आवश्यकता होती है। एडवाइज़री के अनुसार गंभीरता: दो उच्च (8.7), एक मध्यम।
• पर्यावरण चर के माध्यम से, या किसी लाइब्रेरी जार के अंदर सेट किए गए ओवरराइड, स्टैटिक स्कैन के लिए अदृश्य हैं। उन मामलों में टूल "उपयोग में" की ओर झुकता है।
• जो लाइब्रेरी सीधे Reactor Netty के HttpClient का उपयोग करती हैं (उदाहरण के लिए एक गेटवे) उनका अलग से विश्लेषण नहीं किया जाता — यदि 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