CVE-2026-31431 چیست؟ راهنمای کامل رفع آسیب‌پذیری Copy Fail در لینوکس

سطح: متوسط تا حرفه‌ای | مناسب برای: مدیران سرور لینوکس، شرکت‌های هاستینگ، مدیران cPanel و CloudLinux، مدیران DevOps، مدیران Kubernetes، مدیران سرورهای VPS و اختصاصی، و افرادی که سرورهای چندکاربره یا کانتینری لینوکس را مدیریت می‌کنند

CVE-2026-31431 که با نام Copy Fail هم شناخته می‌شود، یکی از آسیب‌پذیری‌های مهم کرنل لینوکس است که در سال ۲۰۲۶ توجه زیادی به خود جلب کرد. این آسیب‌پذیری از نوع Local Privilege Escalation است؛ یعنی مهاجم برای سوءاستفاده از آن باید ابتدا نوعی دسترسی محلی یا امکان اجرای کد روی سیستم داشته باشد، اما بعد از آن می‌تواند از کاربر عادی به سطح root برسد.

اهمیت این CVE در این است که فقط یک توزیع خاص لینوکس را هدف نمی‌گیرد. طبق گزارش‌های منتشرشده توسط AlmaLinux، CloudLinux، Microsoft، Ubuntu، SUSE و سایر منابع امنیتی، این مشکل به کرنل لینوکس و زیرسیستم رمزنگاری آن مربوط است و طیف گسترده‌ای از توزیع‌های لینوکسی، مخصوصاً کرنل‌های ساخته‌شده از حدود سال ۲۰۱۷ به بعد، می‌توانند در معرض آن باشند.

برای شرکت‌های هاستینگ و مدیران سرور، این آسیب‌پذیری بسیار جدی است؛ چون در سرورهای چندکاربره، سرورهای هاست لینوکس، محیط‌های CloudLinux، سرورهای CI/CD، کانتینرها، Kubernetes nodeها و سرورهایی که کاربران غیرقابل اعتماد به shell یا اجرای کد دسترسی دارند، یک LPE قابل اعتماد می‌تواند به compromise کامل سرور منجر شود.

در این مقاله توضیح می‌دهیم CVE-2026-31431 چیست، چرا به آن Copy Fail گفته می‌شود، چطور کار می‌کند، کدام محیط‌ها بیشتر در خطر هستند، وضعیت پچ در AlmaLinux، CloudLinux، Ubuntu، Debian، SUSE و RHEL چیست، چه دستورهایی برای بررسی و آپدیت باید اجرا شود، و اگر فعلاً امکان آپدیت کرنل ندارید چه mitigation موقتی باید در نظر بگیرید.

منابع اصلی این مقاله: اطلاعیه‌های رسمی CloudLinux، AlmaLinux، Microsoft Security Blog، Ubuntu Security، SUSE Security و Debian Security Tracker.

فهرست مطالب

• CVE-2026-31431 یا Copy Fail چیست؟
• چرا Copy Fail خطرناک است؟
• خلاصه فنی آسیب‌پذیری بدون ورود به جزئیات Exploit
• آیا CVE-2026-31431 از راه دور قابل سوءاستفاده است؟
• کدام سیستم‌ها بیشتر در معرض خطر هستند؟
• اثر CVE-2026-31431 روی شرکت‌های هاستینگ
• ریسک در کانتینرها، Kubernetes و CI/CD
• مرحله ۱: بررسی نسخه کرنل لینوکس
• رفع CVE-2026-31431 در AlmaLinux
• رفع CVE-2026-31431 در CloudLinux و KernelCare
• رفع CVE-2026-31431 در Ubuntu
• رفع CVE-2026-31431 در Debian
• رفع CVE-2026-31431 در SUSE و openSUSE
• وضعیت RHEL، Rocky Linux و Oracle Linux
• Mitigation موقت در صورت عدم امکان آپدیت فوری
• چرا بعضی workaroundها ممکن است بی‌اثر باشند؟
• بعد از آپدیت چه چیزهایی را بررسی کنیم؟
• اگر احتمال سوءاستفاده وجود دارد چه کنیم؟
• چک‌لیست فوری مدیران سرور
• سوالات متداول

CVE-2026-31431 یا Copy Fail چیست؟

CVE-2026-31431 یک آسیب‌پذیری در کرنل لینوکس است که به زیرسیستم رمزنگاری و مسیر algif_aead / AF_ALG مربوط می‌شود. این آسیب‌پذیری با نام Copy Fail شناخته می‌شود و طبق گزارش‌های منتشرشده، می‌تواند به یک کاربر محلی غیرمجاز امکان ارتقا به root بدهد.

در ساده‌ترین توضیح، این آسیب‌پذیری به یک خطای منطقی در نحوه مدیریت عملیات رمزنگاری و کپی داده در کرنل مربوط است. مهاجم محلی می‌تواند از تعامل میان AF_ALG و syscallهایی مثل splice() سوءاستفاده کند و باعث تغییر کنترل‌شده در page cache شود؛ تغییری که می‌تواند روی اجرای باینری‌های حساس اثر بگذارد و در نهایت به اجرای کد با سطح دسترسی root منجر شود.

نام Copy Fail به این دلیل انتخاب شده که ریشه مشکل به failure یا خطا در مسیر کپی/مدیریت داده در عملیات کرنل مربوط است. این آسیب‌پذیری از نوع remote نیست؛ اما اگر مهاجم به هر شکلی بتواند روی سیستم کد اجرا کند، مثلاً از طریق SSH، یک کانتینر آلوده، یک job در CI/CD یا یک اکانت هاست compromise شده، می‌تواند از آن برای ارتقا به root استفاده کند.

چرا Copy Fail خطرناک است؟

همه آسیب‌پذیری‌های local privilege escalation به یک اندازه خطرناک نیستند. Copy Fail به چند دلیل بسیار مهم است:

• روی طیف گسترده‌ای از کرنل‌های لینوکس اثر می‌گذارد.
• برای سوءاستفاده نیاز به سطح دسترسی root ندارد؛ یک کاربر محلی عادی کافی است.
• در محیط‌های چندکاربره، هاستینگ، CI/CD و کانتینرها ریسک بالاتری دارد.
• طبق گزارش‌ها، exploit عمومی و کم‌حجم برای آن منتشر شده است.
• به‌صورت مستقیم با کرنل و مرزهای privilege درگیر است.
• در بعضی سناریوها می‌تواند به container escape یا compromise کامل host کمک کند.

برای یک سرور شخصی که هیچ کاربر غیرقابل اعتمادی روی آن shell ندارد، ریسک عملی کمتر از یک سرور هاستینگ چندکاربره است. اما همچنان اگر یک وب‌اپلیکیشن آسیب‌پذیر، اسکریپت مخرب، کاربر compromise شده یا کانتینر آلوده وجود داشته باشد، این آسیب‌پذیری می‌تواند مرحله بعدی حمله باشد.

خلاصه فنی آسیب‌پذیری بدون ورود به جزئیات Exploit

این مقاله وارد ارائه کد exploit یا مراحل سوءاستفاده نمی‌شود. اما برای درک ریسک، دانستن خلاصه فنی مفید است.

Copy Fail در بخش رمزنگاری کرنل لینوکس و مسیر algif_aead رخ می‌دهد. این بخش به کاربران فضای کاربر اجازه می‌دهد از API رمزنگاری کرنل از طریق socket interface استفاده کنند. مشکل از جایی ایجاد می‌شود که یک بهینه‌سازی قدیمی در عملیات in-place باعث رفتار ناامن در مدیریت حافظه و page cache می‌شود.

در گزارش‌های فنی آمده که مهاجم می‌تواند یک write کوچک و کنترل‌شده در page cache ایجاد کند. نکته خطرناک این است که این تغییر الزاماً روی فایل دیسک نوشته نمی‌شود؛ بلکه در حافظه و page cache رخ می‌دهد. به همین دلیل برخی ابزارهای integrity checking که فقط فایل روی دیسک را مقایسه می‌کنند، ممکن است چیزی تشخیص ندهند.

این مسئله باعث می‌شود در محیط‌های حساس، فقط اتکا به checksum فایل‌ها کافی نباشد. راهکار اصلی، نصب کرنل پچ‌شده یا mitigation رسمی vendor است.

آیا CVE-2026-31431 از راه دور قابل سوءاستفاده است؟

خیر، این آسیب‌پذیری به‌تنهایی یک آسیب‌پذیری remote نیست. مهاجم برای سوءاستفاده باید بتواند روی سیستم آسیب‌پذیر کد اجرا کند یا دسترسی محلی داشته باشد. اما این موضوع نباید باعث کوچک شمردن خطر شود.

در دنیای واقعی، مهاجم‌ها معمولاً حمله را زنجیره‌ای انجام می‌دهند. مثلاً:

• ابتدا از یک آسیب‌پذیری در وب‌اپلیکیشن shell محدود می‌گیرند.
• یا یک اکانت SSH ضعیف را compromise می‌کنند.
• یا یک container workload مخرب اجرا می‌کنند.
• یا در CI/CD یک job مخرب وارد pipeline می‌کنند.

بعد از این foothold اولیه، یک LPE مثل Copy Fail می‌تواند به مهاجم کمک کند از کاربر محدود به root برسد. بنابراین برای سرورهایی که چند کاربر، چند سایت یا چند کانتینر دارند، این CVE بسیار جدی است.

کدام سیستم‌ها بیشتر در معرض خطر هستند؟

به‌صورت کلی، هر سیستم لینوکسی با کرنل آسیب‌پذیر و امکان اجرای کد توسط کاربر غیرمجاز یا workload غیرقابل اعتماد می‌تواند در معرض خطر باشد.

محیط‌های پرریسک‌تر:

• سرورهای هاستینگ اشتراکی
• سرورهای CloudLinux و cPanel چندکاربره
• سرورهای دارای SSH برای کاربران متعدد
• CI/CD runnerها و build serverها
• کانتینرها و Kubernetes nodeها
• سرورهای اجرای کد، sandbox یا تست
• سرورهایی که روی آن‌ها کاربران غیرقابل اعتماد دسترسی shell دارند
• محیط‌هایی که containerهای کاربران مختلف روی یک host اجرا می‌شوند

اگر سرور شما فقط یک سایت ساده دارد و هیچ کاربر دیگری روی آن دسترسی shell ندارد، هنوز باید آپدیت کنید؛ اما اولویت فوری‌تر با سرورهای multi-tenant و cloud/container است.

اثر CVE-2026-31431 روی شرکت‌های هاستینگ

برای شرکت‌های هاستینگ، Copy Fail یک رخداد بسیار مهم است. در سرورهای هاست اشتراکی، خرید هاست لینوکس، سرورهای cPanel، DirectAdmin، Plesk و CloudLinux، کاربران مختلف روی یک kernel مشترک اجرا می‌شوند. اگر یکی از کاربران بتواند exploit را اجرا کند، ریسک کل سرور مطرح می‌شود.

این موضوع برای سرویس‌های زیر اهمیت ویژه دارد:

• هاست لینوکس ایران و هاست لینوکس خارجی
• خرید هاست سی پنل
• نمایندگی هاست و reseller hosting
• هاست وردپرس ایران
• خرید هاست ووکامرس
• سرورهای Plesk، DirectAdmin و cPanel با shell access

در هاستینگ اشتراکی، حتی اگر اکثر کاربران نیت بدی نداشته باشند، یک سایت هک‌شده یا یک اکانت compromise شده می‌تواند به نقطه شروع حمله تبدیل شود. بنابراین نصب پچ کرنل یا livepatch باید در اولویت فوری قرار بگیرد.

ریسک در کانتینرها، Kubernetes و CI/CD

در کانتینرها، همه containerها معمولاً kernel میزبان را به اشتراک می‌گذارند. بنابراین اگر host kernel آسیب‌پذیر باشد، یک container آلوده یا workload مخرب می‌تواند ریسک بالاتری ایجاد کند.

سناریوهای مهم:

• اجرای containerهای untrusted روی یک host
• Kubernetes nodeهایی که workloadهای کاربران مختلف را اجرا می‌کنند
• CI runnerهایی که کدهای Pull Request یا jobهای کاربران را اجرا می‌کنند
• Platformهای build یا sandbox که کد شخص ثالث اجرا می‌کنند

در چنین محیط‌هایی، بعد از patch کردن کرنل، باید nodeها reboot یا recycle شوند تا کرنل جدید واقعاً فعال شود. فقط نصب پکیج kernel کافی نیست؛ تا وقتی سیستم با کرنل جدید boot نشده باشد، همچنان کرنل قدیمی در حال اجراست.

مرحله ۱: بررسی نسخه کرنل لینوکس

اولین قدم روی هر سرور، بررسی نسخه کرنل در حال اجراست:

uname -r

برای مشاهده اطلاعات کامل‌تر:

uname -a

برای دیدن توزیع لینوکس:

cat /etc/os-release

برای دیدن کرنل‌های نصب‌شده در سیستم‌های RPM-based:

rpm -q kernel
rpm -qa | grep '^kernel'

در Debian و Ubuntu:

dpkg -l 'linux-image*' | grep '^ii'

نکته مهم این است که نسخه نصب‌شده و نسخه در حال اجرا ممکن است متفاوت باشند. ممکن است کرنل پچ‌شده نصب شده باشد، اما سیستم هنوز reboot نشده و با کرنل آسیب‌پذیر قبلی اجرا شود. معیار اصلی وضعیت فعلی، خروجی uname -r است.

رفع CVE-2026-31431 در AlmaLinux

AlmaLinux اعلام کرده patched kernels برای نسخه‌های پشتیبانی‌شده وارد production repositories شده‌اند. بنابراین در حالت عادی دیگر نیازی به فعال کردن testing repository نیست و باید سیستم را از repositoryهای معمول به‌روزرسانی کنید.

دستور پیشنهادی عمومی برای AlmaLinux:

sudo dnf clean metadata
sudo dnf upgrade
sudo reboot

بعد از reboot:

uname -r

طبق اعلام AlmaLinux، نسخه‌های پچ‌شده به این صورت هستند:

اگر mirror شما هنوز آپدیت را نشان نمی‌دهد، کمی صبر کنید، metadata را پاک کنید و دوباره تلاش کنید. در محیط production، قبل از reboot حتماً مطمئن شوید سرویس‌های حیاتی، فایل‌سیستم‌ها و bootloader وضعیت سالم دارند.

منبع رسمی: AlmaLinux – Copy Fail CVE-2026-31431 Patches Released

رفع CVE-2026-31431 در CloudLinux و KernelCare

CloudLinux برای این CVE چند مسیر ارائه کرده است، چون وضعیت نسخه‌ها متفاوت است. طبق اطلاعیه CloudLinux، وضعیت کلی به این صورت است:

برای CloudLinux 9 و 10 که از کرنل AlmaLinux استفاده می‌کنند، دستور عمومی بعد از انتشار در production repositories:

sudo dnf clean metadata
sudo dnf upgrade
sudo reboot

برای CloudLinux 8 و CL7h، بسته به وضعیت انتشار stable یا testing repository، ممکن است لازم باشد دستورهای CloudLinux را مطابق اطلاعیه رسمی دنبال کنید. برای CL8، نمونه دستور testing channel که CloudLinux ذکر کرده بود:

yum --enablerepo=cloudlinux-updates-testing update 'kernel*'
reboot
uname -r

برای CL7h نیز مسیر beta جداگانه اعلام شده بود:

yum --enablerepo=cl7h_beta update 'kernel*'
reboot
uname -r

اگر از KernelCare استفاده می‌کنید، CloudLinux اعلام کرده livepatchها برای تعداد زیادی از توزیع‌ها منتشر شده یا در حال انتشار هستند. دستورهای بررسی KernelCare:

kcarectl --update
kcarectl --info | grep CVE-2026-31431

یا برای دیدن patch info:

kcarectl --patch-info | grep CVE-2026-31431

KernelCare می‌تواند در سرورهایی که reboot فوری سخت است بسیار مفید باشد، اما همچنان باید مطمئن شوید خروجی ابزار نشان می‌دهد CVE پچ شده است.

منبع رسمی: CloudLinux – CVE-2026-31431 Kernel Update

رفع CVE-2026-31431 در Ubuntu

Ubuntu اعلام کرده این آسیب‌پذیری با امتیاز CVSS 7.8 و شدت High شناسایی شده و روی نسخه‌های Ubuntu قبل از Resolute 26.04 اثر دارد. Ubuntu Security Team برای برخی نسخه‌ها mitigation از طریق بسته kmod ارائه کرده که ماژول آسیب‌پذیر را غیرفعال می‌کند و سپس kernel packageهای پچ‌شده منتشر می‌شوند.

دستور عمومی توصیه‌شده Ubuntu برای آپدیت:

sudo apt update
sudo apt upgrade

اگر می‌خواهید فقط بسته mitigation مربوط را هدف بگیرید:

sudo apt update
sudo apt install --only-upgrade kmod

برای بررسی کرنل فعلی:

uname -r

برای دیدن kernel imageهای نصب‌شده:

dpkg -l 'linux-image*' | grep '^ii'

برای بررسی نسخه kmod:

dpkg -l kmod

Ubuntu اشاره کرده که reboot باعث اعمال مطمئن mitigation می‌شود. اگر reboot فوری ممکن نیست، باید مطابق راهنمای رسمی بررسی کنید که ماژول آسیب‌پذیر loaded نباشد؛ اما برای سرورهای production، reboot کنترل‌شده بعد از آپدیت معمولاً مسیر مطمئن‌تر است.

منبع رسمی: Ubuntu – Fixes available for CVE-2026-31431

رفع CVE-2026-31431 در Debian

Debian وضعیت بسته‌های آسیب‌پذیر و نسخه‌های fixed را در Security Tracker خود منتشر کرده است. طبق tracker رسمی Debian، برای releaseهایی مثل bullseye، bookworm و trixie نسخه‌های security fixed ارائه شده‌اند.

دستور عمومی برای Debian:

sudo apt update
sudo apt full-upgrade
sudo reboot

برای بررسی نسخه کرنل فعلی:

uname -r

برای بررسی بسته‌های kernel نصب‌شده:

dpkg -l 'linux-image*' | grep '^ii'

اگر از Debian روی سرور production استفاده می‌کنید، مطمئن شوید security repository فعال است. در غیر این صورت ممکن است updateهای امنیتی را دریافت نکنید.

منبع رسمی: Debian Security Tracker – CVE-2026-31431

رفع CVE-2026-31431 در SUSE و openSUSE

SUSE اعلام کرده Copy Fail یک آسیب‌پذیری مهم در کرنل لینوکس است که به کاربر محلی non-root امکان گرفتن root access می‌دهد. طبق بلاگ SUSE، نسخه‌های مختلف SLES، SL Micro، openSUSE Leap و SUSE Liberty Linux در بازه‌های مشخص affected بوده‌اند و SUSE برای توزیع‌های نگهداری‌شده خود آپدیت منتشر کرده است.

برای SUSE Linux Enterprise، مسیر کلی آپدیت معمولاً از طریق zypper است:

sudo zypper refresh
sudo zypper patch
sudo reboot

برای openSUSE:

sudo zypper refresh
sudo zypper update
sudo reboot

بعد از reboot:

uname -r

اگر از Rancher، RKE2، K3s یا Harvester استفاده می‌کنید، فقط خود cluster layer را بررسی نکنید؛ چون آسیب‌پذیری در kernel میزبان است. nodeهای underlying باید پچ شوند و در محیط‌های Kubernetes، node rotation یا reboot برنامه‌ریزی‌شده اهمیت دارد.

منبع رسمی: SUSE responds to Copy Fail vulnerability

وضعیت RHEL، Rocky Linux و Oracle Linux

Red Hat برای CVE-2026-31431 صفحه رسمی CVE و advisoryهای مرتبط منتشر کرده است. برای RHEL، مسیر درست این است که با subscription معتبر، advisory رسمی و kernel packageهای مربوط به نسخه خود را نصب کنید.

دستور عمومی برای RHEL و توزیع‌های سازگار:

sudo dnf clean metadata
sudo dnf upgrade
sudo reboot

برای Rocky Linux و Oracle Linux نیز باید اطلاعیه رسمی همان vendor یا repository فعال سیستم را بررسی کنید. CloudLinux در اطلاعیه KernelCare خود اعلام کرده livepatch برای Rocky Linux، Oracle Linux و چند توزیع دیگر نیز در feedهای مختلف منتشر شده است؛ اما اگر از livepatch استفاده نمی‌کنید، باید kernel package رسمی توزیع خودتان را نصب و سیستم را reboot کنید.

برای بررسی وضعیت:

uname -r
rpm -qa | grep '^kernel'

در Oracle Linux، اگر از UEK استفاده می‌کنید، حتماً وضعیت UEK kernel و advisoryهای Oracle را جداگانه بررسی کنید. در برخی سیستم‌ها ممکن است چند kernel نصب باشد اما سیستم با یکی از آن‌ها boot شود.

Mitigation موقت در صورت عدم امکان آپدیت فوری

راهکار اصلی همیشه نصب کرنل پچ‌شده یا livepatch رسمی vendor است. اما اگر فعلاً امکان آپدیت یا reboot ندارید، برخی vendorها mitigation موقت برای بستن سطح حمله مربوط به algif_aead ارائه کرده‌اند.

CloudLinux برای RHEL-family و CloudLinux/AlmaLinux مسیر مبتنی بر grubby را پیشنهاد کرده است:

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot

بعد از reboot، بررسی کنید پارامتر روی kernel command line اعمال شده باشد:

sudo grubby --info=ALL | grep initcall_blacklist

برای بازگردانی بعد از نصب کرنل پچ‌شده:

sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo reboot

Ubuntu مسیر متفاوتی ارائه کرده که از طریق update بسته kmod یا در صورت نیاز manual modprobe rule انجام می‌شود. اما CloudLinux هشدار داده در خانواده RHEL، workaround مبتنی بر modprobe.d ممکن است کار نکند، چون algif_aead در بسیاری از این کرنل‌ها built-in است، نه loadable module.

نکته مهم: mitigation موقت را فقط مطابق راهنمای vendor توزیع خودتان اجرا کنید. یک دستور که برای Ubuntu مناسب است، الزاماً برای CloudLinux، AlmaLinux یا RHEL مناسب نیست.

چرا بعضی workaroundها ممکن است بی‌اثر باشند؟

در برخی منابع اولیه، پیشنهاد شده بود با ساختن فایل در /etc/modprobe.d/ و جلوگیری از load شدن algif_aead مشکل رفع شود. اما CloudLinux به‌صراحت هشدار داده که این روش در CloudLinux، AlmaLinux و بسیاری از توزیع‌های RHEL-family بی‌اثر است؛ چون algif_aead به‌صورت built-in داخل kernel کامپایل شده است.

برای بررسی اینکه ماژول built-in است یا نه:

modinfo algif_aead | grep filename

اگر خروجی چیزی شبیه (builtin) باشد، یعنی modprobe rule جلوی load شدن آن را نمی‌گیرد، چون چیزی برای load/unload وجود ندارد. در این حالت باید از mitigation مناسب vendor مثل initcall_blacklist یا نصب کرنل پچ‌شده استفاده کنید.

این نکته برای مدیران سرور مهم است، چون اجرای workaround اشتباه ممکن است حس امنیت کاذب ایجاد کند؛ در حالی که سیستم همچنان vulnerable است.

بعد از آپدیت چه چیزهایی را بررسی کنیم؟

بعد از نصب آپدیت کرنل یا livepatch، فقط به پیام موفقیت package manager اکتفا نکنید. این موارد را بررسی کنید:

• نسخه کرنل در حال اجرا با uname -r
• کرنل‌های نصب‌شده با rpm -q kernel یا dpkg -l
• وضعیت reboot شدن سیستم
• در صورت استفاده از KernelCare، وضعیت CVE در kcarectl --info
• وضعیت سرویس‌های اصلی بعد از reboot
• لاگ‌های boot و kernel
• وضعیت containerها و Kubernetes nodeها

دستورهای مفید:

uname -r
uptime
journalctl -k -b --no-pager | tail -n 100
systemctl --failed

در سرورهای هاستینگ، بعد از reboot باید سرویس‌های اصلی مثل وب‌سرور، دیتابیس، ایمیل، DNS، کنترل پنل و firewall را بررسی کنید.

اگر احتمال سوءاستفاده وجود دارد چه کنیم؟

چون Copy Fail یک LPE است، اگر مهاجم قبل از پچ به هر شکلی دسترسی local داشته باشد، احتمال ارتقا به root مطرح می‌شود. بنابراین در محیط‌های پرریسک، صرفاً آپدیت کردن ممکن است کافی نباشد.

اگر نشانه‌هایی از compromise دارید:

• لاگ‌های SSH، sudo، auditd و system را حفظ کنید.
• کاربران جدید یا غیرعادی را بررسی کنید.
• فایل‌های authorized_keys کاربران را بررسی کنید.
• cron jobهای root و کاربران را بررسی کنید.
• processهای مشکوک و binaryهای غیرعادی را بررسی کنید.
• containerها و imageهای مشکوک را قرنطینه کنید.
• در محیط‌های Kubernetes، nodeهای مشکوک را drain و rebuild کنید.
• در صورت احتمال root compromise، به rebuild از image تمیز فکر کنید.

چون بخشی از اثر این آسیب‌پذیری می‌تواند در حافظه باشد و بعد از reboot رد مستقیم روی دیسک باقی نگذارد، بررسی incident باید با دید post-exploitation انجام شود؛ یعنی به دنبال persistence، userهای جدید، cron، SSH key، serviceهای جدید و تغییرات پیکربندی باشید.

چک‌لیست فوری مدیران سرور

جمع‌بندی

CVE-2026-31431 / Copy Fail یک آسیب‌پذیری مهم در کرنل لینوکس است که می‌تواند به کاربر محلی غیرمجاز امکان ارتقا به root بدهد. این آسیب‌پذیری به‌تنهایی remote نیست، اما در دنیای واقعی می‌تواند با دسترسی اولیه از طریق SSH، وب‌اپلیکیشن، کانتینر، CI/CD یا اکانت compromise شده ترکیب شود و به compromise کامل سیستم منجر شود.

برای مدیران سرور، مخصوصاً در محیط‌های هاست لینوکس، CloudLinux، cPanel، Kubernetes، CI/CD و سرورهای چندکاربره، اقدام فوری لازم است. ابتدا نسخه کرنل را با uname -r بررسی کنید، سپس طبق راهنمای vendor کرنل را آپدیت کنید یا livepatch رسمی را اعمال کنید و در نهایت سیستم را reboot یا وضعیت livepatch را تأیید کنید.

اگر امکان آپدیت فوری ندارید، mitigation موقت فقط باید مطابق راهنمای رسمی توزیع خودتان انجام شود. برای CloudLinux و AlmaLinux و خانواده RHEL، به هشدار مربوط به بی‌اثر بودن workaroundهای modprobe توجه کنید. برای Ubuntu، راهنمای رسمی kmod mitigation را دنبال کنید. برای Debian، SUSE، RHEL، Oracle و Rocky هم وضعیت fixed package را از منابع رسمی همان توزیع بررسی کنید.

در نهایت، اگر احتمال می‌دهید قبل از پچ، روی سرور اجرای کد غیرقابل اعتماد انجام شده یا container/کاربر مشکوک وجود داشته، فقط آپدیت کافی نیست. باید سرور را از نظر نشانه‌های post-exploitation، persistence، SSH keyهای مشکوک، cron jobها و کاربران غیرعادی بررسی کنید و در محیط‌های حساس، rebuild از image تمیز را در نظر بگیرید.

سوالات متداول

CVE-2026-31431 چیست؟

CVE-2026-31431 یا Copy Fail یک آسیب‌پذیری Local Privilege Escalation در کرنل لینوکس است که به زیرسیستم رمزنگاری و مسیر algif_aead / AF_ALG مربوط می‌شود و می‌تواند به کاربر محلی اجازه ارتقا به root بدهد.

آیا Copy Fail از راه دور قابل سوءاستفاده است؟

به‌تنهایی خیر. مهاجم باید بتواند روی سیستم کد اجرا کند یا دسترسی محلی داشته باشد. اما اگر با یک دسترسی اولیه مثل SSH، وب‌شل، CI job یا کانتینر آلوده ترکیب شود، بسیار خطرناک است.

کدام سرورها بیشتر در خطر هستند؟

سرورهای چندکاربره، هاستینگ اشتراکی، CloudLinux، CI/CD runnerها، Kubernetes nodeها، محیط‌های container و سیستم‌هایی که کاربران غیرقابل اعتماد روی آن‌ها کد اجرا می‌کنند، بیشترین ریسک را دارند.

چطور بفهمم کرنل فعلی سرور چیست؟

با دستور uname -r نسخه کرنل در حال اجرا را می‌بینید. برای اطلاعات کامل‌تر می‌توانید uname -a و cat /etc/os-release را هم اجرا کنید.

آیا فقط نصب آپدیت کرنل کافی است؟

نصب پکیج کرنل کافی نیست؛ باید سیستم با کرنل جدید boot شود. بنابراین معمولاً reboot لازم است، مگر اینکه از livepatch معتبر مثل KernelCare استفاده کنید و وضعیت پچ را تأیید کرده باشید.

برای AlmaLinux چه کار کنیم؟

طبق اعلام AlmaLinux، patched kernels وارد production repositories شده‌اند. معمولاً باید sudo dnf clean metadata && sudo dnf upgrade را اجرا کنید و سپس سیستم را reboot کنید.

برای Ubuntu چه کار کنیم؟

Ubuntu mitigationهایی از طریق بسته kmod و سپس kernel update ارائه کرده است. دستور عمومی sudo apt update && sudo apt upgrade است و در صورت نیاز می‌توان kmod را جداگانه upgrade کرد.

برای CloudLinux چه کار کنیم؟

بسته به نسخه CloudLinux، مسیر متفاوت است. CL7h و CL8 از CloudLinux kernel استفاده می‌کنند و CL9/CL10 از AlmaLinux kernel. اگر KernelCare دارید، وضعیت CVE را با kcarectl --info | grep CVE-2026-31431 بررسی کنید.

آیا workaround modprobe.d برای همه توزیع‌ها جواب می‌دهد؟

خیر. CloudLinux هشدار داده که در CloudLinux، AlmaLinux و خانواده RHEL، چون algif_aead معمولاً built-in است، workaround مبتنی بر modprobe.d ممکن است بی‌اثر باشد. باید راهنمای رسمی همان vendor را دنبال کنید.

بعد از آپدیت چه چیزی را بررسی کنم؟

خروجی uname -r، وضعیت سرویس‌ها، لاگ‌های boot، وضعیت livepatch در صورت استفاده، و در محیط‌های کانتینری وضعیت nodeها و workloadها را بررسی کنید.