CVE-2026-98432, Linux कर्नेल के TCP कनेक्शन अनुरोध स्वीकार करने के तरीके में मौजूद एक कमजोरी है। इसकी मदद से दूर बैठा हमलावर, बिना पासवर्ड के, सर्वर को क्रैश कर सकता है या कर्नेल की मेमोरी खराब कर सकता है। Linux कर्नेल की CVE टीम ने इसे 10 में से 9.8 अंक दिए हैं, और Anthropic का कहना है कि उसके मॉडल Claude ने एक एक्सप्लॉइट लिखा जो MPTCP कनेक्शन स्वीकार करने वाले सर्वरों पर हमलावर को root अधिकार दे देता है। फिक्स मुख्य कर्नेल में आ चुका है और Debian इसे जारी कर चुका है, लेकिन 30 अक्टूबर 2026 तक Ubuntu ने 22.04, 24.04 और 26.04 के लिए इसे "work in progress" (काम चल रहा है) बताया है, और Red Hat ने RHEL 8, 9 और 10 को प्रभावित और बिना अपडेट के बताया है। अपडेट आने तक: अगर MPTCP की जरूरत नहीं है तो उसे बंद करें, IP विकल्पों वाले IPv4 पैकेट ब्लॉक करें, सीमित करें कि आपके सर्वरों तक कौन पहुंच सकता है, और रीबूट की योजना बनाएं।

CVE-2026-98432 क्या है, और यह आपकी कंपनी के लिए क्यों मायने रखती है?

आधिकारिक CVE रिकॉर्ड के अनुसार, यह कमजोरी उस पल में है जब IPv4 पर TCP हैंडशेक पूरा होता है: कर्नेल कनेक्शन अनुरोध के साथ सहेजे गए IP विकल्पों को कॉपी किए बिना नए कनेक्शन को सौंप देता है, जबकि ठीक उसी पल कोई दूसरा CPU एक डुप्लिकेट अनुरोध को प्रोसेस करके उन्हीं विकल्पों से जवाब बना सकता है। अगर कर्नेल पहले उस मेमोरी को खाली कर दे, तो वह उसे खाली करने के बाद पढ़ता है, और इस गड़बड़ी को use-after-free कहा जाता है। यह कमजोरी कर्नेल 4.4 से मौजूद है। कर्नेल की CVE टीम ने इसे 15 अक्टूबर 2026 को प्रकाशित किया और 10 में से 9.8 अंक दिए, क्योंकि इस तक नेटवर्क के जरिए, हैंडशेक के दौरान और किसी भी लॉगिन से पहले, उपयोगकर्ता की किसी भागीदारी के बिना पहुंचा जा सकता है।

27 अक्टूबर की एक पोस्ट में Anthropic ने बताया कि Claude ने एक एक्सप्लॉइट लिखा, जिससे बिना किसी क्रेडेंशियल वाला दूर बैठा हमलावर उन Linux सर्वरों पर root के रूप में कमांड चला सकता है जो MPTCP, यानी मल्टीपाथ TCP, कनेक्शन स्वीकार करते हैं। उसके परीक्षण में एक्सप्लॉइट को कर्नेल मेमोरी से एक पता लीक करने में 48 मिनट लगे, और फिर कमांड चलाने तक पहुंचने में 5 मिनट। इससे भी बुरी बात यह है कि नाकाम कोशिश से सर्वर क्रैश नहीं होता; सिर्फ वह कनेक्शन विफल होता है, इसलिए हमलावर बिना किसी की नजर में आए बार-बार कोशिश करता रह सकता है। Anthropic ने एक्सप्लॉइट खुद प्रकाशित नहीं किया।

Red Hat इसका मुख्य असर सर्वर क्रैश और सेवा से इनकार (denial of service) बताता है, साथ में मेमोरी खराब होने की आशंका भी। CISA की ज्ञात शोषित कमजोरियों की सूची के 30 अक्टूबर वाले संस्करण तक यह कमजोरी उसमें नहीं जोड़ी गई थी।

क्या आपके डिस्ट्रीब्यूशन तक अपडेट पहुंचा है?

30 अक्टूबर 2026 को हर डिस्ट्रीब्यूशन के आधिकारिक पेज पर यह स्थिति दिख रही थी:

डिस्ट्रीब्यूशनस्थिति
Ubuntu 22.04, 24.04, 26.04 और 26.10असुरक्षित, फिक्स "work in progress" (काम चल रहा है); 24.04 के लिए कर्नेल 6.8.0-149 में (Ubuntu पेज)
Ubuntu 16.04, 18.04 और 20.04असुरक्षित
Red Hat Enterprise Linux 8, 9 और 10प्रभावित, कोई अपडेट जारी नहीं (Red Hat पेज)
Red Hat Enterprise Linux 6 और 7प्रभावित नहीं
Debian 12 और 136.1.190-1 और 6.12.113-1 में ठीक किया गया (Debian ट्रैकर)

मुख्य कर्नेल में फिक्स 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 और 7.3 संस्करणों में आया। लेकिन ज्यादातर सर्वर अपने डिस्ट्रीब्यूशन का कर्नेल चलाते हैं, इसलिए मायने आपके डिस्ट्रीब्यूशन का पेज रखता है, मुख्य कर्नेल का संस्करण नंबर नहीं।

कैसे पता करें कि कोई सर्वर खतरे में है?

इंटरनेट से कनेक्शन स्वीकार करने वाले हर Linux सर्वर पर ये कमांड चलाएं:

uname -r
cat /proc/sys/net/mptcp/enabled
ss -Mln
cat /proc/sys/net/ipv4/tcp_migrate_req
  • पहली कमांड कर्नेल का संस्करण दिखाती है; उसे अपने डिस्ट्रीब्यूशन के पेज से मिलाएं। उदाहरण के लिए, Ubuntu 24.04 पर आज उपलब्ध हर संस्करण बिना फिक्स का है।
  • दूसरी कमांड से 1 मिले तो इसका मतलब है कि MPTCP चालू है, और कर्नेल दस्तावेज के अनुसार यही डिफॉल्ट है।
  • तीसरी कमांड उन सेवाओं की सूची देती है जो MPTCP कनेक्शन स्वीकार करती हैं। इसमें दिखने वाली हर सेवा उसी तरह का निशाना है जिसका Anthropic ने फायदा उठाया। Go में लिखे प्रोग्रामों पर ध्यान दें: Go 1.24 के रिलीज नोट्स के अनुसार, जहां समर्थन है वहां उनके लिसनर अब डिफॉल्ट रूप से MPTCP इस्तेमाल करते हैं।
  • चौथी कमांड को 0 दिखाना चाहिए; CVE रिकॉर्ड के अनुसार कमजोरी का दूसरा रास्ता तभी काम करता है जब इसका मान 1 हो।

अपडेट आने तक अस्थायी समाधान: 5 कदम

  1. अगर आपके डिस्ट्रीब्यूशन में फिक्स आ गया है, तो उसे अभी इंस्टॉल करें और रीबूट करें। उदाहरण के लिए Debian 12 और 13 पर:
    sudo apt update && sudo apt upgrade
    sudo reboot
    नया कर्नेल तब तक आपकी रक्षा नहीं करता, जब तक सर्वर उस पर चलने न लगे।
  2. अगर किसी सेवा को MPTCP की जरूरत नहीं है, तो उसे बंद करें। इससे उस तरह का निशाना बंद हो जाता है जिसका Anthropic ने फायदा उठाया:
    sudo sysctl -w net.mptcp.enabled=0
    echo "net.mptcp.enabled = 0" | sudo tee /etc/sysctl.d/99-disable-mptcp.conf
    पहली कमांड सेटिंग को तुरंत लागू करती है; दूसरी उसे रीबूट के बाद भी बनाए रखती है। कर्नेल दस्तावेज के अनुसार यह सेटिंग हर नेटवर्क नेमस्पेस के लिए अलग होती है, इसलिए इसे कंटेनरों के अंदर भी लागू करें। MPTCP उपलब्ध न होने पर Go प्रोग्राम अपने आप सामान्य TCP पर लौट आते हैं। लेकिन न Anthropic और न कोई डिस्ट्रीब्यूशन यह कहता है कि इसे बंद करने से कमजोरी खुद खत्म हो जाती है, इसलिए यह जोखिम को घटाता है, उसका इलाज नहीं करता।
  3. IPv4 विकल्पों वाले TCP पैकेट ब्लॉक करें। CVE रिकॉर्ड का स्कोरिंग परिदृश्य एक ऐसे हमलावर को मानता है जो IPv4 के Record Route या Timestamp विकल्प वाला कनेक्शन अनुरोध भेजता है, और सामान्य वेब, ईमेल और SSH ट्रैफिक को इन विकल्पों की जरूरत नहीं होती। अपने नेटवर्क एडमिनिस्ट्रेटर से ऐसा फायरवॉल नियम बनवाएं जो उन आने वाले TCP पैकेटों को गिरा दे जिनका IPv4 हेडर 20 बाइट से लंबा हो, और पहले इसे एक सर्वर पर परखें। कोई डिस्ट्रीब्यूशन नहीं कहता कि इससे कमजोरी रुक जाती है, लेकिन इससे वह शर्त हट जाती है जिसे स्कोरिंग मानकर चलती है।
  4. सीमित करें कि आपके सर्वरों तक कौन पहुंच सकता है। इस कमजोरी को कनेक्शन स्वीकार करने वाला एक खुला TCP पोर्ट चाहिए, इसलिए हर वह पोर्ट बंद करें जिसकी जरूरत नहीं है, और SSH व एडमिन पैनल को सिर्फ तय IP पतों से या VPN के जरिए खुला रखें। अगर साइट CDN जैसी किसी बिचौलिया सेवा के पीछे है, तो ओरिजिन सर्वर को सिर्फ उसी सेवा के पतों से कनेक्शन स्वीकार करने दें।
  5. अपडेट आने से पहले उसकी तैयारी करें। इस CVE के लिए Ubuntu और Red Hat के पेजों पर नजर रखें, कर्नेल अपडेट को पहले से मंजूरी दें और रीबूट का समय तय करें, ताकि फिक्स जिस दिन जारी हो उसी दिन लग जाए। कर्नेल लॉग में ऐसे क्रैश पर नजर रखें जिनमें ip_options_build का जिक्र हो:
    sudo journalctl -k | grep -i ip_options_build
    फिर भी शांत लॉग का मतलब सुरक्षा नहीं है, क्योंकि नाकाम कोशिश से सर्वर क्रैश नहीं होता।

अगर आपके सर्वर किसी होस्टिंग प्रदाता के पास हैं तो?

शेयर्ड होस्टिंग और मैनेज्ड सेवाओं में कर्नेल प्रदाता का होता है, आपका नहीं। उससे तीन सवाल पूछें: उसके सर्वर कौन सा डिस्ट्रीब्यूशन और कर्नेल का कौन सा संस्करण चलाते हैं, वह फिक्स कब इंस्टॉल करेगा, और तब तक जोखिम घटाने के लिए क्या कर रहा है। वर्चुअल प्राइवेट सर्वर (VPS) में आमतौर पर कर्नेल आपके हाथ में होता है, इसलिए ऊपर दिए कदम खुद लागू करें।

Origami की राय

जैसा कि PHP की कमजोरियों पर हमारे लेख में था, जब आधिकारिक अपडेट में देर होती है, तो शुरुआती दिनों में सर्वरों की रक्षा अस्थायी कदम ही करते हैं। हालांकि ये सिर्फ जोखिम घटाते हैं; असली इलाज रीबूट के बाद ठीक किया गया कर्नेल ही है। Origami में हम आपके Linux सर्वरों की जांच कर सकते हैं, आपकी सेवाएं रोके बिना अस्थायी कदम लागू कर सकते हैं, और फिक्स जारी होते ही उसे इंस्टॉल कर सकते हैं। हमसे संपर्क करें।

मुख्य बातें

  • CVE-2026-98432, Linux कर्नेल की एक कमजोरी है जिसे कर्नेल टीम ने 10 में से 9.8 अंक दिए हैं, और जो TCP हैंडशेक के दौरान, किसी भी लॉगिन से पहले, सर्वर पर दूर से हमला करती है।
  • Debian ने फिक्स जारी कर दिया है; Ubuntu और Red Hat ने 30 अक्टूबर 2026 तक नहीं किया था।
  • जब तक वे नहीं करते: जरूरत न हो तो MPTCP बंद करें, IPv4 विकल्पों वाले TCP पैकेट ब्लॉक करें, और इस्तेमाल न होने वाले पोर्ट बंद करें।
  • ठीक किया गया कर्नेल जारी होते ही इंस्टॉल करें और रीबूट करें; अस्थायी कदम उसकी जगह नहीं ले सकते।

स्रोत