مقاله امنیت

به‌روزرسانی امنیتی بحرانی PHP در مهر ۱۴۰۵؛ سرور وردپرسی را چطور آماده کنیم

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

حمید اعراب توسعه‌دهنده ارشد بک‌اند وردپرس و ووکامرس
انتشار
زمان مطالعه
۵ دقیقه مطالعه

حمید اعراب ۲۹ مهر ۱۴۰۵ ۵ دقیقه مطالعه

جلد پیکسلی: علامت هشدار قرمز و خلاصهٔ به‌روزرسانی امنیتی PHP
فهرست مطالب (7)

روز ۲۰ اکتبر ۲۰۲۶ (۲۸ مهر ۱۴۰۵)، تیم امنیت PHP یک اطلاعیهٔ کوتاه ولی کم‌سابقه منتشر کرد: یک به‌روزرسانی امنیتی در راه است که دو آسیب‌پذیری بحرانی را برطرف می‌کند. امتیاز هر دو در استاندارد CVSS v4.0 برابر ۹.۲ است. انتشار برای چهارشنبه ۲۱ اکتبر، ساعت ۱۴:۰۰ به وقت UTC، یعنی ۱۷:۳۰ به وقت تهران، برنامه‌ریزی شده بود.

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

تا الان چه می‌دانیم

  • دو آسیب‌پذیری بحرانی، هر دو با امتیاز CVSS v4.0 برابر ۹.۲.
  • زمان انتشار: ۲۱ اکتبر ۲۰۲۶، ساعت ۱۴:۰۰ UTC.
  • تیم PHP گفته اگر جزئیات آسیب‌پذیری‌ها زودتر فاش شود یا نشانه‌ای از سوءاستفادهٔ فعال دیده شود، ممکن است زودتر منتشر کند.
  • جزئیات فنی، نسخه‌های آسیب‌پذیر و نسخه‌های اصلاح‌شده همراه خود انتشار اعلام می‌شوند.

این یادداشت پیش از انتشار جزئیات نوشته شده است. وقتی نسخه‌های جدید منتشر شوند، فهرست دقیق نسخه‌های اصلاح‌شده و شمارهٔ CVEها در اخبار php.net و صفحهٔ ChangeLog می‌آید. همان‌جا ببینید نسخهٔ شاخهٔ شما به چه عددی رسیده است.

نسخه‌هایی که الان پشتیبانی امنیتی دارند

طبق جدول رسمی php.net، در این تاریخ این شاخه‌ها وصلهٔ امنیتی می‌گیرند:

  • PHP 8.5: پشتیبانی فعال تا پایان ۲۰۲۷
  • PHP 8.4: پشتیبانی فعال تا پایان ۲۰۲۶
  • PHP 8.3: فقط وصلهٔ امنیتی، تا پایان ۲۰۲۷
  • PHP 8.2: فقط وصلهٔ امنیتی، تا ۳۱ دسامبر ۲۰۲۶؛ یعنی کمتر از ده هفتهٔ دیگر

اگر سرور شما هنوز روی PHP 8.1 یا قدیمی‌تر است، این به‌روزرسانی رسمی برای شما منتشر نمی‌شود. این بهترین بهانه است که ارتقا را همین هفته در برنامه بگذارید.

قبل از انتشار: آمادگی

  1. نسخهٔ دقیق PHP را پیدا کنید. در وردپرس از «ابزارها › سلامت سایت › اطلاعات › سرور»، یا در ترمینال با php -v. حواستان باشد نسخهٔ PHP خط فرمان و نسخه‌ای که وب‌سرور با آن اجرا می‌شود (PHP-FPM) گاهی فرق دارند.
  2. بدانید چه کسی PHP را به‌روز می‌کند. روی هاست اشتراکی، این کار با شرکت میزبانی است. همین امروز تیکت بزنید و بپرسید کِی وصله را نصب می‌کنند. روی سرور اختصاصی یا VPS، این مسئولیت با خودتان است.
  3. منبع بسته‌ها را بشناسید. اگر PHP را از مخزن رسمی توزیع نصب کرده‌اید، وصله ممکن است با کمی تأخیر برسد. اگر از مخزن‌هایی مثل ondrej/php در اوبونتو یا Remi در RHEL استفاده می‌کنید، معمولاً زودتر می‌رسد. Docker هم image تازهٔ php می‌گیرد، ولی فقط وقتی دوباره build کنید.
  4. بک‌آپ بگیرید. هم از فایل‌ها، هم از دیتابیس. به‌روزرسانی patch معمولاً چیزی را خراب نمی‌کند، ولی «معمولاً» برای فروشگاهی که سفارش ثبت می‌کند کافی نیست.
  5. زمان کم‌ترافیک را مشخص کنید. انتشار ساعت ۱۷:۳۰ به وقت تهران است. برای فروشگاه ایرانی، اواخر شب یا صبح زود روز بعد پنجرهٔ مناسبی برای ری‌استارت PHP-FPM است.

بعد از انتشار: به‌روزرسانی

روی اوبونتو یا دبیان با مخزن ondrej، مسیر معمول این است (نسخه را با نسخهٔ خودتان عوض کنید):

sudo apt update
apt list --upgradable 2>/dev/null | grep php
sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm
php -v

روی RHEL یا Alma با مخزن Remi:

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm
php -v

در Docker، image را دوباره بکشید و سرویس را از نو بسازید؛ فقط ری‌استارت کانتینر کافی نیست:

docker compose pull && docker compose up -d --build

بعد از به‌روزرسانی: چک کنید که واقعاً به‌روز شده

  • نسخه را از خود وب‌سرور بخوانید، نه فقط از خط فرمان. «سلامت سایت» در وردپرس همین را نشان می‌دهد.
  • OPcache را فراموش نکنید. اگر PHP-FPM ری‌استارت نشود، پروسه‌های قدیمی همچنان کد قبلی را اجرا می‌کنند.
  • مسیرهای حساس را یک بار دستی تست کنید: ورود، پرداخت آزمایشی، فرم تماس و هر cron یا webhookی که به درگاه یا انبار وصل است.
  • لاگ خطای PHP را تا ۲۴ ساعت بعد نگاه کنید. باگ‌های امنیتی گاهی با تغییر رفتار در موارد مرزی بسته می‌شوند. افزونه‌ای که به همان رفتار تکیه کرده بود، ممکن است حالا هشدار بدهد.

چرا این بار جدی‌تر است

در گزارش Patchstack از وضعیت امنیت وردپرس در ۲۰۲۶ آمده که حدود نیمی از آسیب‌پذیری‌های پرخطر در ۲۴ ساعت اول مورد سوءاستفاده قرار می‌گیرند. آن آمار دربارهٔ افزونه‌هاست، نه خود PHP؛ ولی منطقش همین‌جا هم صدق می‌کند. وقتی وصله منتشر شود، تغییرات کد هم عمومی می‌شود و مهاجم‌ها از روی همان تغییرات می‌فهمند باگ کجا بوده. فاصلهٔ «وصله منتشر شد» تا «اکسپلویت در دسترس است» هر سال کوتاه‌تر می‌شود.

پس اگر فقط یک کار از این یادداشت انجام می‌دهید: همین امروز معلوم کنید PHP سرورتان را چه کسی و کِی به‌روز می‌کند.

منابع

$ ./request_review

همین مشکل را در فروشگاه خودتان دارید؟

توسعه‌دهنده ارشد WordPress و WooCommerce برای معماری، اتصال سیستم‌ها و حل مسائل پیچیده production.

درخواست بررسی فنی

دیدگاه‌ها

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *