سطح: متوسط تا حرفه‌ای | مناسب برای: مدیران سرور cPanel، شرکت‌های هاستینگ، مدیران WHM، مدیران امنیت، مدیران سرور مجازی و اختصاصی، و افرادی که سرویس‌های هاست لینوکس، هاست سی‌پنل یا نمایندگی هاست ارائه می‌کنند

در تاریخ ۲۸ آوریل ۲۰۲۶، cPanel یک اطلاعیه امنیتی مهم درباره آسیب‌پذیری CVE-2026-41940 منتشر کرد. این آسیب‌پذیری از نوع Authentication Bypass معرفی شده و طبق اعلام رسمی cPanel، نرم‌افزار cPanel شامل DNSOnly را در نسخه‌های بعد از 11.40 تحت تأثیر قرار می‌دهد.

اهمیت این موضوع بسیار بالاست، چون cPanel و WHM در بسیاری از سرورهای هاستینگ، سرورهای شرکت‌ها، سرویس‌های هاست لینوکس، خرید هاست سی پنل، نمایندگی هاست و سرورهای مدیریت‌شده استفاده می‌شوند. اگر چنین آسیب‌پذیری‌ای به‌موقع پچ نشود، ممکن است ریسک دسترسی غیرمجاز به سرویس‌های مدیریتی cPanel، WHM یا Webmail افزایش پیدا کند.

در این مقاله توضیح می‌دهیم CVE-2026-41940 چیست، کدام نسخه‌های cPanel و WHM پچ دریافت کرده‌اند، چطور نسخه سرور را بررسی کنید، چه دستورهایی برای آپدیت فوری لازم است، اگر آپدیت ممکن نبود چه راهکارهای موقتی باید انجام دهید، و اگر احتمال compromise وجود دارد، چه اقداماتی برای واکنش اضطراری باید در نظر بگیرید.

منبع اصلی این مقاله اطلاعیه رسمی cPanel است: Security: CVE-2026-41940 – cPanel & WHM / WP2 Security Update

فهرست مطالب

CVE-2026-41940 چیست؟

CVE-2026-41940 یک آسیب‌پذیری امنیتی گزارش‌شده در cPanel است که طبق اطلاعیه رسمی cPanel، از نوع Authentication Bypass است. Authentication Bypass یعنی ضعف امنیتی‌ای که می‌تواند باعث دور زدن بخشی از فرآیند احراز هویت شود.

در اطلاعیه cPanel آمده که این مشکل در نرم‌افزار cPanel، از جمله DNSOnly، شناسایی شده و نسخه‌های بعد از 11.40 را تحت تأثیر قرار می‌دهد. cPanel برای شاخه‌های مشخصی از cPanel & WHM و همچنین WP Squared نسخه پچ‌شده منتشر کرده است.

در چنین رخدادهایی، مهم‌ترین اصل این است که مدیر سرور منتظر «مشاهده نشانه قطعی نفوذ» نماند. وقتی vendor رسمی پچ امنیتی فوری منتشر کرده، باید اولویت با آپدیت و کاهش سطح حمله باشد.

چرا این آسیب‌پذیری برای مدیران هاستینگ مهم است؟

cPanel و WHM روی سرورهای زیادی در صنعت میزبانی وب استفاده می‌شوند. روی یک سرور cPanel ممکن است ده‌ها یا صدها اکانت میزبانی، ایمیل، دیتابیس، فایل سایت، رکورد DNS، SSL و تنظیمات حساس وجود داشته باشد. بنابراین آسیب‌پذیری در خود لایه cPanel می‌تواند بسیار مهم‌تر از یک آسیب‌پذیری ساده در یک سایت یا افزونه باشد.

این رخداد برای این گروه‌ها اهمیت ویژه دارد:

  • شرکت‌هایی که هاست لینوکس ایران یا هاست لینوکس خارجی ارائه می‌کنند
  • ارائه‌دهندگان هاست نمایندگی و نمایندگی هاست لینوکس
  • مدیران سرورهای اختصاصی و VPS که WHM نصب کرده‌اند
  • مشتریانی که چندین سایت وردپرسی یا فروشگاهی روی یک سرور cPanel دارند
  • مدیرانی که به‌دلیل policy داخلی، آپدیت‌های cPanel را pin یا غیرفعال کرده‌اند
  • سرورهای DNSOnly که ممکن است کمتر از سرورهای اصلی مانیتور شوند

اگر شما فقط کاربر نهایی یک سرویس هاست اشتراکی هستید، معمولاً آپدیت cPanel در اختیار شما نیست و باید از شرکت هاستینگ خود درباره وضعیت پچ سؤال کنید. اما اگر مدیر WHM یا root سرور هستید، باید همین امروز وضعیت نسخه سرور را بررسی کنید.

کدام نسخه‌های cPanel تحت تأثیر قرار دارند؟

طبق اعلام cPanel، این issue همه نسخه‌های cPanel بعد از 11.40 را تحت تأثیر قرار می‌دهد. با این حال، راهکار اصلی این نیست که فقط بدانیم «آسیب‌پذیر هستیم یا نه»؛ راهکار اصلی این است که سرور به یکی از نسخه‌های پچ‌شده اعلام‌شده توسط cPanel به‌روزرسانی شود.

بنابراین اگر سرور شما cPanel & WHM دارد و نسخه آن در بازه‌های قدیمی یا pin شده است، باید نسخه فعلی را بررسی کنید و آن را با فهرست نسخه‌های patched مقایسه کنید.

برای سرورهایی که به‌روزرسانی خودکار دارند، ممکن است پچ به‌صورت خودکار اعمال شده باشد؛ اما این موضوع را حدس نزنید. حتماً نسخه build را با دستور رسمی بررسی کنید.

نسخه‌های پچ‌شده cPanel و WHM

cPanel اعلام کرده برای نسخه‌های زیر از cPanel & WHM پچ منتشر شده است:

شاخه نسخهنسخه پچ‌شده
11.8611.86.0.41
11.11011.110.0.97
11.11811.118.0.63
11.12611.126.0.54
11.13011.130.0.19
11.13211.132.0.29
11.13411.134.0.20
11.13611.136.0.5

اگر نسخه سرور شما پایین‌تر از نسخه پچ‌شده همان شاخه است، باید آپدیت انجام شود. اگر روی نسخه‌ای هستید که در این فهرست نیست، باید طبق توصیه cPanel برای به‌روزرسانی به شاخه پشتیبانی‌شده اقدام کنید.

وضعیت WP Squared و DNSOnly

در اطلاعیه cPanel، علاوه بر cPanel & WHM، به WP Squared و DNSOnly هم اشاره شده است. cPanel برای WP Squared نسخه پچ‌شده زیر را اعلام کرده است:

136.1.7

همچنین در توضیح علت، cPanel اعلام کرده این مشکل در نرم‌افزار cPanel شامل DNSOnly هم شناسایی شده است. بنابراین اگر سرور DNSOnly دارید، آن را از قلم نیندازید. بسیاری از مدیران فقط سرورهای هاستینگ اصلی را آپدیت می‌کنند و سرورهای DNSOnly یا utility serverها را دیرتر بررسی می‌کنند؛ این کار در رخدادهای امنیتی اشتباه است.

مرحله ۱: بررسی نسخه فعلی cPanel روی سرور

برای بررسی نسخه فعلی cPanel، با SSH وارد سرور شوید و دستور زیر را اجرا کنید:

/usr/local/cpanel/cpanel -V

خروجی چیزی شبیه این خواهد بود:

11.136.0.5

این عدد را با فهرست نسخه‌های پچ‌شده مقایسه کنید. اگر نسخه شما پایین‌تر است، باید آپدیت انجام شود.

همچنین بهتر است وضعیت tier را بررسی کنید:

whmapi1 get_tier

اگر سرور روی tier یا نسخه خاصی pin شده باشد، ممکن است به‌روزرسانی خودکار انجام نشده باشد.

مرحله ۲: آپدیت فوری cPanel با upcp

cPanel در اطلاعیه رسمی خود توصیه کرده سرور فوراً به یکی از نسخه‌های پچ‌شده به‌روزرسانی شود. دستور اصلی آپدیت:

/scripts/upcp --force

اجرای این دستور ممکن است بسته به وضعیت سرور، سرعت mirrorها، نسخه فعلی، تعداد سرویس‌ها و وضعیت سیستم‌عامل چند دقیقه تا بیشتر طول بکشد. در زمان آپدیت، لاگ را بررسی کنید و اگر خطا رخ داد، آن را نادیده نگیرید.

برای مشاهده لاگ آپدیت:

tail -f /var/cpanel/updatelogs/latest

بعد از پایان آپدیت، دوباره نسخه را بررسی کنید:

/usr/local/cpanel/cpanel -V

اگر نسخه همچنان پایین‌تر از نسخه پچ‌شده است، احتمالاً tier، تنظیمات update، محدودیت سیستم‌عامل یا خطای update مانع شده است.

مرحله ۳: ری‌استارت سرویس cpsrvd بعد از آپدیت

cPanel در required actions اعلام کرده بعد از تکمیل آپدیت، نسخه build را بررسی کنید و سرویس cpsrvd را hard restart کنید:

/usr/local/cpanel/cpanel -V
/scripts/restartsrv_cpsrvd --hard

cpsrvd سرویس اصلی cPanel برای پاسخ‌دهی به رابط‌های cPanel، WHM و Webmail است. بعد از پچ امنیتی، restart کردن این سرویس کمک می‌کند نسخه جدید و کدهای به‌روزشده به‌درستی در حال اجرا باشند.

بعد از restart، دسترسی به WHM و cPanel را تست کنید:

https://server-hostname:2087
https://server-hostname:2083

اگر نسخه cPanel را pin کرده‌اید چه کار کنید؟

بعضی مدیران برای کنترل تغییرات، cPanel را روی یک نسخه یا tier خاص نگه می‌دارند. این کار در حالت عادی ممکن است برای جلوگیری از تغییرات ناخواسته انجام شود، اما در رخدادهای امنیتی می‌تواند باعث جا ماندن از پچ شود.

cPanel در اطلاعیه خود تأکید کرده اگر آپدیت‌ها را غیرفعال کرده‌اید یا تنظیمات update را روی نسخه خاص pin کرده‌اید، این سرورها ممکن است auto-update نشوند و باید دستی و با اولویت بالا بررسی شوند.

برای تغییر tier، بسته به وضعیت سرور، می‌توانید از WHM یا خط فرمان استفاده کنید. برای سرورهای CentOS 7 یا CloudLinux 7، cPanel دستور زیر را برای set کردن tier به 11.110 ذکر کرده است:

whmapi1 set_tier tier=11.110

بعد از تنظیم tier، دوباره آپدیت را اجرا کنید:

/scripts/upcp --force

نکته مهم برای CentOS 7 و CloudLinux 7

طبق اطلاعیه cPanel، اگر سرور از CentOS 7 یا CloudLinux 7 استفاده می‌کند، باید نسخه روی 11.110 تنظیم شود:

whmapi1 set_tier tier=11.110

سپس:

/scripts/upcp --force
/usr/local/cpanel/cpanel -V
/scripts/restartsrv_cpsrvd --hard

اگر هنوز روی CentOS 7 یا CloudLinux 7 هستید، این رخداد یادآوری مهمی است که سیستم‌عامل‌های قدیمی در رخدادهای امنیتی می‌توانند محدودیت ایجاد کنند. برای سرورهای production، برنامه مهاجرت به سیستم‌عامل پشتیبانی‌شده را جدی بگیرید.

نکته مهم برای CentOS 6 و CloudLinux 6

cPanel برای مشتریانی که هنوز روی CentOS 6 یا CloudLinux 6 و نسخه 110.0.50 هستند، نسخه 110.0.103 را به‌عنوان direct update اعلام کرده است. دستور تنظیم tier طبق اطلاعیه:

whmapi1 set_tier tier=11.110.0.103

سپس باید مراحل required actions اجرا شود:

/scripts/upcp --force
/usr/local/cpanel/cpanel -V
/scripts/restartsrv_cpsrvd --hard

استفاده از CentOS 6 یا CloudLinux 6 برای سرورهای فعال بسیار پرریسک است. حتی اگر برای این رخداد direct update ارائه شده باشد، این وضعیت نباید راهکار بلندمدت تلقی شود. بهتر است مهاجرت به سرور جدید و سیستم‌عامل پشتیبانی‌شده در اولویت قرار بگیرد.

اگر فعلاً نمی‌توانید آپدیت کنید چه کار کنید؟

راهکار اصلی، آپدیت به نسخه پچ‌شده است. اما اگر به هر دلیل فعلاً نمی‌توانید آپدیت انجام دهید، cPanel دو mitigation موقت پیشنهاد کرده است:

  • بستن ترافیک ورودی روی پورت‌های 2083، 2087، 2095 و 2096 در فایروال
  • یا متوقف کردن سرویس‌های cpsrvd و cpdavd

نمونه دستور توقف سرویس‌ها طبق اطلاعیه cPanel:

whmapi1 configureservice service=cpsrvd enabled=0 monitored=0 && whmapi1 configureservice service=cpdavd enabled=0 monitored=0 && /scripts/restartsrv_cpsrvd --stop && /scripts/restartsrv_cpdavd --stop

هشدار: این کار دسترسی کاربران و مدیران به cPanel، WHM، Webmail یا WebDAV را تحت تأثیر قرار می‌دهد. بنابراین باید آگاهانه، موقت و با اطلاع‌رسانی انجام شود. این mitigation جایگزین پچ نیست؛ فقط برای کاهش سطح حمله تا زمان آپدیت است.

پورت‌های حساس cPanel در این رخداد

cPanel در mitigation خود به چند پورت مشخص اشاره کرده است. این پورت‌ها مربوط به رابط‌های مدیریتی یا کاربری cPanel هستند:

پورتسرویس رایجتوضیح
2083cPanel over SSLورود کاربران به cPanel
2087WHM over SSLورود مدیران به WHM
2095Webmail بدون SSL یا redirectدسترسی Webmail
2096Webmail over SSLدسترسی امن Webmail

در حالت عادی هم بهتر است دسترسی به WHM روی پورت 2087 برای همه اینترنت باز نباشد و فقط از IPهای مدیریتی یا VPN قابل دسترسی باشد. برای سرورهای هاستینگ عمومی، cPanel و Webmail ممکن است برای کاربران باز باشند؛ اما WHM باید تا حد امکان محدود شود.

وضعیت Detection Script رسمی cPanel

در نسخه‌های اولیه اطلاعیه، cPanel به detection script اشاره کرده بود؛ اما طبق آخرین تغییر ثبت‌شده در مقاله رسمی، cPanel اعلام کرده detection script فعلی به‌طور موقت حذف شده تا نسخه جدید تأیید شود.

بنابراین اگر در سایت‌ها یا شبکه‌های اجتماعی اسکریپت‌هایی با عنوان «تشخیص CVE-2026-41940» می‌بینید، بدون تأیید رسمی cPanel آن‌ها را روی سرور production اجرا نکنید. اجرای اسکریپت ناشناس با دسترسی root می‌تواند خودش یک ریسک امنیتی جدی باشد.

تا زمانی که cPanel نسخه رسمی و تأییدشده detection script را منتشر نکرده، کارهای مطمئن‌تر این‌ها هستند:

  • آپدیت به نسخه پچ‌شده
  • بررسی نسخه build با دستور رسمی
  • بررسی لاگ‌های ورود و فعالیت‌های مشکوک
  • محدودسازی پورت‌های مدیریتی
  • در صورت مشاهده نشانه compromise، مهاجرت به سرور clean یا reinstall طبق توصیه cPanel

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

cPanel در اطلاعیه رسمی خود اشاره کرده اگر سرور root-compromised تأیید شود، باید اکانت‌های cPanel به یک سرور تمیز منتقل شوند یا سیستم‌عامل مجدداً نصب شود و اکانت‌ها از بکاپ restore شوند.

اگر احتمال compromise دارید، فقط اجرای آپدیت کافی نیست. آپدیت آسیب‌پذیری را می‌بندد، اما اگر مهاجم قبلاً دسترسی گرفته باشد، ممکن است backdoor، کاربر مخفی، فایل مخرب یا تغییرات ماندگار ایجاد کرده باشد.

چک‌لیست واکنش اولیه:

  1. سرور را از نظر دسترسی‌های مشکوک بررسی کنید.
  2. لاگ‌های cPanel، WHM، SSH و سیستم را حفظ کنید.
  3. رمزهای root، کاربران WHM، اکانت‌های cPanel، ایمیل‌ها و دیتابیس‌ها را rotate کنید.
  4. کاربران ناشناس یا سطح دسترسی غیرعادی را بررسی کنید.
  5. فایل‌های جدید و تغییرکرده در مسیرهای حساس را بررسی کنید.
  6. Mail queue، cron jobها و SSH authorized_keys را بررسی کنید.
  7. اگر root compromise محتمل یا تأیید شده است، سرور clean بسازید و اکانت‌ها را امن منتقل کنید.

در compromise سطح root، اعتماد کردن به همان سیستم‌عامل بعد از پاکسازی ساده کافی نیست. بهترین مسیر، مهاجرت به سرور تمیز یا reinstall و restore کنترل‌شده است.

چک‌لیست فوری برای شرکت‌های هاستینگ

اگر شرکت هاستینگ هستید یا چند سرور cPanel مدیریت می‌کنید، با یک سرور کار تمام نمی‌شود. باید inventory کامل داشته باشید و همه سرورها را بررسی کنید.

اقدامدستور یا توضیحاولویت
فهرست همه سرورهاcPanel، DNSOnly، WP Squared، سرورهای تست و قدیمیخیلی بالا
بررسی نسخه/usr/local/cpanel/cpanel -Vخیلی بالا
آپدیت فوری/scripts/upcp --forceخیلی بالا
ری‌استارت cpsrvd/scripts/restartsrv_cpsrvd --hardخیلی بالا
بررسی سرورهای pin شدهupdate tier و disabled updates را بررسی کنیدخیلی بالا
محدودسازی WHMپورت 2087 را فقط برای IP/VPN مدیریتی باز بگذاریدبالا
بررسی لاگ‌هاlogin_log، access_log، secure و لاگ‌های سیستمبالا
اطلاع‌رسانی داخلیبه تیم پشتیبانی و NOC اطلاع دهید چه چیزی بررسی شده استبالا
مستندسازینسخه قبل، نسخه بعد، زمان آپدیت و نتیجه را ثبت کنیدمتوسط

اگر ارائه‌دهنده نمایندگی هاست ایران یا نمایندگی هاست لینوکس هستید، بهتر است مشتریان reseller هم بدانند سرورهای شما پچ شده‌اند، بدون اینکه جزئیات حساس امنیتی یا لاگ‌های داخلی منتشر شود.

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

بعد از آپدیت، کار تمام نیست. باید مطمئن شوید سرویس‌ها سالم هستند و نسخه پچ‌شده واقعاً اجرا شده است.

چک‌لیست بعد از آپدیت:

  • بررسی نسخه با /usr/local/cpanel/cpanel -V
  • بررسی وضعیت سرویس cpsrvd
  • تست ورود به WHM و cPanel
  • تست Webmail، اگر روی سرور فعال است
  • بررسی لاگ‌های update برای خطا
  • بررسی لاگ‌های login برای تلاش‌های مشکوک
  • بررسی cPHulk، CSF/LFD یا فایروال برای بلاک‌های غیرعادی
  • بررسی AutoSSL یا سرویس‌های مهمی که ممکن است تحت تأثیر restart قرار گرفته باشند

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

/usr/local/cpanel/cpanel -V
/scripts/restartsrv_cpsrvd --status
tail -n 100 /var/cpanel/updatelogs/latest
tail -n 100 /usr/local/cpanel/logs/login_log
tail -n 100 /usr/local/cpanel/logs/access_log

اقدامات بلندمدت برای امنیت cPanel

CVE-2026-41940 یک رخداد امنیتی مهم است، اما نباید نگاه ما فقط به همین پچ محدود شود. سرور cPanel باید همیشه با مدل دفاع چندلایه مدیریت شود.

اقدامات پیشنهادی بلندمدت:

  • فعال نگه داشتن آپدیت‌های cPanel و سیستم‌عامل
  • استفاده از 2FA برای WHM و کاربران حساس
  • محدودسازی WHM و SSH به IP یا VPN مدیریتی
  • فعال‌سازی و تنظیم cPHulk
  • تنظیم فایروال CSF/LFD یا فایروال معادل
  • فعال‌سازی ModSecurity و Rule Set معتبر
  • اسکن بدافزار و مانیتورینگ تغییر فایل‌ها
  • بکاپ خارج از سرور و تست restore
  • مهاجرت از سیستم‌عامل‌های قدیمی و EOL
  • تهیه inventory دقیق از همه سرورهای cPanel، DNSOnly و سرویس‌های وابسته

برای مطالعه کامل‌تر، مقاله چک‌لیست امنیت cPanel و WHM را بخوانید. اگر در حال انتخاب سرویس برای سایت‌های وردپرسی یا فروشگاهی هستید، کیفیت زیرساخت در سرویس‌هایی مثل بهترین هاست وردپرس، خرید هاست اشتراکی و خرید هاست ووکامرس اهمیت زیادی دارد.

جمع‌بندی

CVE-2026-41940 یک آسیب‌پذیری authentication bypass در cPanel و WHM است که طبق اطلاعیه رسمی cPanel، نسخه‌های بعد از 11.40 را تحت تأثیر قرار می‌دهد. cPanel برای چندین شاخه نسخه پچ منتشر کرده و مدیران سرور باید فوراً نسخه سرور را بررسی و به نسخه patched به‌روزرسانی کنند.

مهم‌ترین دستورهای عملی برای مدیران سرور این‌ها هستند: اجرای /scripts/upcp --force، بررسی نسخه با /usr/local/cpanel/cpanel -V و restart کردن سرویس cpsrvd با /scripts/restartsrv_cpsrvd --hard. اگر سرور شما روی نسخه pin شده یا سیستم‌عامل قدیمی است، باید طبق راهنمای cPanel tier مناسب را تنظیم و آپدیت را دستی انجام دهید.

اگر امکان آپدیت فوری ندارید، بستن پورت‌های 2083، 2087، 2095 و 2096 یا توقف موقت cpsrvd و cpdavd می‌تواند به‌عنوان mitigation کوتاه‌مدت استفاده شود؛ اما این کار جایگزین پچ نیست. اگر سرور root-compromised تشخیص داده شود، مسیر قابل اعتماد، مهاجرت به سرور clean یا نصب مجدد سیستم‌عامل و restore کنترل‌شده از بکاپ است.

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

CVE-2026-41940 چیست؟

CVE-2026-41940 یک آسیب‌پذیری امنیتی از نوع Authentication Bypass در cPanel است که طبق اعلام رسمی cPanel، نرم‌افزار cPanel شامل DNSOnly را در نسخه‌های بعد از 11.40 تحت تأثیر قرار می‌دهد.

آیا همه سرورهای cPanel باید بررسی شوند؟

بله. هر سروری که cPanel & WHM، DNSOnly یا WP Squared دارد باید از نظر نسخه بررسی شود، مخصوصاً اگر آپدیت‌ها pin یا غیرفعال شده باشند.

چطور نسخه cPanel را بررسی کنم؟

با SSH وارد سرور شوید و دستور /usr/local/cpanel/cpanel -V را اجرا کنید.

دستور آپدیت فوری cPanel چیست؟

دستور پیشنهادی cPanel برای آپدیت فوری این است: /scripts/upcp --force

بعد از آپدیت چه دستوری باید اجرا شود؟

بعد از آپدیت، نسخه را با /usr/local/cpanel/cpanel -V بررسی کنید و سرویس cpsrvd را با /scripts/restartsrv_cpsrvd --hard ری‌استارت کنید.

اگر سرور CentOS 7 یا CloudLinux 7 باشد چه کار کنم؟

طبق اطلاعیه cPanel، برای CentOS 7 یا CloudLinux 7 باید tier روی 11.110 تنظیم شود و سپس آپدیت اجرا شود.

اگر سرور CentOS 6 یا CloudLinux 6 باشد چه کار کنم؟

cPanel برای سرورهای CentOS 6 یا CloudLinux 6 روی 110.0.50 نسخه direct update با tier 11.110.0.103 اعلام کرده است؛ اما این وضعیت نباید راهکار بلندمدت باشد و مهاجرت به سیستم‌عامل جدید توصیه می‌شود.

اگر نتوانم فوراً آپدیت کنم چه mitigation موقتی دارم؟

طبق اطلاعیه cPanel، می‌توانید ترافیک ورودی روی پورت‌های 2083، 2087، 2095 و 2096 را در فایروال ببندید یا سرویس‌های cpsrvd و cpdavd را موقتاً متوقف کنید. این کار جایگزین آپدیت نیست.

آیا detection script رسمی برای این آسیب‌پذیری وجود دارد؟

در آخرین نسخه اطلاعیه رسمی، cPanel اعلام کرده detection script فعلی موقتاً حذف شده تا نسخه جدید تأیید شود. بنابراین فقط از ابزارها و اسکریپت‌های رسمی cPanel استفاده کنید.

اگر سرور root-compromised شده باشد چه کار کنیم؟

طبق توصیه cPanel، اگر root compromise تأیید شود، باید اکانت‌ها به یک سرور clean منتقل شوند یا سیستم‌عامل مجدداً نصب و اکانت‌ها از بکاپ restore شوند.