गंभीर लिनक्स कर्नल भेद्यता CVE-2026-98432: तुमचा व्हीपीएस कसा तपासावा आणि अद्ययावत करावा

ऑक्टोबर २०२६ मध्ये, लिनक्स कर्नलमध्ये एक गंभीर असुरक्षितता, CVE-2026-98432 , आढळली, जिला CVSS स्केलवर १० पैकी ९.८ गुण मिळाले आहेत. याचा परिणाम येणाऱ्या IPv4 TCP कनेक्शन्सच्या हाताळणीवर होतो आणि, विशिष्ट परिस्थितीत, यामुळे आक्रमणकर्त्याला दूरस्थपणे सर्व्हरचा रूट ऍक्सेस मिळवता येतो — यासाठी प्रशासकाला कोणताही पासवर्ड किंवा कोणतीही कृती करण्याची आवश्यकता नसते.

कोणावर परिणाम होतो, तुमचा सर्व्हर कसा तपासावा आणि त्याचे संरक्षण कसे करावे, हे खाली दिले आहे. सर्व कमांड्स रूट म्हणून किंवा त्यासोबत चालवल्या जातात. sudo.

थोडक्यात असुरक्षितता

• हे काय आहे: IPv4 TCP कनेक्शन स्थापित करणाऱ्या कोडमधील 'रेस कंडिशन'मुळे निर्माण झालेला 'यूज-आफ्टर-फ्री' बग. हल्लेखोर कोणत्याही खुल्या TCP पोर्टवर खास तयार केलेली पॅकेट्स पाठवतो.
• प्रभावित कर्नल: लिनक्स ४.४ पासूनची प्रत्येक आवृत्ती, म्हणजेच व्यावहारिकदृष्ट्या प्रत्येक सध्याचे डिस्ट्रिब्युशन.
• IPv6 मुख्य बगमुळे प्रभावित होत नाही.
• धोका किती खरा आहे: अँथ्रोपिकच्या संशोधकांनी एक कार्यरत एक्सप्लॉइट चेन सादर केली आहे, ज्याद्वारे मल्टिपाथ टीसीपी (MPTCP) सक्षम असलेल्या सर्व्हरवर सुमारे ५३ मिनिटांत रूट ऍक्सेस मिळवण्यात आला. हा एक्सप्लॉइट कोड अद्याप प्रकाशित करण्यात आलेला नाही.
• जंगली हल्ले: १ नोव्हेंबर २०२६ पर्यंत, कोणत्याही शोषणाची नोंद झालेली नाही. हे शांतपणे अद्ययावत करण्याचे कारण आहे, ते पुढे ढकलण्याचे नाही.

गो सेवांमध्ये एक वेगळा धोका असतो. गो १.२४ पासून, लिनक्सवरील सर्व्हर प्रोग्राम्स, कर्नलने परवानगी दिल्यास, डीफॉल्टनुसार MPTCP द्वारे पोर्ट्सवर ऐकतात. आपला सर्व्हर अशी कनेक्शन्स स्वीकारतो हे प्रशासकाला कदाचित माहीतही नसेल. लोकप्रिय प्रोग्राम्सपैकी, एक्स-रे (Xray) याच पद्धतीने काम करतो — त्याच्या डेव्हलपर्सनी आधीच एक आपत्कालीन आवृत्ती, v26.10.31, प्रसिद्ध केली आहे, जी डीफॉल्टनुसार MPTCP अक्षम करते.

प्रत्येक व्हीपीएस (VPS) स्वतःचा कर्नल चालवतो, त्यामुळे तुम्हाला तुमच्या सर्व्हरमधील कर्नल स्वतःच अद्ययावत करावा लागतो. आम्ही व्हर्च्युअलायझेशन नोड्स स्वतःच अद्ययावत करतो.

तुमच्या सिस्टमवर काही उपाय आहे का?

१ नोव्हेंबर, २०२६ रोजीची स्थिती. जवळपास दररोज सुधारणा केल्या जात आहेत — सद्यस्थितीसाठी या लेखाच्या शेवटी दिलेल्या लिंक्स तपासा.

पायरी १. तुम्ही कोणता कर्नल वापरत आहात ते तपासा.

चालू असलेल्या कर्नलची आवृत्ती शोधा:

uname -r

केवळ आवृत्ती क्रमांकावरून काहीही कळत नाही: डिस्ट्रिब्युशन्स मूळ आवृत्ती न बदलता त्यांच्या स्वतःच्या कर्नलमध्ये दुरुस्त्या समाविष्ट करतात. कर्नल पॅकेजचा चेंजलॉग तपासणे अधिक विश्वसनीय आहे — जर त्यात CVE क्रमांकाचा उल्लेख असेल, तर ती दुरुस्ती आधीच स्थापित केलेली आहे.

डेबियन आणि उबंटू:

apt changelog linux-image-$(uname -r) 2>/dev/null | grep CVE-2026-98432

डेबियनवर, uname -v ही कमांड चालू असलेल्या कर्नलची संपूर्ण पॅकेज आवृत्ती देखील दाखवते: तिची वरील तक्त्याशी तुलना करा.

अल्मा लिनक्स, रॉकी लिनक्स, आरएचईएल, ओरॅकल लिनक्स:

rpm -q --changelog kernel-core-$(uname -r) | grep CVE-2026-98432

जर कमांड काहीही प्रिंट करत नसेल, तर चालू असलेला कर्नल असुरक्षित आहे.

पुढे, कोणत्या सेवा MPTCP द्वारे कनेक्शन स्वीकारतात ते तपासा. दाखवलेल्या हल्ल्यात यांसारखे सर्व्हर लक्ष्य होते:

ss -lnMp

रिक्त आउटपुटचा अर्थ असा आहे की कोणतेही MPTCP लिसनर्स नाहीत.

पायरी २. दुरुस्त केलेला कर्नल स्थापित करा.

कर्नेल अद्ययावत करण्यापूर्वी तुमच्या सर्व्हरचा बॅकअप किंवा स्नॅपशॉट घ्या.

डेबियन १२ आणि १३

दुरुस्त केलेले कर्नल सुरक्षा रिपॉझिटरीमध्ये आहेत. ते सक्षम असल्याची खात्री करा:

grep -r security.debian.org /etc/apt/sources.list /etc/apt/sources.list.d/

काहीही न आढळल्यास, जोडा security.debian.org तुमच्या रिलीजसाठी रिपॉझिटरी बदला. त्यानंतर सिस्टम अपडेट करा:

apt update
apt full-upgrade
reboot

उबंटू

सुधारित कर्नल अद्याप जारी केलेले नाहीत. अद्यतनांसाठी तपासा:

apt update
apt list --upgradable | grep linux-image

जर तुमचा सर्वर उबंटू प्रो शी जोडलेला असेल, तर तुम्ही दुरुस्ती योजना तपासू शकता:

pro fix CVE-2026-98432 --dry-run

एकदा का ही दुरुस्ती उपलब्ध झाली की, ती इन्स्टॉल करा आणि रीबूट करा.

apt update
apt full-upgrade
reboot

तोपर्यंत, पायरी ३ मधील तात्पुरते संरक्षण नक्की लागू करा.

अल्मा लिनक्स ८, ९, १०

दुरुस्त केलेले कर्नल सध्या फक्त टेस्टिंग रिपॉझिटरीमध्ये उपलब्ध आहेत. प्रोडक्शन सर्व्हरवर इन्स्टॉल करण्यास सोयीस्कर वाटत असल्यास ते इन्स्टॉल करा आणि अपडेट करण्यापूर्वी स्नॅपशॉट घ्यायला विसरू नका.

dnf install -y almalinux-release-testing
dnf update 'kernel*' --enablerepo=almalinux-testing
dnf config-manager --disable almalinux-testing
reboot

रीबूट केल्यानंतर, तुलना करा uname -r वरील तक्त्यातील आवृत्त्यांसह. जर तुम्हाला चाचणी पॅकेजेस स्थापित करायची नसतील, तर तात्पुरते संरक्षण लागू करा आणि मुख्य रेपॉजिटरीमध्ये दुरुस्ती येईपर्यंत प्रतीक्षा करा.

रॉकी लिनक्स आणि इतर RHEL-आधारित प्रणाली

यावर अद्याप कोणताही उपाय नाही. तुम्ही यावर लक्ष ठेवू शकता:

dnf --refresh updateinfo info --all --cves CVE-2026-98432

एकदा का ही दुरुस्ती प्रसिद्ध झाली की:

dnf update kernel
reboot

अपडेट केल्यानंतर, रीबूट करणे आवश्यक आहे.

नवीन कर्नल केवळ रीबूट केल्यानंतरच लागू होतो. रीबूटची आवश्यकता आहे की नाही हे तपासण्यासाठी:

# Debian and Ubuntu
[ -f /var/run/reboot-required ] && echo "Reboot required"

# AlmaLinux, Rocky, RHEL
needs-restarting -r

रीबूट केल्यानंतर, पायरी १ पासून तपासणी पुन्हा करा.

पायरी ३. सुधारित कर्नल उपलब्ध होईपर्यंत तात्पुरते संरक्षण

या उपायांमुळे धोका कमी होतो, परंतु ते कर्नल अपडेटची जागा घेत नाहीत.

ट्रिगर पॅकेट्स ब्लॉक करा

हा हल्ला IPv4 हेडरमध्ये IP पर्यायांसह TCP पॅकेट्स वापरतो. ते सामान्य ट्रॅफिकमध्ये जवळजवळ कधीच दिसत नाहीत आणि RFC 7126 आधीच त्यांना ड्रॉप करण्याची शिफारस करते. खालील nftables नियम पर्यायांसह येणारी सर्व IPv4 TCP पॅकेट्स ड्रॉप करतो आणि IPv6, UDP किंवा ICMP वर परिणाम करत नाही. हे ufw आणि firewalld सोबत काम करते.

nftables आधीपासून इन्स्टॉल केलेले नसल्यास ते इन्स्टॉल करा:

# Debian and Ubuntu
apt install -y nftables

# AlmaLinux, Rocky, RHEL
dnf install -y nftables

नियम फाईल तयार करा:

cat > /etc/cve-2026-98432.nft <<'EOF'
table ip cve_2026_98432 {
    chain pre {
        type filter hook prerouting priority -300; policy accept;
        meta l4proto tcp ip hdrlength gt 5 counter drop
    }
}
EOF

प्रत्येक रीबूटनंतर नियम पुनर्संचयित करण्यासाठी, एक systemd सेवा तयार करा:

cat > /etc/systemd/system/cve-2026-98432.service <<'EOF'
[Unit]
Description=Mitigation for CVE-2026-98432
After=network-pre.target nftables.service firewalld.service ufw.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=-/usr/sbin/nft delete table ip cve_2026_98432
ExecStart=/usr/sbin/nft -f /etc/cve-2026-98432.nft
ExecStop=/usr/sbin/nft delete table ip cve_2026_98432

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now cve-2026-98432.service

नियम लोड झाला आहे का ते तपासा:

nft list table ip cve_2026_98432

जर तुम्ही nftables सेवा ग्लोबल सह रीस्टार्ट केली तर flush ruleset नियम, चालवा systemctl restart cve-2026-98432 त्यानंतर.

महत्त्वाची सूचना: CIPSO लेबल्स (SELinux किंवा Smack NetLabel) वापरणाऱ्या नेटवर्क्सवर हा नियम लागू करू नका — तिथे सामान्यतः IP ऑप्शन्स वापरले जातात. जर तुमचा सर्व्हर इतर मशीन्ससाठी ट्रॅफिक राउट करत असेल, तर हा नियम IP ऑप्शन्स असलेले त्यांचे TCP पॅकेट्ससुद्धा ड्रॉप करेल.

गरज नसल्यास MPTCP अक्षम करा.

sysctl -w net.mptcp.enabled=0
echo "net.mptcp.enabled = 0" > /etc/sysctl.d/99-disable-mptcp.conf

ही सेटिंग फक्त प्रतिबंधित करते नवीन MPTCP सॉकेट्स तयार होण्यापासून थांबवा. ज्या सेवा आधीपासून चालू आहेत त्या MPTCP द्वारे ऐकत राहतील, म्हणून खालील यादीतील प्रत्येक सेवा पुन्हा सुरू करा. ss -lnMp आणि त्याचा आउटपुट आता रिकामा असल्याची खात्री करा.

AlmaLinux वर, MPTCP डीफॉल्टनुसार अक्षम केलेले असते, जोपर्यंत तुम्ही ते स्वतः सक्षम करत नाही.

Go प्रोग्रॅममध्ये MPTCP अक्षम करा

Go 1.24 किंवा त्यानंतरच्या आवृत्तीने तयार केलेल्या सेवांसाठी, तुम्ही एन्व्हायर्नमेंट व्हेरिएबल वापरून MPTCP अक्षम करू शकता. उदाहरणार्थ, नावाच्या सेवेसाठी myservice:

systemctl edit myservice

उघडणाऱ्या फाईलमध्ये खालील गोष्टी जोडा:

[Service]
Environment=GODEBUG=multipathtcp=0

त्यानंतर सेवा पुन्हा सुरू करा.

systemctl restart myservice

एक्स-रे अपडेट करा

जर तुमचा सर्व्हर एक्स-रे (Xray) वापरत असेल, तर त्याला v26.10.31 किंवा त्यानंतरच्या आवृत्तीवर अद्ययावत करा. मागील आवृत्ती, v26.10.29, तिच्या विकसकांनी मागे घेतली आहे. हे अद्ययावतीकरण MPTCP अक्षम करते परंतु कर्नल दुरुस्त करत नाही, त्यामुळे कर्नल अद्ययावत करणे अजूनही आवश्यक आहे.

आणखी एक सेटिंग तपासा

शोषणाचा दुसरा, अधिक मर्यादित मार्ग वापरण्यासाठी रिक्वेस्ट मायग्रेशन सक्षम करणे आवश्यक आहे. ते डीफॉल्टनुसार बंद असते — याची खात्री करून घ्या:

sysctl net.ipv4.tcp_migrate_req

कमांडने प्रिंट केले पाहिजे 0.

तुमच्या सेवांवरील प्रवेश प्रतिबंधित करा

इंटरनेटवरून पोहोचता न येणारे प्रत्येक फायरवॉल पोर्ट बंद करा. शक्य असेल तिथे, प्रशासकीय सेवा — SSH, कंट्रोल पॅनल, डेटाबेस — केवळ विश्वसनीय IP पत्त्यांसाठीच उघडा.

पायरी ४. दुरुस्त केलेला कर्नल स्थापित केल्यानंतर

1. सर्व्हर रीबूट करा आणि दुरुस्त केलेला कर्नल चालू असल्याची खात्री करण्यासाठी पायरी 1 मधील कमांड वापरा.
2. तुम्ही तात्पुरता नियम काढून टाकू शकता:
   

   systemctl disable --now cve-2026-98432.service
   rm /etc/systemd/system/cve-2026-98432.service /etc/cve-2026-98432.nft
   systemctl daemon-reload

   
   
3. तुम्हाला MPTCP ची गरज असल्यास, सेटिंग पूर्ववत करा: हटवा /etc/sysctl.d/99-disable-mptcp.conf आणि धाव sysctl -w net.mptcp.enabled=1.

जर काही चूक झाली तर

कर्नल अपडेटनंतर तुमचा सर्व्हर बूट होत नसल्यास, कंट्रोल पॅनेलमधील VNC कन्सोलद्वारे कनेक्ट करा आणि बूट मेन्यूमध्ये मागील कर्नल निवडा. हे तुम्ही स्वतः करू शकाल की नाही याची तुम्हाला खात्री नसल्यास, किंवा अपडेटसाठी मदतीची आवश्यकता असल्यास, आमच्या सपोर्ट टीमशी संपर्क साधा.