حفره امنیتی بحرانی PHP؛ PHP2Shell چیست و چگونه سایت را امن کنیم؟

اگر سایت شما با وردپرس، ووکامرس یا هر سیستم دیگری که روی PHP اجرا می‌شود ساخته شده است، بروزرسانی اخیر PHP چیزی نیست که بتوان آن را مانند یک آپدیت عادی به هفته‌ها یا ماه‌های آینده موکول کرد. در 21 اکتبر 2026 تیم امنیتی PHP دو حفره امنیتی بحرانی PHP را با شناسه‌های CVE-2026-109618 و CVE-2026-109619 معرفی و هم‌زمان نسخه‌های اصلاح‌شده PHP را منتشر کرد؛ آسیب‌پذیری‌هایی که با نام PHP2Shell شناخته می‌شوند و هر دو امتیاز 9.2 از 10 در CVSS v4.0 دارند. اهمیت ماجرا زمانی بیشتر می‌شود که بدانیم در شرایط مناسب، مهاجم می‌تواند بدون داشتن نام کاربری، رمز عبور یا دسترسی قبلی به سایت، از ضعف موجود در خود PHP برای اجرای کد روی سرور استفاده کند.

برای مدیران سایت‌های ایرانی، مخصوصاً سایت‌های وردپرسی و فروشگاه‌های ووکامرسی که روی هاست اشتراکی، سرور مجازی یا سرور اختصاصی قرار دارند، نکته بسیار مهم این است که این مشکل لزوماً مربوط به وردپرس، قالب یا افزونه سایت نیست؛ یعنی حتی اگر وردپرس شما کاملاً بروزرسانی شده باشد، افزونه‌ها از منابع معتبر نصب شده باشند و از یک افزونه امنیتی مناسب نیز استفاده کنید، در صورتی که نسخه PHP نصب‌شده روی سرور آسیب‌پذیر باشد همچنان باید وضعیت سرور بررسی شود. PHP اعلام کرده است که این آسیب‌پذیری‌ها می‌توانند نصب‌هایی را که درخواست‌های وب را از طریق PHP-FPM، Apache mod_php، php-cgi، FrankenPHP و LiteSpeed پردازش می‌کنند تحت تأثیر قرار دهند و در مورد mod_php سطح ریسک بالاتر ارزیابی شده است.

ماجرای حفره امنیتی PHP2Shell چیست؟

PHP در پشت بخش بزرگی از وب قرار دارد و بسیاری از کاربران حتی بدون اینکه مستقیماً با PHP کار کنند، روزانه از نرم‌افزارهایی استفاده می‌کنند که Backend آن‌ها با این زبان اجرا می‌شود. وردپرس یکی از مهم‌ترین نمونه‌هاست و تمام اجرای هسته وردپرس، افزونه‌ها، قالب‌ها و بخش قابل توجهی از فرآیندهای ووکامرس به محیط PHP وابسته هستند؛ به همین دلیل وجود یک آسیب‌پذیری در خود PHP می‌تواند نسبت به یک باگ معمولی در یک Plugin محدود، دامنه اثر بسیار گسترده‌تری داشته باشد.

طبق Advisory رسمی PHP، دو آسیب‌پذیری PHP2Shell به نحوه مدیریت حافظه و وضعیت داخلی PHP هنگام پردازش درخواست‌های HTTP مربوط هستند. PHP در روز 21 اکتبر 2026 نسخه‌های 8.5.12، 8.4.27، 8.3.36 و 8.2.35 را منتشر کرد و صراحتاً از مدیران سیستم خواست در سریع‌ترین زمان ممکن بروزرسانی کنند. تیم PHP همچنین تأکید کرده است که راهکارهای موقت تنها می‌توانند برخی مسیرهای حمله را محدود کنند و بروزرسانی PHP تنها راهکار کامل برای رفع مشکل است.

اهمیت این مسئله تا حدی بود که ENISA، کمیسیون اروپا، CERT-EU، Europol و شبکه CSIRTهای اروپایی به‌صورت مشترک از سازمان‌ها خواستند سیستم‌های PHP خود را شناسایی کرده و به‌خصوص سیستم‌های متصل به اینترنت را در اولویت بروزرسانی قرار دهند. NCSC بریتانیا نیز توصیه مشابهی منتشر کرده و اعلام کرده است که مدیران زیرساخت نباید بررسی را فقط به نسخه‌های بسیار قدیمی PHP محدود کنند، بلکه باید تمام نصب‌های PHP را شناسایی و وضعیت Patch آن‌ها را کنترل کنند.

CVE-2026-109618 چگونه کار می‌کند؟

اولین آسیب‌پذیری با شناسه CVE-2026-109618 به شرایط Out of Memory یا همان OOM مربوط می‌شود. به زبان ساده، در بعضی شرایط PHP ممکن است هنگام پردازش یک Request به محدودیت حافظه برسد و اجرای یک مرحله داخلی به شکلی متوقف شود که بخشی از اطلاعات مربوط به Request هنوز به‌طور کامل مقداردهی نشده باشند. فرآیند پاک‌سازی بعدی ممکن است این داده ناقص را معتبر تصور کند و همین وضعیت می‌تواند به Memory Corruption یا خرابی حافظه منجر شود.

این نوع باگ‌ها از دید یک توسعه‌دهنده وب جدی هستند، زیرا مسئله فقط Crash کردن PHP یا نمایش خطای Memory Limit نیست. هنگامی که Memory Corruption به شکل قابل کنترل رخ دهد، در بعضی شرایط می‌تواند مسیر اجرای برنامه را تحت تأثیر قرار دهد و در نهایت امکان Remote Code Execution یا RCE ایجاد کند. NCSC نیز توضیح داده است که مهاجم ممکن است شرایط OOM را ایجاد کند و از خرابی حاصل در حافظه برای رسیدن به اجرای کد بدون احراز هویت استفاده کند.

از دید مدیر وردپرس، نکته مهم این است که رفع این مشکل با افزایش Memory Limit وردپرس، نصب Wordfence یا تغییر قالب انجام نمی‌شود؛ زیرا ضعف اصلی در Runtime خود PHP قرار دارد. این موضوع دقیقاً تفاوت بین یک آسیب‌پذیری Application-Level و یک آسیب‌پذیری Runtime-Level را نشان می‌دهد.

CVE-2026-109619 چیست؟

آسیب‌پذیری دوم با شناسه CVE-2026-109619 به حالتی مربوط است که بخشی از State یا وضعیت داخلی متعلق به یک Request، بعد از آزاد شدن حافظه همچنان باقی می‌ماند و Request بعدی که توسط همان Worker پردازش می‌شود ممکن است پیش از Reset شدن کامل این وضعیت، از داده‌ای استفاده کند که دیگر معتبر نیست. این کلاس از مشکلات در سطح پایین برنامه‌نویسی معمولاً با مفاهیمی مانند Use-After-Free و Stale State شناخته می‌شود و در صورت قابل کنترل بودن می‌تواند بسیار خطرناک باشد.

در عمل مهاجم برای سوءاستفاده موفق از این نوع آسیب‌پذیری باید شرایط مشخصی ایجاد کند و تمام PoCهای منتشرشده لزوماً روی تمام سرورها قابل اجرا نیستند. Rapid7 گزارش کرده است که Proof of Conceptهای عمومی برای این دو CVE منتشر شده‌اند، اما قابلیت اطمینان آن‌ها به ترکیب سیستم‌عامل، نسخه PHP، وب‌سرور و شرایط حافظه بستگی دارد و یک Exploit عمومی که بدون توجه به محیط روی همه سرورها کار کند تأیید نشده است. همین موضوع نباید باعث تعویق بروزرسانی شود، زیرا با انتشار جزئیات فنی، زمان لازم برای توسعه Exploitهای قابل‌اعتمادتر معمولاً کاهش پیدا می‌کند.

آیا سایت‌های وردپرسی هم در معرض این حفره امنیتی PHP هستند؟

بله، اما باید این موضوع را درست بیان کنیم. این آسیب‌پذیری حفره امنیتی وردپرس نیست و اصلاح آن نیز با بروزرسانی WordPress Core انجام نمی‌شود؛ مشکل در PHP قرار دارد و از آنجا که WordPress برای اجرای درخواست‌های خود از PHP استفاده می‌کند، یک سایت وردپرسی که روی PHP آسیب‌پذیر اجرا می‌شود می‌تواند در محدوده ریسک قرار بگیرد.

در نتیجه اگر شما وردپرس 6.x یا نسخه جدیدتری دارید، تمام افزونه‌ها و قالب‌ها را بروزرسانی کرده‌اید و حتی از افزونه امنیتی استفاده می‌کنید، همچنان باید نسخه و Patch Level محیط PHP هاست را کنترل کنید. در برخی مسیرهای حمله، مخصوصاً در شرایطی که PHP به شکل Apache mod_php اجرا می‌شود، ضعف می‌تواند حتی قبل از اینکه کد اصلی Application وارد فرآیند شود مورد استفاده قرار بگیرد؛ بنابراین Hardening خود WordPress جایگزین Patch کردن PHP نیست. PHP نیز mod_php را در میان روش‌های اجرا پرریسک‌تر ارزیابی کرده است.

کدام نسخه‌های PHP امن شده‌اند؟

نسخه‌های اصلاح‌شده‌ای که PHP در 21 اکتبر 2026 منتشر کرده است به شکل زیر هستند:

اگر روی یکی از این Branchها هستید و نسخه شما پایین‌تر از مقدار جدول است، باید بروزرسانی را در اولویت بالا قرار دهید. PHP همچنین اعلام کرده است که نسخه 8.2 در 31 دسامبر 2026 به پایان عمر خود می‌رسد و پس از آن دیگر Security Fixهای معمول را از پروژه PHP دریافت نخواهد کرد، بنابراین اگر در حال حاضر روی 8.2 هستید بهتر است علاوه بر نصب Patch امنیتی، برای مهاجرت به یک شاخه پشتیبانی‌شده جدیدتر نیز برنامه داشته باشید.

PHP 8.1 و نسخه‌های قدیمی‌تر دیگر بروزرسانی‌های عادی پروژه اصلی PHP را دریافت نمی‌کنند. به دلیل شدت بالای این مشکل، PHP برای 7.4، 8.0 و 8.1 Backportهای محدودی منتشر کرده است تا Vendorها یا افرادی که PHP را از Source کامپایل می‌کنند بتوانند Patch را اعمال کنند، اما برای یک سایت معمولی وردپرسی ادامه استفاده طولانی‌مدت از شاخه End-of-Life تصمیم مناسبی نیست.

چگونه نسخه PHP سایت وردپرسی خود را بررسی کنیم؟

اگر مدیر یک سایت وردپرسی هستید، ساده‌ترین روش این است که از پیشخوان وردپرس وارد مسیر ابزارها ← سلامت سایت ← اطلاعات ← سرور شوید و نسخه PHP را مشاهده کنید. در هاست‌هایی که از cPanel استفاده می‌کنند نیز معمولاً بخش‌هایی مانند MultiPHP Manager یا Select PHP Version وجود دارند و در DirectAdmin نیز بسته به تنظیمات شرکت هاست، امکان مشاهده یا تغییر PHP Version در بخش مدیریت PHP وجود دارد.

یک نکته مهم این است که تنها دیدن عدد نسخه همیشه برای نتیجه‌گیری کافی نیست، زیرا برخی Distributionهای لینوکسی و شرکت‌های ارائه‌دهنده LTS ممکن است Patch امنیتی را روی نسخه موجود Backport کنند بدون اینکه شماره Version دقیقاً مطابق نسخه رسمی PHP تغییر کند. PHP اعلام کرده است که Vendorهای لینوکسی و LTS پیش از انتشار عمومی Patchها را دریافت کرده‌اند، بنابراین اگر روی هاست اشتراکی قرار دارید بهتر است از پشتیبانی سؤال مشخصی بپرسید: «آیا PHP سرور برای CVE-2026-109618 و CVE-2026-109619 Patch شده است؟»، نه اینکه صرفاً بپرسید «PHP سرور آپدیت است؟».

کاربران هاست‌های ایرانی چه کاری باید انجام دهند؟

اگر از یک هاست اشتراکی ایرانی استفاده می‌کنید، معمولاً امکان بروزرسانی Binary اصلی PHP در اختیار شما نیست و این مسئولیت برعهده شرکت Hosting قرار دارد. در چنین شرایطی ابتدا نسخه PHP را بررسی کنید و سپس از طریق تیکت از پشتیبانی بخواهید وضعیت این دو CVE را اعلام کند. اگر شرکت هاست امکان انتخاب نسخه PHP دارد، مهاجرت به نسخه اصلاح‌شده را انجام دهید؛ البته قبل از تغییر Branch، سازگاری قالب، افزونه‌ها و ووکامرس را روی Backup یا Staging بررسی کنید تا سایت پس از تغییر نسخه دچار Fatal Error نشود.

اگر VPS یا سرور اختصاصی دارید، مسئولیت Patch کاملاً جدی‌تر است. بسته‌های سیستم‌عامل را از Repository معتبر بروزرسانی کنید و پس از نصب نسخه اصلاح‌شده، PHP-FPM یا وب‌سرور مرتبط را Restart کنید تا Workerهای قدیمی در حافظه باقی نمانند. اگر از کنترل‌پنل‌هایی مانند DirectAdmin، cPanel یا Plesk استفاده می‌کنید، بهتر است علاوه بر PHP Version وضعیت Packageهای ارائه‌شده توسط خود کنترل‌پنل را نیز بررسی کنید.

آیا راهکار موقت بدون آپدیت وجود دارد؟

PHP چند Mitigation موقت منتشر کرده، از جمله تغییر بعضی تنظیمات Memory و غیرفعال کردن session.upload_progress، اما در همان Advisory رسمی تأکید کرده است که این روش‌ها فقط مسیرهای مشخصی از حمله را محدود می‌کنند و نصب Patch تنها راه‌حل کامل است. برای CVE-2026-109618 پیشنهادهایی مانند تنظیم مدیریتی memory_limit=-1 و محدود کردن post_max_size ارائه شده و برای CVE-2026-109619 نیز غیرفعال کردن session.upload_progress.enabled پیش از پردازش Request مطرح شده است، اما هیچ‌کدام نباید به‌عنوان جایگزین دائمی بروزرسانی استفاده شوند.

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

آیا این حفره امنیتی PHP در حال سوءاستفاده است؟

وضعیت Threat Intelligence در روزهای بعد از انتشار به‌سرعت در حال تغییر بوده است. Rapid7 اعلام کرده که چند PoC عمومی منتشر شده و گزارش‌هایی از تلاش برای Exploit وجود دارد، هرچند Exploitهای فعلی به شرایط محیط وابسته‌اند و این شرکت تا زمان گزارش خود سوءاستفاده گسترده و قابل اتکایی را روی همه محیط‌ها تأیید نکرده است. در عین حال شرکت‌های امنیتی مختلف به مدیران سیستم توصیه کرده‌اند انتشار PoC را به‌عنوان یک فرصت برای مهاجم در نظر بگیرند و Patch را خارج از چرخه عادی بروزرسانی انجام دهند.

Palo Alto Networks نیز در بررسی خود بیش از 22.6 میلیون Instance در معرض اینترنت را بر اساس Telemetry خود به‌عنوان سیستم‌های بالقوه در معرض این دو CVE شناسایی کرده است؛ عددی که به‌خوبی نشان می‌دهد چرا این آسیب‌پذیری از یک Bug معمولی PHP مهم‌تر است.

بعد از بروزرسانی PHP چه چیزهایی را بررسی کنیم؟

اگر سرور شما مدتی با نسخه آسیب‌پذیر در اینترنت فعال بوده است، بهتر است بروزرسانی را پایان کار در نظر نگیرید. Access Log و Error Log سرور را بررسی کنید و به دنبال رفتارهای غیرعادی مانند اجرای Processهای ناشناخته توسط PHP، ایجاد فایل‌های PHP جدید در پوشه‌های writable، تغییر کاربران مدیریتی، Cronهای ناشناس یا فایل‌هایی که اخیراً بدون دلیل تغییر کرده‌اند بگردید.

برای سایت وردپرسی، فایل‌های WordPress Core را با نسخه رسمی مقایسه کنید، کاربران Administrator را بررسی کنید، Plugin و Themeهای ناشناخته را حذف کنید، Passwordهای حساس را در صورت مشاهده شواهد نفوذ تغییر دهید و از یک Scanner امنیتی معتبر برای بررسی فایل‌ها استفاده کنید. اگر نشانه جدی از Compromise مشاهده شد، تنها حذف یک فایل مشکوک کافی نیست و باید فرآیند Incident Response کامل انجام شود.

آیا افزونه امنیتی وردپرس جلوی PHP2Shell را می‌گیرد؟

یک افزونه امنیتی می‌تواند در تشخیص رفتار مشکوک، محدود کردن برخی Requestها و شناسایی فایل‌های تغییرکرده مفید باشد، اما نباید از آن به‌عنوان Patch این آسیب‌پذیری استفاده کرد. چون PHP2Shell در Runtime خود PHP قرار دارد، راهکار اصلی همچنان بروزرسانی PHP است و هیچ افزونه وردپرسی نمی‌تواند تضمین کند تمام مسیرهای Exploit یک Memory Corruption در PHP را مسدود خواهد کرد.

Firewall، WAF و افزونه امنیتی را باید به‌عنوان لایه‌های اضافی دفاع در عمق در نظر گرفت، نه جایگزین بروزرسانی نرم‌افزار.

جمع‌بندی؛ آیا باید PHP سایت را فوراً بروزرسانی کنیم؟

پاسخ کوتاه بله است. CVE-2026-109618 و CVE-2026-109619 دو حفره امنیتی بحرانی در PHP هستند که امکان Remote Code Execution بدون احراز هویت را در شرایط خاص ایجاد می‌کنند و به دلیل گستردگی استفاده PHP، تأثیر بالقوه آن‌ها بسیار بالاست. تیم PHP، ENISA و NCSC همگی روی بروزرسانی فوری سیستم‌های اینترنتی تأکید کرده‌اند و PHP نیز اعلام کرده است که Mitigationهای موقت جای Patch کامل را نمی‌گیرند.

اگر سایت وردپرسی یا ووکامرسی دارید، ابتدا نسخه PHP را بررسی کنید و در صورت استفاده از PHP 8.2 پایین‌تر از 8.2.35، PHP 8.3 پایین‌تر از 8.3.36، PHP 8.4 پایین‌تر از 8.4.27 یا PHP 8.5 پایین‌تر از 8.5.12 وضعیت Patch را با شرکت هاست بررسی کنید. برای کاربران هاست اشتراکی در ایران، ارسال یک تیکت دقیق به Hosting معمولاً مهم‌ترین اقدام است؛ برای مدیران VPS و سرور اختصاصی نیز Patch کردن Packageهای PHP و Restart سرویس‌های مرتبط باید در اولویت فوری قرار گیرد.