آسیب‌پذیری ارتقا امتیاز Fragnesia در هسته لینوکس (CVE-2026-46300)؛ کدام نسخه‌ها آسیب‌پذیرند و چطور وصله کنیم
آسیب‌پذیری هسته لینوکس با نام Fragnesia و شناسه CVE-2026-46300 به فهرست آسیب‌پذیری‌های فعالانه اکسپلویت‌شده CISA اضافه شده و تیم‌های زیرساخت باید هرچه سریع‌تر وضعیت سرورهای خود را بررسی کنند. در این مطلب می‌بینید این باگ دقیقا چیست، کدام توزیع‌ها و نسخه‌های کرنل را درگیر می‌کند، و چطور وصله یا مقابله موقت کنید.
چه اتفاقی افتاده است؟
CISA در تاریخ ۲۸ اکتبر ۲۰۲۶ (۲۸ مهر ۱۴۰۵) این آسیب‌پذیری را به کاتالوگ Known Exploited Vulnerabilities (KEV) اضافه کرد و برای سازمان‌های فدرال آمریکا مهلت اقدام را ۳۱ اکتبر ۲۰۲۶ تعیین کرد. دلیل این فوریت، شواهد مستند از سوءاستفاده واقعی از این باگ در محیط‌های عملیاتی است، به‌ویژه در ترکیب با یک زنجیره نفوذ دیگر به نام PHP2Shell.
Fragnesia دقیقا چیست؟
Fragnesia یک نسخه جدید از خانواده باگ‌های قبلا شناخته‌شده با نام «Dirty Frag» است و در زیرسیستم XFRM مربوط به ESP-over-TCP در هسته لینوکس قرار دارد. مشکل در تابع skb_try_coalesce() است: این تابع می‌تواند فرگمنت‌های صفحه‌ای (paged fragments) را بین بافرهای شبکه (skb) ادغام کند بدون اینکه نشانگر «shared-frag» را حفظ کند.
نتیجه این است که پردازش ورودی ESP ممکن است داده را به‌صورت in-place روی فرگمنت‌هایی رمزگشایی کند که در واقع به page cache فایل‌های فقط‌خواندنی - از جمله باینری‌های setuid - اشاره دارند. یک کاربر محلی کم‌دسترسی، یا مهاجمی که از راه دور یک پایگاه اولیه (مثلا از طریق یک وب‌شل PHP) به دست آورده، می‌تواند از این مسیر برای نوشتن بایت‌های دلخواه روی این صفحات کش‌شده و بازنویسی باینری‌های حساس استفاده کند و دسترسی محدود را به روت کامل تبدیل کند.
برای افزایش امنیت سرور لینوکس به‌طور کلی، شناخت همین نوع مسیرهای ارتقا امتیاز در کرنل نقطه شروع خوبی است.
چرا خطرناک است؟
امتیاز CVSS 3.1 این آسیب‌پذیری برابر ۷.۸ (High) است با وکتور AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. شرکت Red Hat آن را «Important» رده‌بندی کرده، نه «Critical»، چون بردار حمله صرفا محلی است. اما نکته مهم این است:
- نیازی به تعامل کاربر ندارد
- پیچیدگی اکسپلویت پایین است
- CISA تأیید کرده که در حال سوءاستفاده فعال است
به‌خصوص وقتی این باگ با زنجیره PHP2Shell (دو آسیب‌پذیری RCE در PHP با شناسه‌های CVE-2026-109618 و CVE-2026-109619) ترکیب شود، یک مهاجم بدون هیچ حساب کاربری می‌تواند از یک وب‌شل روی سرور PHP شروع کند و در نهایت به روت کامل هاست برسد.
برای پایش همین نوع رویدادهای امنیتی روی سرور، راه‌اندازی Auditd در لینوکس کمک می‌کند تغییرات مشکوک روی فایل‌ها زودتر دیده شوند.
کدام نسخه‌ها آسیب‌پذیرند؟
پچ بالادستی با عنوان «net: skbuff: preserve shared-frag marker during coalescing» در ۱۳ می ۲۰۲۶ منتشر شد. هر توزیع به‌صورت جداگانه این پچ را در یک نسخه بیلد مشخص عرضه کرده است:
| توزیع | نسخه‌های آسیب‌پذیر | نسخه وصله‌شده |
|---|---|---|
| Ubuntu 16.04 LTS | قبل از این نسخه | 4.4.0-283.317 |
| Ubuntu 18.04 LTS | قبل از این نسخه | 4.15.0-253.265 |
| Ubuntu 20.04 LTS | قبل از این نسخه | 5.4.0-233.253 |
| Ubuntu 22.04 LTS | قبل از این نسخه | 5.15.0-181.191 |
| Ubuntu 24.04 LTS | قبل از این نسخه | 6.8.0-124.124 |
| Ubuntu 26.04 LTS | قبل از این نسخه | 7.0.0-22.22 |
| Debian bullseye | قبل از این نسخه | 5.10.257-1 |
| Debian bookworm | قبل از این نسخه | 6.1.174-1 |
| Debian trixie | قبل از این نسخه | 6.12.90-1 |
| Debian sid | قبل از این نسخه | 7.0.9-1 |
| AlmaLinux 8 | قبل از این نسخه | kernel-4.18.0-553.124.3.el8_10 |
| AlmaLinux 9 | قبل از این نسخه | kernel-5.14.0-611.54.5.el9_7 |
| AlmaLinux 10 | قبل از این نسخه | kernel-6.12.0-124.56.3.el10_1 |
RHEL 8، 9 و 10 نیز آسیب‌پذیر هستند، همین‌طور محصولات مبتنی بر RHEL مثل RHEL CoreOS، OpenShift، OpenStack Platform و Red Hat Virtualization. برای این محصولات باید از کانال به‌روزرسانی رسمی Red Hat نسخه پچ‌شده را دریافت کنید. اگر روی یکی از همین توزیع‌ها سرور لینوکس را با SELinux سخت‌سازی کرده‌اید، وصله کرنل تغییری در تنظیمات SELinux نمی‌دهد و بعد از ریبوت هم باقی می‌ماند.
چطور بررسی کنید سرور شما آسیب‌پذیر است؟
نسخه کرنل در حال اجرا را ببینید:
uname -r
روی اوبونتو یا دبیان، نسخه پکیج نصب‌شده را هم بررسی کنید:
apt list --installed | grep linux-image
روی RHEL یا AlmaLinux:
rpm -q kernel
cat /etc/os-release
نسخه خروجی را با جدول بالا مقایسه کنید. اگر نسخه شما قدیمی‌تر از عدد وصله‌شده است، سرور آسیب‌پذیر است.
چون این زنجیره با PHP2Shell هم ترکیب می‌شود، نسخه PHP را هم بررسی کنید:
php -v
چطور وصله یا مقابله کنیم؟
راه‌حل اصلی، به‌روزرسانی پکیج کرنل به نسخه وصله‌شده و ریبوت سرور است؛ این باگ در سطح کرنل است و امکان live-patch ندارد، یعنی صرف نصب پکیج کافی نیست.
# اوبونتو/دبیان
sudo apt update && sudo apt install linux-image-generic
sudo reboot
# RHEL/AlmaLinux
sudo dnf update kernel
sudo reboot
اگر ریبوت فوری ممکن نیست، طبق بولتن RHSB-2026-003 ردهت، دو راه‌حل موقت وجود دارد:
۱. مسدود کردن ماژول‌های esp4/esp6 (در صورتی که از IPsec استفاده نمی‌کنید). ابتدا بررسی کنید که این ماژول‌ها در حال استفاده نیستند:
lsmod | grep -E 'esp4|esp6'
سپس:
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf
۲. غیرفعال کردن user namespaces بدون امتیاز (اگر IPsec/esp باید فعال بماند):
echo 'user.max_user_namespaces=0' > /etc/sysctl.d/dirtyfrag.conf
چون این آسیب‌پذیری عملا با زنجیره PHP2Shell استفاده می‌شود، وصله کردن فقط کرنل کافی نیست. سرورهای PHP باید هم‌زمان به نسخه ۸.۵.۱۲، ۸.۴.۲۷، ۸.۳.۳۶ یا ۸.۲.۳۵ (یا بالاتر) ارتقا یابند؛ وصله کردن فقط یک نیمه از زنجیره، نیمه دیگر را همچنان در معرض خطر نگه می‌دارد.
روی یک سرور مجازی که مالکیت کامل آن را دارید، این فرآیند ساده‌تر است: پیش از آپدیت کرنل یک snapshot می‌گیرید، ریبوت را در زمان کم‌ترافیک انجام می‌دهید، و با فایروال سطح سرور دسترسی به سرویس‌های غیرضروری مثل IPsec را محدود می‌کنید. اگر هنوز روی یک سرور مجازی لینوکس این سطح کنترل را ندارید یا می‌خواهید محیط تست جداگانه‌ای برای اعمال این وصله راه بیندازید، حتی یک سرور مجازی لینوکس ساعتی هم برای این کار کافی است.
سؤالات متداول
آیا Fragnesia از راه دور هم قابل سوءاستفاده است؟ به‌طور مستقیم نه؛ بردار حمله محلی است. اما در عمل، مهاجمان از راه دور ابتدا از طریق PHP2Shell یک وب‌شل روی سرور می‌گذارند و سپس از Fragnesia برای رسیدن به روت استفاده می‌کنند.
آیا نصب پکیج کرنل جدید بدون ریبوت کافی است؟ خیر. این آسیب‌پذیری در سطح کرنل در حال اجراست و live-patch نمی‌شود؛ باید سرور را ریبوت کنید تا کرنل جدید بار شود.
اگر همین حالا نمی‌توانم ریبوت کنم چه کار کنم؟ طبق بولتن ردهت، می‌توانید موقتا ماژول‌های esp4/esp6 را مسدود کنید یا user namespaces بدون امتیاز را غیرفعال کنید، تا زمانی که فرصت ریبوت فراهم شود.
چطور بفهمم سرورم هنوز آسیب‌پذیر است؟
با دستور uname -r (یا rpm -q kernel روی RHEL/AlmaLinux) نسخه کرنل را بگیرید و با جدول نسخه‌های وصله‌شده در این مطلب مقایسه کنید.
