Milad Mobaseri
تصویر مفهومی از وصله‌ی امنیتی که درِ باز سرور PHP را می‌بندد
امنیت

آسیب‌پذیری PHP2Shell: سایت PHP دارم، چه کار کنم؟

PHP2Shell دو آسیب‌پذیری بحرانی در خود PHP است که وردپرس، لاراول و هر سایت PHP را تهدید می‌کند. چطور نسخه را چک کنیم، روی سرور و هاست اشتراکی آپدیت کنیم و اگر نمی‌شود چه راه موقتی هست.

جواب کوتاه: PHP2Shell دو آسیب‌پذیری بحرانی در خود موتور PHP است (CVE-2026-109618 و CVE-2026-109619) که تقریباً همه‌ی نسخه‌ها از ۵.۴ تا ۸.۵ را شامل می‌شود. کد سایت شما هر چقدر هم تمیز باشد فرقی نمی‌کند؛ راه‌حل فقط به‌روزرسانی خود PHP است: نسخه‌ی ۸.۲.۳۵، ۸.۳.۳۶، ۸.۴.۲۷ یا ۸.۵.۱۲، و بعد ری‌استارت سرویس PHP. اگر روی هاست اشتراکی هستید، باید از شرکت هاستینگ بخواهید این کار را انجام دهد.

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

سروری قدیمی با درزی نورانی که با یک کلید کوچک باز شده و به‌روزرسانی که آن را می‌بندد

PHP2Shell چیست و چه اتفاقی افتاد؟

  • ۲۱ اکتبر ۲۰۲۶ (۲۹ مهر ۱۴۰۵): تیم PHP نسخه‌های اصلاح‌شده را منتشر کرد. قرار بود اعلام عمومی یک روز بعد باشد، اما جزئیات زودتر لو رفت و انتشار جلو افتاد.
  • چطور پیدا شد: پژوهشگرها با کمک مدل‌های هوش مصنوعی این باگ‌ها را به یک حمله‌ی کامل تبدیل کردند. یکی از این باگ‌ها از سال ۲۰۲۴ شناخته‌شده بود، اما چون ساختن حمله برایش «غیرممکن» به نظر می‌رسید، رفعش عقب افتاده بود.
  • نتیجه: مهاجم بدون نیاز به ورود و رمز می‌تواند روی سرور کد اجرا کند. گزارش‌های تلاش برای حمله از همان روز انتشار وصله شروع شد و چند سایت دولتی در اروپا و کانادا موقتاً از دسترس خارج شدند.

یک نکته‌ی منصفانه هم هست: شرکت امنیتی Sansec گزارش داده که اکسپلویت‌های عمومی فعلی روی نصب پیش‌فرض PHP کار نمی‌کنند و بیشترشان به یک باگ دیگر در خود برنامه نیاز دارند. یعنی وضعیت «همه هک می‌شوند» نیست؛ ولی با توجه به سرعت ساخت اکسپلویت‌های جدید، صبر کردن هم منطقی نیست.

آیا سایت من آسیب‌پذیر است؟

اگر سایتتان با PHP کار می‌کند، تقریباً قطعاً بله، مگر اینکه نسخه‌ی اصلاح‌شده را داشته باشید. این شامل وردپرس، ووکامرس، لاراول، جوملا، مجنتو و هر سایت PHP دیگری است، چون مشکل در خود موتور PHP است، نه در افزونه‌ها یا کد سایت.

نسخه‌ی PHP شما وضعیت کار لازم
8.2، 8.3، 8.4، 8.5 وصله‌ی رسمی دارد آپدیت به 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12
7.4، 8.0، 8.1 نسخه‌ی رسمی ندارد بسته‌ی وصله‌شده‌ی توزیع لینوکس یا ارتقا به 8.2+
7.3 و قدیمی‌تر (حتی 5.x) هیچ وصله‌ای ندارد ارتقا به نسخه‌ی پشتیبانی‌شده

فرقی نمی‌کند PHP با PHP-FPM، ماژول Apache (mod_php)، LiteSpeed یا FrankenPHP اجرا شود؛ همه آسیب‌پذیرند. طبق اعلام خود PHP، بیشترین خطر برای Apache mod_php است.

نسخه‌ی PHP سایتم را چطور بفهمم؟

روی هاست با کنترل‌پنل (cPanel، DirectAdmin، Plesk): در پنل، بخشی با نام‌هایی مثل «Select PHP Version» یا «MultiPHP Manager» نسخه را نشان می‌دهد.

روی سرور خودتان: دقت کنید که php -v در ترمینال نسخه‌ی خط فرمان را نشان می‌دهد و ممکن است با نسخه‌ای که سایت را اجرا می‌کند فرق داشته باشد. مطمئن‌ترین راه این است که یک فایل موقت بسازید:

<?php echo PHP_VERSION;

آن را از مرورگر باز کنید، نسخه را ببینید و فوراً پاکش کنید.

اگر PHP را از مخزن توزیع لینوکس نصب کرده‌اید، شماره‌ی نسخه ممکن است عوض نشود ولی وصله اعمال شده باشد. برای اطمینان، تغییرات بسته را بگردید:

# Debian / Ubuntu
zgrep CVE-2026-109618 /usr/share/doc/php*/changelog.Debian.gz

# AlmaLinux / Rocky / RHEL
rpm -q --changelog php-common | grep CVE-2026-109618

اگر چیزی پیدا شد، وصله نصب است.

راه‌حل روی سرور اختصاصی یا VPS

  1. بسته‌های PHP را آپدیت کنید:
# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade 'php*'

# AlmaLinux / Rocky
sudo dnf upgrade 'php*'
  1. حتماً سرویس PHP را ری‌استارت کنید. پروسه‌هایی که از قبل در حال اجرا هستند هنوز کد قدیمی را دارند:
sudo systemctl restart php8.3-fpm   # نسخه‌ی خودتان را بگذارید
sudo systemctl restart apache2      # اگر mod_php دارید
  1. اگر روی PHP 8.1 یا قدیمی‌تر هستید، نسخه‌ی رسمی جدیدی منتشر نمی‌شود. یا از بسته‌های وصله‌شده‌ی توزیع (مثلاً Ubuntu 22.04 برای PHP 8.1، مخزن Remi یا CloudLinux) استفاده کنید، یا بهترین کار: همین حالا به PHP 8.2 یا بالاتر ارتقا دهید.

اگر سرور در ایران است: اگر apt یا dnf به مخزن‌های خارجی وصل نمی‌شود، از میرورهای داخلی استفاده کنید. روش تنظیمش را در راهنمای کار در نت ملی نوشته‌ام.

راه‌حل روی هاست اشتراکی

روی هاست اشتراکی دسترسی به خود PHP ندارید، پس کار اصلی با شرکت هاستینگ است. این پیام را برای پشتیبانی بفرستید:

سلام. با توجه به آسیب‌پذیری‌های بحرانی PHP2Shell (CVE-2026-109618 و CVE-2026-109619)، لطفاً تأیید کنید که نسخه‌ی PHP سرور هاست من به نسخه‌ی وصله‌شده (8.2.35، 8.3.36، 8.4.27 یا 8.5.12، یا بسته‌ی backport معادل) به‌روز شده و سرویس PHP ری‌استارت شده است.

هم‌زمان، اگر در پنل گزینه‌ی انتخاب نسخه‌ی PHP دارید، سایت را روی بالاترین نسخه‌ای بگذارید که سایتتان با آن درست کار می‌کند (قبلش بکاپ بگیرید). اگر هاست شما هنوز فقط PHP 7.x قدیمی ارائه می‌دهد، وقت عوض کردن هاست است.

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

تیم PHP صریحاً گفته هیچ تنظیمی این مشکل را کامل رفع نمی‌کند و تنها راه، آپدیت است. راه‌های زیر فقط خطر را کم می‌کنند و باید موقت باشند:

  • مسدود کردن درخواست‌های multipart/form-data: این حمله از مسیر درخواست‌های آپلود فایل وارد می‌شود. در nginx:

nginx if ($http_content_type ~* "multipart/form-data") { return 403; }

این کار آپلود فایل و بعضی فرم‌ها (مثلاً آپلود تصویر محصول یا بعضی فرم‌های خرید) را از کار می‌اندازد؛ بعد از اعمال، فرم‌های مهم سایت را تست کنید.
- غیرفعال کردن session.upload_progress.enabled در تنظیمات PHP. این به‌تنهایی کافی نیست، فقط همراه با مورد قبل.
- فایروال وب (WAF): بعضی سرویس‌های CDN و WAF قانون مخصوص این حمله اضافه کرده‌اند. اگر از چنین سرویسی استفاده می‌کنید، از پشتیبانی‌اش بپرسید؛ ولی این هم جایگزین آپدیت نیست.

از کجا بفهمم قبلاً نفوذ شده؟

تا این لحظه نشانه‌ی رسمی و مشخصی (IoC) برای این حمله منتشر نشده. ولی چند بررسی کلی که بعد از هر آسیب‌پذیری اجرای کد ارزش دارد:

  • فایل‌های PHP جدید در پوشه‌هایی که نباید PHP داشته باشند، مثل پوشه‌ی آپلودها:

bash find /var/www -name "*.php" -newermt "2026-10-15" -path "*upload*"

  • کاربر مدیر جدید و ناشناس در پنل سایت (مثلاً در وردپرس).
  • کارهای زمان‌بندی‌شده‌ی (cron) ناشناس روی سرور.
  • جهش ناگهانی مصرف حافظه‌ی PHP در لاگ‌ها؛ این حمله با پر کردن حافظه کار می‌کند.

اگر چیز مشکوکی دیدید، فقط آپدیت کافی نیست: رمزها و کلیدها (دیتابیس، API، پنل) را عوض کنید و در صورت امکان از بکاپ تمیزِ قبل از نفوذ بازگردانی کنید.

درس بزرگ‌تر: «اکسپلویت‌پذیر نیست» دیگر به معنی امن نیست

یکی از این دو باگ دو سال پیش پیدا شده بود و کنار گذاشته شد، چون کسی فکر نمی‌کرد بشود از آن حمله ساخت. این بار هوش مصنوعی همان «سخت» را ارزان کرد. برای ما که سایت و سرور نگه می‌داریم، دو نتیجه دارد:

  1. فاصله‌ی بین انتشار وصله و شروع حمله دیگر روزها نیست، ساعت‌هاست. آپدیت امنیتی را نمی‌شود برای «آخر هفته» گذاشت.
  2. نسخه‌های قدیمی بدهی واقعی‌اند. سایتی که هنوز روی PHP 7 مانده، اولین جایی است که وصله‌ای برایش نمی‌آید.

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

آپدیت وردپرس یا افزونه‌ها مشکل را حل می‌کند؟
نه. مشکل در خود PHP است و فقط آپدیت PHP آن را رفع می‌کند.

سایتم لاراول است، باز هم آسیب‌پذیرم؟
بله. هر برنامه‌ای که با PHP اجرا می‌شود، صرف‌نظر از فریم‌ورک، آسیب‌پذیر است.

سایتم پشت CDN است؛ امنم؟
خطر کمتر می‌شود اگر CDN قانون مخصوص این حمله را فعال کرده باشد، ولی جایگزین آپدیت نیست.

بعد از آپدیت باید کار دیگری بکنم؟
سرویس PHP را ری‌استارت کنید و با فایل موقت PHP_VERSION مطمئن شوید که سایت واقعاً روی نسخه‌ی جدید اجرا می‌شود.

سایت‌های پایتون، جنگو یا Node.js چطور؟
این آسیب‌پذیری فقط مربوط به PHP است. البته Node.js هم در همان روز وصله‌های امنیتی مهمی منتشر کرد، پس آن را هم آپدیت کنید.

منابع

#PHP#آسیب‌پذیری#امنیت وب#وردپرس

نوشته‌های مرتبط

امنیت

پیامک ابلاغیه و سهام عدالت: چطور لینک کلاهبرداری را بشناسیم؟

پیامک ابلاغیه، سهام عدالت، جریمه یا بسته‌ی پستی با لینک؟ ۵ نشانه‌ی پیامک جعلی، کاری که قبل از زدن روی لینک باید بکنید و اگر برنامه نصب کردید، قدم‌به‌قدم چه کنید.

۳ دقیقه مطالعه۸ بازدید
ادامه مطلب →