با دیدن هشدار «دریافت شل بدون رمز عبور از سایت‌های PHP»، اولین سؤال معمولاً این است: آیا باید سایت را خاموش کنیم؟ برای پاسخ، ابتدا باید بدانیم PHP سایت را چه کسی مدیریت می‌کند، درخواست‌های کاربران از چه مسیری به آن می‌رسند و آیا بسته اصلاح‌شده برای همان محیط در دسترس است. تغییر تصادفی تنظیمات یا ارتقای عجولانه نسخه اصلی PHP می‌تواند هم سرویس را مختل کند و هم مشکل امنیتی را باقی بگذارد.
آسیب‌پذیری PHP2Shell نامی است که برای دو شناسه CVE-2026-109618 و CVE-2026-109619 به کار می‌رود. این راهنما به مدیران سایت، فروشگاه اینترنتی و سرور کمک می‌کند وضعیت خود را مشخص کنند و برای محافظت موقت، نصب وصله و بازگشت به سرویس عادی تصمیم بگیرند.
مبنای اطلاعات: بررسی منابع در ۲۱ اکتبر ۲۰۲۶، پیش از زمان اعلام‌شده انتشار وصله. اطلاعیه قابل‌دسترسی PHP هنوز شماره نسخه‌های اصلاح‌شده را درج نکرده بود. زمان اعلام‌شده انتشار، ساعت ۱۴:۰۰ UTC، معادل ۱۷:۳۰ ایران در همین تاریخ است. هنگام اجرای مراحل، وضعیت جدید منابع رسمی را بررسی کنید؛ زمان انتشار کد PHP الزاماً با زمان آماده‌شدن بسته میزبان شما یکسان نیست.
پیش از هر تغییری، این سه سؤال را پاسخ دهید
برای شروع لازم نیست متخصص تحلیل اکسپلویت باشید. مهم‌تر است مشخص شود چه چیزی در اختیار شماست و کدام بخش باید توسط شرکت میزبان یا مدیر زیرساخت اصلاح شود.
- PHP را چه کسی نصب و به‌روزرسانی می‌کند؟ در هاست اشتراکی معمولاً این کار بر عهده میزبان است. در سرور مدیریت‌نشده، مسئولیت عملیاتی به مدیر سرور برمی‌گردد.
- کدام برنامه‌ها از آن استفاده می‌کنند؟ سایت اصلی، فروشگاه، پنل مشتریان، API، وب‌میل، زیردامنه آزمایشی و نسخه قدیمی سایت را بررسی کنید.
- آیا می‌توان دسترسی عمومی را موقتاً محدود کرد؟ پنل داخلی و سامانه عمومی فروش شرایط یکسانی ندارند. اثر محدودیت بر مشتری، سفارش و پرداخت باید از ابتدا معلوم باشد.
خروجی این مرحله یک فهرست ساده است: نام سایت، نسخه PHP، محل نصب یا ارائه‌دهنده بسته، مسئول به‌روزرسانی و وضعیت دسترسی عمومی. این فهرست مانع از آن می‌شود که نسخه سایت اصلی اصلاح شود ولی یک زیردامنه فراموش‌شده همچنان باز بماند.
واقعیت هشدار PHP2Shell چیست و چه چیزهایی هنوز مشخص نیست؟
تیم امنیت PHP در اطلاعیه رسمی انتشار اضطراری وجود دو آسیب‌پذیری بحرانی با امتیاز ۹٫۲ در مدل CVSS v4.0 را تأیید کرده است. در آن اطلاعیه آمده که جزئیات فنی و فهرست نسخه‌های آسیب‌پذیر و اصلاح‌شده همراه انتشار ارائه می‌شوند.
هشدار CERT-EU نیز این دو شناسه را مطرح می‌کند و از احتمال اجرای کد از راه دور بدون احراز هویت می‌گوید. با این حال، عبارت‌هایی مانند «تمام سایت‌ها با یک درخواست شل می‌دهند» از اطلاعات رسمی موجود دقیق‌تر نیستند؛ شرایط بهره‌برداری و مسیر دقیق خطا هنوز در منابع بررسی‌شده عمومی نشده بود.
هاست اختصاصی وردپرس
شروع از ماهانه 80 هزار تومان
«اجرای کد از راه دور» یعنی مهاجم ممکن است از طریق ورودی ارسالی به سرویس، کدی خارج از رفتار عادی برنامه اجرا کند. اگر اجرا در حساب کاربری سایت رخ دهد، دسترسی اولیه معمولاً تابع مجوزهای همان حساب است. این اتفاق خودبه‌خود معادل دسترسی root نیست، اما خواندن تنظیمات اتصال دیتابیس یا تغییر فایل‌های قابل‌نوشتن سایت نیز می‌تواند خسارت بزرگی ایجاد کند.
وجود آسیب‌پذیری، در معرض اینترنت بودن و آلوده‌شدن سه موضوع متفاوت‌اند. یک اعلامیه عمومی ثابت نمی‌کند سایت شما هک شده است؛ نبود خطا یا افت سرعت نیز سالم‌بودن آن را ثابت نمی‌کند.
اگر هاست اشتراکی دارید، از شرکت میزبان چه بخواهید؟
در هاست اشتراکی، تغییر نسخه از منوی انتخاب PHP لزوماً نصب وصله نیست. ممکن است فقط بین چند نسخه نصب‌شده جابه‌جا شوید و هیچ‌کدام هنوز اصلاحیه موردنظر را دریافت نکرده باشند. اگر با محیط کنترل پنل آشنا نیستید، راهنمای کار با cPanel برای شناخت بخش‌های مدیریت هاست مفید است؛ تأیید اصلاح این آسیب‌پذیری همچنان باید از مسئول بسته‌های سرور گرفته شود.
در درخواست پشتیبانی، به‌جای پرسش کلی «سرور امن است؟»، این اطلاعات را بخواهید:
- نسخه و شماره ساخت بسته PHP که درخواست‌های دامنه شما را اجرا می‌کند.
- تأیید اینکه بسته نصب‌شده هر دو شناسه CVE را پوشش می‌دهد.
- مرجع اطلاعیه سازنده یا ارائه‌دهنده بسته که این موضوع را تأیید می‌کند.
- وضعیت جایگزینی پردازش‌های قدیمی پس از نصب به‌روزرسانی.
- راهکار موقت پیشنهادی و اثر آن بر ورود کاربران، پرداخت و آپلود فایل.
پاسخ «کنترل پنل به‌روز است» یا «فایروال فعال است» به‌تنهایی پاسخ این پرسش‌ها نیست. نام دقیق بسته و مرجع اصلاحیه کمک می‌کند بین آماده‌سازی، نصب واقعی و تأیید نتیجه تفاوت بگذارید.
اگر سرور را خودتان مدیریت می‌کنید، نسخه واقعی PHP را پیدا کنید
روی یک سرور ممکن است چند PHP کنار هم نصب شده باشد: نسخه سیستم‌عامل، نسخه‌های کنترل پنل، اجرای مستقل یک برنامه و نسخه داخل کانتینر. دستور زیر فقط اطلاعات PHP پیش‌فرض خط فرمان را نشان می‌دهد:
php -v
php --iniاین خروجی برای شروع مفید است، اما به‌تنهایی مشخص نمی‌کند فروشگاه یا پنل مشتریان با کدام PHP اجرا می‌شود. مسیر اجرای وب‌سرور، تنظیمات PHP-FPM یا تنظیمات دامنه در کنترل پنل را با آن تطبیق دهید. کرون‌ها و پردازش‌های طولانی‌مدت را هم جداگانه بررسی کنید.
سرور مجازی ارزان
شروع از ماهانه 100 هزارتومان
برای هر برنامه، این اطلاعات را ثبت کنید:
| اطلاعات موردنیاز | دلیل بررسی |
|---|---|
| نسخه و مسیر PHP فعال | جلوگیری از به‌روزرسانی یک نصب نامرتبط |
| ارائه‌دهنده و شماره ساخت بسته | تطبیق با اطلاعیه امنیتی و اصلاحیه احتمالی Backport |
| دامنه‌ها و سرویس‌های وابسته | مشخص‌شدن دامنه اثر به‌روزرسانی یا محدودیت |
| نوع اجرا، مانند FPM یا ماژول وب‌سرور | شناسایی پردازش‌هایی که پس از نصب باید جایگزین شوند |
| آزمون‌های ضروری برنامه | بررسی ورود، سفارش و سایر عملیات بعد از تغییر |
شماره نسخه ظاهری همیشه تمام اطلاعات را نشان نمی‌دهد. برخی ارائه‌دهندگان اصلاح امنیتی را به نسخه موجود برمی‌گردانند که به آن Backport می‌گویند. در این حالت باید شماره ساخت بسته و اطلاعیه همان ارائه‌دهنده بررسی شود؛ صرفاً دیدن یک شماره قدیمی یا جدید برای نتیجه‌گیری کافی نیست.
تا قبل از نصب وصله، سایت باز بماند یا محدود شود؟
این تصمیم به حساسیت داده‌ها، امکان اصلاح سریع و هزینه اختلال بستگی دارد. CERT-EU توصیه کرده در صورت نبود امکان وصله فوری، جداسازی برنامه‌های PHP در معرض اینترنت بررسی شود. اجرای این توصیه الزاماً به معنی خاموش‌کردن کل ماشین یا قطع ایمیل نیست؛ در بسیاری از محیط‌ها می‌توان دسترسی به برنامه وب را جداگانه کنترل کرد.
| شرایط سرویس | اقدام موقت قابل‌بررسی | اثری که باید پذیرفت |
|---|---|---|
| پنل داخلی یا محیط آزمایشی | دسترسی فقط از VPN یا IPهای مورداعتماد | کاربران خارج از مسیر مجاز نمی‌توانند متصل شوند |
| سایت اطلاع‌رسانی با امکان توقف کوتاه | نمایش HTML استاتیک و جلوگیری از رسیدن درخواست عمومی به PHP | بخش‌های پویا، فرم‌ها و ورود موقتاً از دسترس خارج می‌شوند |
| فروشگاه یا سامانه پرداخت | تصمیم هماهنگ برای محدودیت موقت با توجه به سفارش‌ها و callbackها | باید پرداخت‌های در جریان و بازگشت اطلاع‌رسانی درگاه پیگیری شوند |
| سرویسی که فعلاً عمومی باقی می‌ماند | حفظ کنترل‌های موجود، پایش و آماده‌سازی نصب سریع وصله | خطر باقی‌مانده پذیرفته می‌شود؛ رفع آسیب‌پذیری تأیید نشده است |
محدودیت باید پیش از اجرای PHP اعمال شود. افزونه «حالت تعمیرات» وردپرس معمولاً خود به اجرای PHP وابسته است. همچنین بستن صفحه مدیریت، مسیرهای عمومی برنامه را حذف نمی‌کند. در راهکار استاتیک، آدرس مستقیم فایل‌های PHP، مسیرهای بازنویسی‌شده و میزبان‌های مجازی جایگزین باید بررسی شوند.
اگر از CDN استفاده می‌کنید، فقط نام دامنه اصلی را نبینید. دسترسی مستقیم به سرور مبدأ، IPv6، پورت‌های دیگر و زیردامنه‌هایی که از CDN عبور نمی‌کنند نیز باید با سیاست انتخابی سازگار باشند. محدودیتی که فقط از اتصال مدیر سایت آزمایش شده، ممکن است از اینترنت عمومی رفتار دیگری داشته باشد.
چه اقدام‌هایی احساس امنیت می‌دهند ولی اثبات رفع مشکل نیستند؟
تغییر یک خط در php.ini
تنظیم session.upload_progress.enabled = Off در پیام‌های اولیه زیاد دیده می‌شود. طبق مستندات تنظیمات Session در PHP، این گزینه به ثبت پیشرفت آپلود در Session مربوط است. وجود چنین تنظیمی در مستندات به معنی تأیید آن به‌عنوان وصله این دو CVE نیست. خاموش‌کردن آن را معیار امن‌شدن سرور قرار ندهید.
همچنین مقدار memory_limit = -1 محدودیت حافظه را برمی‌دارد و نباید به‌عنوان دستور عمومی مقابله با این هشدار اجرا شود. هر راهکار موقت باید توضیح روشن سازنده درباره شرایط کاربرد و محدودیت‌هایش داشته باشد.
سرور مجازی ویندوز
Remote Access & Full Admin
اتکا به SSL یا افزونه امنیت وردپرس
SSL ارتباط را رمزگذاری می‌کند، اما مسئول اصلاح خطای داخل مفسر PHP نیست. در توضیح تفاوت HTTP و HTTPS نیز موضوع اصلی، امنیت مسیر انتقال است. پس قفل مرورگر یا نصب گواهی معتبر، شاهد رفع نقص پردازش درخواست در سرور نیست.
افزونه امنیتی می‌تواند بخشی از دفاع برنامه باشد، ولی جایگزین به‌روزرسانی PHP نمی‌شود. به‌روزرسانی وردپرس و افزونه‌ها را با به‌روزرسانی محیط اجرای آن اشتباه نگیرید.
فرض محافظت کامل با فعال‌بودن WAF
برای اتکا به یک قانون WAF باید معلوم باشد کدام CVE و چه الگوی درخواست را پوشش می‌دهد. فعال‌بودن کلی فایروال، مسدودکردن چند کشور یا محدودکردن تعداد درخواست‌ها اثبات نمی‌کند مسیر بهره‌برداری بسته شده است. حتی قانون معتبر نیز باید در تمام مسیرهای ورودی اعمال شود.
سایت‌های وابسته به PHP 7.4 چه راهی دارند؟
بر اساس جدول پشتیبانی رسمی PHP در زمان این بررسی، شاخه‌های 8.2 تا 8.5 پشتیبانی می‌شوند و PHP 7.4 خارج از پشتیبانی بالادستی است. اگر یک نرم‌افزار قدیمی تنها با این نسخه کار می‌کند، تصمیم شما دو بخش دارد: کنترل مواجهه فعلی و برنامه مهاجرت سازگار.
در کوتاه‌مدت، بررسی کنید ارائه‌دهنده بسته قدیمی واقعاً اصلاحیه‌ای برای هر دو شناسه عرضه کرده است یا نه. عنوان «پشتیبانی طولانی‌مدت» بدون اشاره به بسته و پوشش آسیب‌پذیری موردنظر کافی نیست. اگر اصلاحیه قابل‌تأیید ندارید، خطر اجرای عمومی برنامه باقی می‌ماند و باید درباره محدودیت دسترسی تصمیم بگیرید.
برای مهاجرت، ابتدا سازگاری هسته برنامه، افزونه‌ها، ماژول‌های تجاری، ionCube و کدهای اختصاصی را در محیط آزمایش بررسی کنید. تغییر ناگهانی PHP یک سامانه مالی قدیمی ممکن است ثبت سفارش یا کرون آن را متوقف کند. هدف، رسیدن به نسخه پشتیبانی‌شده و وصله‌شده همراه با عملکرد صحیح برنامه است.
نصب وصله را به یک کار قابل‌تأیید تبدیل کنید
به‌جای یک دستور عمومی که برای همه سرورها پیشنهاد شود، مسیر اصلاح را مطابق روش نصب موجود انتخاب کنید. بسته سیستم‌عامل، بسته کنترل پنل و تصویر Docker چرخه انتشار جداگانه دارند.
- مرجع اصلاحیه را مشخص کنید: مطمئن شوید سازنده بسته، رفع هر دو CVE را برای شماره ساخت موردنظر اعلام کرده است.
- امکان بازگشت عملیاتی داشته باشید: نسخه پشتیبان قابل‌بازیابی و وضعیت تنظیمات را بررسی کنید. برگشت به بسته آسیب‌پذیر نباید بدون کنترل مواجهه به راه‌حل دائمی تبدیل شود.
- همان محیط اجرای برنامه را اصلاح کنید: نصب PHP جدید در مسیر دیگر، نسخه فعال وب‌سایت را خودکار جایگزین نمی‌کند.
- پردازش‌های قدیمی را جایگزین کنید: طبق دستور سازنده، سرویس‌های مربوط را راه‌اندازی مجدد کنید یا کانتینرها را با تصویر اصلاح‌شده دوباره مستقر کنید.
- نتیجه را ثبت کنید: نام بسته، زمان نصب، نسخه فعال و آزمون‌های انجام‌شده باید قابل مراجعه باشند.
اگر کنترل پنل دارید، وضعیت بسته PHP آن را مستقل از شماره نسخه خود پنل بررسی کنید. برای نمونه، اطلاعیه Plesk نسخه‌های PHP عرضه‌شده با این محصول را تحت‌تأثیر اعلام کرده بود. این یک نمونه از لزوم پیگیری بسته ارائه‌دهنده است؛ موضوع PHP2Shell به یک کنترل پنل محدود نیست.
از کجا بفهمیم کار تمام شده است؟
پیام «Update successful» تنها نشان می‌دهد فرایند به‌روزرسانی به پایان رسیده است. برای بستن کار امنیتی، این سه نتیجه را جداگانه تأیید کنید:
- اصلاح نصب شده: شماره ساخت بسته با نسخه اعلام‌شده در اطلاعیه امنیتی تطابق دارد.
- اصلاح در حال استفاده است: وب‌سایت و پردازش‌های وابسته واقعاً از همان محیط اجرای اصلاح‌شده استفاده می‌کنند.
- سرویس درست کار می‌کند: ورود، فرم‌ها، آپلود، پرداخت، API و کارهای زمان‌بندی‌شده موردنیاز آزموده شده‌اند.
برای دیدن نسخه اجرای وب، از ابزار تشخیصی محدود به مدیر یا روش محلی استفاده کنید. صفحه عمومی phpinfo() را در دسترس اینترنت رها نکنید. پس از برداشتن محدودیت نیز سفارش‌های نیمه‌تمام، callbackهای ناموفق و صف کارها را بازبینی کنید.
اگر نشانه‌ای از نفوذ دیدیم، آیا به‌روزرسانی کافی است؟
خیر. نصب وصله مسیر آسیب‌پذیری را اصلاح می‌کند، اما فایل مخرب قبلی یا اطلاعات سرقت‌شده را برنمی‌گرداند. ایجاد فایل PHP ناشناس، تغییر غیرمنتظره تنظیمات، پردازش مشکوک زیر حساب وب‌سرور یا اتصال خروجی غیرعادی می‌تواند دلیل بررسی بیشتر باشد. این موارد نشانه‌های عمومی‌اند و به‌تنهایی ثابت نمی‌کنند همین دو CVE استفاده شده‌اند.
در صورت ظن جدی، دسترسی سرویس را محدود و لاگ‌ها و شواهد را حفظ کنید. سپس دامنه حادثه، حساب‌های درگیر و رازهای قابل‌دسترسی را مشخص کنید. پاک‌سازی یا بازسازی از مبنای مورداعتماد و تعویض رمزها و کلیدهای افشاشده ممکن است لازم باشد. حذف عجولانه فایل‌ها پیش از ثبت شواهد، تحلیل اتفاق را دشوار می‌کند.
پرسش‌های رایج مدیران سایت
اگر سایت فرم آپلود نداشته باشد، از خطر خارج است؟
نبود فرم آپلود در ظاهر سایت، به‌تنهایی دلیل مصونیت نیست. تا زمانی که پیش‌شرط‌های دقیق توسط سازنده مشخص نشده، از ظاهر صفحات برای تعیین آسیب‌پذیری PHP استفاده نکنید.
اگر رمز مدیریت را عوض کنیم مشکل برطرف می‌شود؟
تغییر رمز، خطای محیط اجرای PHP را اصلاح نمی‌کند. در حمله بدون احراز هویت، مهاجم الزاماً به رمز حساب مدیریت نیاز ندارد. تغییر اطلاعات دسترسی زمانی اهمیت جداگانه دارد که احتمال افشای آن‌ها مطرح باشد.
می‌توان با انتقال سایت به سرور دیگری مشکل را حل کرد؟
فقط جابه‌جایی کافی نیست. باید محیط مقصد دارای بسته اصلاح‌شده و تنظیمات مناسب باشد. انتقال همان برنامه به همان PHP آسیب‌پذیر، علت اصلی خطر را حذف نمی‌کند.
آیا نسخه جدیدتر همیشه انتخاب بهتری است؟
برای این اقدام، نسخه‌ای لازم است که رفع آسیب‌پذیری در آن تأیید شده و با برنامه سازگار باشد. بزرگ‌تر بودن شماره نسخه بدون بررسی اطلاعیه و سازگاری، معیار کافی نیست.
از کجا وضعیت جدید را پیگیری کنیم؟
اطلاعیه PHP را برای جزئیات بالادستی، و اطلاعیه شرکت میزبان یا سازنده بسته را برای نسخه قابل‌نصب خود بررسی کنید. شماره ساخت نصب‌شده را با همان مرجع تطبیق دهید؛ به زمان‌بندی پیام‌های بازنشرشده اکتفا نکنید.
برای مدیریت این هشدار، یک مسئول مشخص و یک فهرست وضعیت برای تمام سایت‌ها داشته باشید. هر سرویس باید در نهایت به یکی از دو وضعیت روشن برسد: «اصلاحیه نصب و تأیید شده» یا «دسترسی موقتاً کنترل شده و اصلاح هنوز در انتظار است». این روش از فراموش‌شدن بخش‌هایی مثل سایت آزمایشی، نسخه قدیمی PHP یا کرون سامانه مالی جلوگیری می‌کند.
