در ۲۱ اکتبر ۲۰۲۶ مرکز ملی امنیت سایبری بریتانیا (NCSC) هشداری با عنوان «Critical security issue affecting PHP» منتشر کرد. دو آسیب‌پذیری در خودِ PHP می‌تواند به مهاجم بدون احراز هویت اجازه‌ی اجرای کد از راه دور (RCE) روی وب‌سروری بدهد که PHP اجرا می‌کند. هر دو مورد در نسخه‌های جدید رفع شده‌اند.

اگر روی سرورهایتان PHP دارید، اول نسخه را آپدیت کنید و بعد این مقاله را بخوانید.

خلاصه

CVE-2026-109618CVE-2026-109619
عنوانRCE via OOM corruptionRCE via stale global state
امتیاز CVSS v4.0۹٫۲ (Critical)۹٫۲ (Critical)
بردارAV:N/AC:H/AT:P/PR:N/UI:NAV:N/AC:H/AT:P/PR:N/UI:N
نوع ضعفuse-after-free، مدیریت نادرست خطاuse-after-free، وضعیت global باقی‌مانده

هر دو آسیب‌پذیری از راه شبکه، بدون نیاز به لاگین و بدون تعامل کاربر قابل بهره‌برداری‌اند.

ماجرا چیست؟

CVE-2026-109618: PHP برای خطای کمبود حافظه (OOM) از longjmp() استفاده می‌کند. اگر تخصیص حافظه وسط مقداردهی اولیه‌ی داده‌های درخواست شکست بخورد، مرحله‌ی پاک‌سازی درخواست ممکن است داده‌ی نیمه‌ساخته را معتبر فرض کند. نتیجه خرابی حافظه است و در شرایطی RCE. محرک‌ها بیشتر به پردازش درخواست‌های multipart مربوط‌اند: درخواست بدون طول مشخص، تعداد نامحدود هدر در هر بخش، فیلدهای فایل خالی که در max_file_uploads حساب نمی‌شوند و نام فیلدهای تودرتو.

CVE-2026-109619: در Workerهایی که بین درخواست‌ها زنده می‌مانند، بخشی از وضعیت global (خطا، session، آبجکت و extension) می‌تواند بعد از آزاد شدن حافظه‌ی درخواست هنوز به آن اشاره کند. درخواست بعدیِ همان Worker ممکن است قبل از مقداردهی اولیه‌ی عادی از این وضعیت کهنه استفاده کند و به use-after-free برسد. نمونه‌ی تأییدشده‌ی بهره‌برداری، PHP 8.5 با fatal_error_backtraces فعال و همچنین چرخه‌ی session upload progress است.

چه چیزهایی تحت تأثیرند؟

نسخه‌های آسیب‌پذیر:

  • PHP ۸٫۲ پایین‌تر از 8.2.35
  • PHP ۸٫۳ پایین‌تر از 8.3.36
  • PHP ۸٫۴ پایین‌تر از 8.4.27
  • PHP ۸٫۵ پایین‌تر از 8.5.12

نسخه‌های رفع‌شده: 8.2.35، 8.3.36، 8.4.27 و 8.5.12.

NCSC تأکید می‌کند هر سازمانی که از PHP استفاده می‌کند در معرض خطر است، از جمله محصولات و appliance‌هایی که PHP را داخل خود دارند. نسخه‌های قدیمی‌تر از ۸٫۲ که پشتیبانی نمی‌شوند هم باید به نسخه‌ی پشتیبانی‌شده ارتقا پیدا کنند.

از نظر نحوه‌ی اجرا (طبق advisory رسمی PHP):

  • Apache mod_php: بهره‌برداری با تنظیمات پیش‌فرض و prefork معمولی روی HTTP تأیید شده است.
  • PHP-FPM: بر اساس تحلیل سورس آسیب‌پذیر است، هرچند exploit کامل نمایش داده نشده.
  • FrankenPHP و LSAPI: احتمالاً آسیب‌پذیرند ولی هنوز تأیید نشده.

چه کار کنیم؟

۱. آپدیت. تنها راه‌حل کامل، ارتقا به یکی از نسخه‌های رفع‌شده است.

۲. همه‌ی نصب‌های PHP را پیدا کنید. اول سیستم‌های در دسترس از اینترنت، و فقط به نسخه‌های قدیمی بسنده نکنید. کانتینرها، imageهای Docker و محصولات بسته‌بندی‌شده (پنل‌ها، CMSها، appliance‌ها) را هم چک کنید. NCSC هلند فهرستی از نرم‌افزارهای وابسته به PHP منتشر کرده: NCSC-NL/php2shell.

۳. اگر فوراً نمی‌توانید آپدیت کنید، این کاهش‌دهنده‌ها را اعمال کنید (کامل نیستند):

  • memory_limit=-1 را در سطح سرور تنظیم و همه‌ی Workerها را ری‌استارت کنید. از RLIMIT_AS و RLIMIT_DATA استفاده نکنید چون mmap() را شکست می‌دهند و مسیر آسیب‌پذیر را فعال می‌کنند.
  • post_max_size را محافظه‌کارانه نگه دارید و اندازه‌ی بدنه‌ی درخواست را در فرانت‌اند (Nginx/لودبالانسر) محدود کنید.
  • max_input_nesting_level را کم کنید و تعداد متغیرهای ورودی، بخش‌های multipart، هدرها و آپلودها را محدود کنید.
  • اگر اپلیکیشن از multipart/form-data استفاده نمی‌کند، این درخواست‌ها را در فرانت‌اند ببندید.
  • session.upload_progress.enabled=0 را تنظیم کنید و برای PHP 8.5 مقدار fatal_error_backtraces=0 بگذارید. سپس Workerها را ری‌استارت کنید.
  • اگر عملکرد مهم نیست، pm.max_requests=1 در PHP-FPM وضعیت باقی‌مانده بین درخواست‌ها را از بین می‌برد.

۴. اگر نه آپدیت ممکن است و نه کاهش‌دهنده‌ها، NCSC پیشنهاد می‌کند سیستم را موقتاً آفلاین کنید.

۵. نشانه‌های نفوذ را بررسی کنید. اگر سیستم تا الان در معرض اینترنت بوده، دنبال backdoor و فایل‌ها یا پردازش‌های ناشناس بگردید.

منابع