دو نقص بحرانی در PHP؛ چرا مدیران سایت‌ها باید فوری به‌روزرسانی کنند؟
دو آسیب‌پذیری در موتور اجرای PHP می‌توانند به مهاجم اجازه دهند بدون ورود به حساب کاربری، روی سرور سایت کد اجرا کند؛ در یکی از مسیرهای تأییدشده، حمله پیش از اجرای کد خود سایت آغاز می‌شود.
پروژه PHP روز ۲۱ اکتبر ۲۰۲۶ برای رفع دو آسیب‌پذیری بحرانی، به‌روزرسانی امنیتی منتشر کرد. این نقص‌ها در شرایط مشخص به مهاجم اجازه می‌دهند بدون داشتن نام کاربری و رمز عبور، کد دلخواه خود را روی سرور اجرا کند. هشدار رسمی شامل نصب‌های PHP است که درخواست‌های وب را پردازش می‌کنند؛ نرم‌افزاری که بسیاری از سایت‌ها برای اجرای بخش اصلی خدمات خود به آن وابسته‌اند.
خطر فقط از دسترس خارج‌شدن سایت نیست. اجرای کد با دسترسی پردازش وب، بسته به مجوزهای آن، می‌تواند امکان خواندن اطلاعات، تغییر فایل‌ها یا دست‌کاری عملکرد سایت را فراهم کند. البته این دسترسی لزوماً به معنی در اختیار گرفتن کامل سیستم با بالاترین سطح مجوز نیست.
کمبود حافظه چگونه راه نفوذ باز می‌کند؟
نخستین آسیب‌پذیری با شناسه CVE-2026-109618 به نحوه برخورد PHP با کمبود حافظه مربوط است.
هر درخواست برای پردازش به مقداری حافظه نیاز دارد. PHP معمولاً سقفی برای مصرف حافظه تعیین می‌کند و وقتی درخواست از آن عبور کند، اجرای آن را متوقف می‌کند. مشکل اینجاست که این توقف ممکن است درست زمانی رخ دهد که بعضی ساختارهای داخلی هنوز کامل آماده نشده‌اند.
در ادامه، بخش مسئول پایان‌دادن به درخواست و آزادکردن منابع، ممکن است همین اطلاعات ناقص را معتبر فرض کند. این وضعیت به خرابی حافظه می‌انجامد و پژوهشگران نشان داده‌اند که می‌توان آن را به اجرای کد روی سرور تبدیل کرد.
در سرورهای Apache که PHP را با ماژول mod_php اجرا می‌کنند، این مسیر حتی پیش از اجرای کد سایت قابل فعال‌شدن است. یعنی بررسی ورودی‌ها در خود سایت ممکن است اصلاً فرصت جلوگیری از آن را پیدا نکند. اصلاح منتشرشده، نحوه توقف PHP هنگام کمبود حافظه را تغییر می‌دهد تا ساختارهای نیمه‌آماده وارد مرحله پاک‌سازی نشوند.
درخواست تمام می‌شود، اما رد آن در حافظه می‌ماند
آسیب‌پذیری دوم با شناسه CVE-2026-109619 به اطلاعاتی مربوط است که پس از پایان یک درخواست، به‌اشتباه در وضعیت داخلی PHP باقی می‌مانند.
پردازش‌های سرور معمولاً پس از پاسخ‌دادن به یک درخواست، برای رسیدگی به درخواست بعدی دوباره استفاده می‌شوند. اطلاعات مخصوص هر درخواست باید پیش از آزادشدن حافظه آن پاک شوند. اما بعضی خطاها می‌توانند این روند را ناقص بگذارند؛ در نتیجه، پردازش سرور همچنان به بخشی از حافظه اشاره می‌کند که دیگر معتبر نیست.
اگر درخواست بعدی به همان پردازش برسد و PHP دوباره از آن ارجاع استفاده کند، امکان دسترسی به حافظه آزادشده ایجاد می‌شود. پژوهشگران نشان داده‌اند که این وضعیت نیز می‌تواند به اجرای کد منجر شود.
یکی از مسیرهای تأییدشده به قابلیت ثبت پیشرفت بارگذاری فایل مربوط است. مسیر دیگری هنگام پردازش برخی تنظیمات نامعتبر یا قدیمی فعال می‌شود. پنهان‌کردن پیام‌های خطا این مشکل را حل نمی‌کند، چون دسترسی نامعتبر پیش از تصمیم PHP برای نمایش یا ثبت پیام اتفاق می‌افتد.
تغییر وب‌سرور جای به‌روزرسانی را نمی‌گیرد
خطر همه نصب‌ها دقیقاً یکسان نیست. معماری اجرای PHP تعیین می‌کند کدام مسیر حمله در دسترس باشد.
برای نمونه، PHP-FPM که در بسیاری از سرورها در کنار nginx استفاده می‌شود، هنگام شکست در آغاز پردازش درخواست، پردازش مربوط را خاتمه می‌دهد. این رفتار یکی از مسیرهای حمله را قطع می‌کند، اما به معنی مصونیت نیست. مسیرهای دیگری به رفتار برنامه و تنظیمات سرور وابسته‌اند و یک مسیر مربوط به اطلاعات باقی‌مانده میان درخواست‌ها در PHP-FPM نیز تأیید شده است. بنابراین مدیران این سرورها هم باید به‌روزرسانی کنند.
چرا اصلاح این مشکل طول کشید؟
بنیاد PHP می‌گوید نخستین نشانه‌های مشکل کمبود حافظه در سال ۲۰۲۴ پیدا شده بود، اما آن زمان راه عملی تبدیل آن به اجرای کد مشخص نبود.
رفع مشکل نیز به تغییر بخشی بنیادی از موتور PHP نیاز داشت. راه‌حل‌های پیشنهادی می‌توانستند سازگاری با نرم‌افزارهای موجود را مختل کنند، مشکل تازه‌ای برای پایداری سرویس بسازند یا به تغییر تعداد زیادی افزونه نیاز داشته باشند. بنیاد، تأخیر در اصلاح را به مشکلات ساختاری تصمیم‌گیری و کمبود نیروی متخصص نسبت داده است.
در اوت ۲۰۲۶، گزارش شرکت امنیتی Calif امکان اجرای کد با استفاده از همین نقص را روشن کرد. گزارش‌های مستقل OpenAI و Wiz نیز مسیرهای بیشتری را مشخص کردند و اصلاح مشکل در اولویت قرار گرفت. پس از انتشار عمومی شناسه‌های آسیب‌پذیری، عرضه وصله یک روز جلو افتاد و در ۲۱ اکتبر انجام شد.
مدیران سایت‌ها چه باید بکنند؟
اقدام اصلی، به‌روزرسانی خود PHP است. نسخه‌های 8.2.35، 8.3.36، 8.4.27 و 8.5.12 این دو آسیب‌پذیری را برطرف می‌کنند؛ مدیران باید نسخه اصلاح‌شده متناسب با شاخه مورد استفاده خود یا نسخه جدیدتر آن را نصب کنند. به‌روزرسانی وردپرس، قالب یا افزونه‌ها به‌تنهایی این نقص‌ها را رفع نمی‌کند، چون مشکل در موتور اجرای PHP است.
اگر مدیریت سرور با شرکت میزبان است، باید از پشتیبانی تأیید گرفت که اصلاحات روی PHP مورد استفاده سایت اعمال شده‌اند. در سرورهایی که بسته‌های PHP را از مخزن سیستم‌عامل دریافت می‌کنند، شماره نسخه به‌تنهایی معیار کافی نیست؛ بعضی توزیع‌ها وصله امنیتی را به نسخه موجود اضافه می‌کنند، بدون اینکه شماره اصلی آن را تغییر دهند. ملاک، تأیید دریافت اصلاحات مربوط به هر دو شناسه آسیب‌پذیری است.
برای PHP نسخه ۸٫۱ و قدیمی‌تر، باید وضعیت پشتیبانی و دریافت وصله را از تأمین‌کننده بررسی کرد. پروژه PHP برای برخی شاخه‌های قدیمی اصلاحات حداقلی منتشر کرده، اما این اقدام به معنی بازگشت پشتیبانی عادی آن‌ها نیست؛ مهاجرت به یک شاخه پشتیبانی‌شده همچنان ضروری است.
تغییر موقت تنظیمات می‌تواند بعضی مسیرهای حمله را محدود کند، اما هیچ تنظیم واحدی جای وصله را نمی‌گیرد. تیم PHP تأکید کرده که راه‌حل کامل، نصب نسخه اصلاح‌شده است؛ اقدام‌های موقت باید متناسب با معماری سرور و با توجه به اثر آن‌ها بر مصرف منابع و عملکرد سایت اجرا شوند.