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 پیکٹ بلاک کریں، اور استعمال نہ ہونے والے پورٹس بند کریں۔
  • درست کیا گیا کرنل جاری ہوتے ہی انسٹال کریں اور ری بوٹ کریں؛ عارضی اقدامات اس کی جگہ نہیں لے سکتے۔

ذرائع