PHP2Shell؛ بررسی جامع دو آسیب‌پذیری بحرانی

دسته‌بندی: امنیت وب، آسیب‌پذیری‌های نرم‌افزاری، امنیت سرور
تاریخ انتشار: ۲۳ اکتبر ۲۰۲۶
شدت خطر: بحرانی (CVSS v4.0: 9.2 از 10)
نام شناخته‌شده: PHP2Shell

مقدمه

در ۲۱ اکتبر ۲۰۲۶، تیم توسعه PHP دو آسیب‌پذیری امنیتی بحرانی را در موتور اصلی این زبان برنامه‌نویسی برطرف کرد. این آسیب‌پذیری‌ها با شناسه‌های CVE-2026-109618 و CVE-2026-109619 ثبت شده‌اند و در صورت بهره‌برداری موفق، می‌توانند امکان اجرای کد از راه دور بدون احراز هویت را فراهم کنند.

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

تیم PHP نسخه‌های اصلاح‌شده را منتشر کرده و نهادهای امنیت سایبری نیز به مدیران زیرساخت توصیه کرده‌اند دارایی‌های آسیب‌پذیر را شناسایی و در سریع‌ترین زمان ممکن اصلاح کنند.

منابع: هشدار رسمی PHP، گزارش CERT-EU، گزارش پژوهشی Wiz.

۱. آسیب‌پذیری PHP2Shell چیست؟

PHP2Shell نامی است که برای این مجموعه از دو نقص امنیتی در هسته PHP به کار می‌رود. هر دو نقص به مدیریت حافظه و وضعیت داخلی درخواست‌ها مربوط هستند، اما سازوکار فنی یکسانی ندارند.

آسیب‌پذیری اول: CVE-2026-109618

عنوان فنی: Remote Code Execution through Out-of-Memory handling

این نقص به نحوه مدیریت خطای اتمام حافظه (Out-of-Memory یا OOM) در PHP مربوط است.

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

در نتیجه، عملیات آزادسازی حافظه می‌تواند با داده‌های نامعتبر انجام شود و به تخریب حافظه منجر شود. در شرایط مناسب، این وضعیت می‌تواند مسیر اجرای کد دلخواه را برای مهاجم فراهم کند.

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

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

شناسه مرتبط با این نقص:

• CVE: CVE-2026-109618
• شناسه GitHub Security Advisory: GHSA-w8hw-w9fx-j79w
• شدت: بحرانی، CVSS v4.0 برابر ۹٫۲

آسیب‌پذیری دوم: CVE-2026-109619

عنوان فنی: Remote Code Execution through stale internal state / Use-After-Free

آسیب‌پذیری دوم به باقی‌ماندن وضعیت داخلی درخواست پس از آزادشدن حافظه مربوط است.

در این وضعیت، بخشی از اطلاعاتی که به یک درخواست تعلق داشته، ممکن است پس از آزادشدن حافظه همچنان در وضعیت داخلی Worker باقی بماند. اگر درخواست دیگری توسط همان Worker پردازش شود و پیش از بازنشانی صحیح وضعیت، به داده قدیمی دسترسی پیدا کند، ممکن است خطای Use-After-Free رخ دهد.

Use-After-Free یکی از خطاهای شناخته‌شده ایمنی حافظه است که در آن برنامه پس از آزادشدن یک ناحیه حافظه، همچنان از آن استفاده می‌کند. پیامد آن می‌تواند از اختلال در فرایند تا افشای اطلاعات حافظه یا اجرای کد دلخواه متغیر باشد.

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

شناسه مرتبط با این نقص:

• CVE: CVE-2026-109619
• شناسه GitHub Security Advisory: GHSA-6wmf-4rv5-p3rp
• شدت: بحرانی، CVSS v4.0 برابر ۹٫۲

منبع فنی هر دو آسیب‌پذیری: CERT-EU Security Advisory 2026-018.

۲. آیا برای حمله حتماً باید وردپرس یا جوملا نصب باشد؟

خیر. این یکی از مهم‌ترین نکات امنیتی PHP2Shell است.

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

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

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

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

• Apache با mod_php
• PHP-FPM
• php-cgi
• FrankenPHP
• LiteSpeed

طبق هشدار رسمی PHP، تمام نصب‌هایی که درخواست‌های وب را پردازش می‌کنند باید بررسی شوند و خطر در معماری mod_php بیشتر ارزیابی شده است.

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

منبع: PHP Security Advisory.

۳. کدام نسخه‌های PHP آسیب‌پذیر هستند؟

بر اساس اطلاعات منتشرشده توسط تیم PHP، نسخه‌های PHP از شاخه 5.4 تا نسخه 8.5.11 در محدوده نسخه‌های آسیب‌پذیر قرار می‌گیرند؛ البته وضعیت دقیق هر نقص و اصلاحیه‌های اختصاصی تأمین‌کنندگان باید بررسی شود.

نسخه‌های اصلاح‌شده منتشرشده عبارت‌اند از:

این جدول نسخه‌های رسمی اصلاح‌شده را نشان می‌دهد. اگر از بسته‌های اختصاصی توزیع لینوکس یا نسخه‌های پشتیبانی‌شده توسط تأمین‌کنندگان تجاری استفاده می‌کنید، شماره نسخه به‌تنهایی برای تشخیص وضعیت اصلاحیه کافی نیست؛ ممکن است اصلاحیه امنیتی به‌صورت Backport ارائه شده باشد.

شاخه‌های PHP 8.1 و قدیمی‌تر دیگر از سوی پروژه اصلی PHP پشتیبانی نمی‌شوند. برخی تأمین‌کنندگان ممکن است اصلاحیه اختصاصی ارائه دهند، اما وضعیت آن باید مستقیماً از تأمین‌کننده بررسی شود.

نکته: بررسی نسخه php -v به‌تنهایی کافی نیست. ممکن است نسخه PHP خط فرمان با نسخه فعال در Apache، PHP-FPM، یک کانتینر یا محیط میزبانی متفاوت باشد.

منبع: PHP Security Releases.

۴. پیامدهای احتمالی بهره‌برداری موفق

اگر مهاجم بتواند آسیب‌پذیری را با موفقیت فعال کند، بسته به معماری سرویس و سطح دسترسی فرایند PHP، پیامدهای زیر ممکن است رخ دهد:

• اجرای کد دلخواه روی سرور با سطح دسترسی فرایند آسیب‌پذیر.
• دسترسی غیرمجاز به فایل‌های پیکربندی و اطلاعات حساس قابل دسترسی برای آن فرایند.
• افشای اطلاعات حافظه، از جمله احتمال دسترسی به داده‌های حساس موجود در حافظه Worker.
• دسترسی به اطلاعات اتصال پایگاه داده، توکن‌ها و کلیدهای API، در صورتی که این اطلاعات در دسترس فرایند قرار داشته باشند.
• تغییر فایل‌های سایت یا ایجاد فایل‌های مخرب، در صورت وجود مجوز نوشتن مناسب.
• استفاده از سرور آسیب‌دیده به‌عنوان نقطه شروع حملات بعدی، در صورت وجود دسترسی‌ها و مسیرهای شبکه‌ای مناسب.

موفقیت در بهره‌برداری به معنای دستیابی خودکار به دسترسی root نیست. سطح دسترسی واقعی مهاجم به مجوزهای فرایند، جداسازی سرویس‌ها، سیاست‌های سیستم‌عامل و کنترل‌های امنیتی زیرساخت بستگی دارد.

۵. راهکار اصلی: نصب اصلاحیه امنیتی

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

اولویت اصلاح باید با سرویس‌هایی باشد که از اینترنت قابل دسترسی هستند و درخواست‌های ناشناس را پردازش می‌کنند.

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

۶. راهکار موقت Apache: محدودسازی درخواست‌های multipart در .htaccess

در برخی سناریوهای مرتبط با CVE-2026-109618، پردازش درخواست‌های multipart/form-data، از جمله درخواست‌های بارگذاری فایل، اهمیت دارد. به همین دلیل، محدودکردن چنین درخواست‌هایی می‌تواند یکی از اقدامات کاهش ریسک باشد.

اگر یک مسیر از سایت نیازی به دریافت فایل ندارد، می‌توان درخواست‌های POST، PUT و PATCH با این نوع محتوا را در آن مسیر مسدود کرد.

نمونه زیر برای Apache و فایل .htaccess ارائه شده است:

RewriteEngine On

RewriteCond %{REQUEST_METHOD} ^(POST|PUT|PATCH)$ [NC]
RewriteCond %{HTTP:Content-Type} ^[[:space:]]*multipart/form-data([;,[:space:]]|$) [NC]
RewriteRule ^ - [F,L]

در صورت فعال‌بودن mod_rewrite و مجازبودن این دستورها در پیکربندی Apache، درخواست‌های منطبق با شرایط بالا با پاسخ HTTP 403 رد می‌شوند.

محدودیت‌های این قاعده

این نمونه تنها درخواست‌های مشخص‌شده را فیلتر می‌کند و نباید به‌عنوان راهکار قطعی رفع PHP2Shell معرفی شود.

• درخواست‌های دیگر که از نوع multipart/form-data نیستند، تحت تأثیر این قاعده قرار نمی‌گیرند.
• اگر برنامه برای آپلود فایل به این درخواست‌ها نیاز داشته باشد، عملکرد آن مختل می‌شود.
• این قاعده به‌تنهایی تمام مسیرهای احتمالی مرتبط با CVE-2026-109618 و CVE-2026-109619 را پوشش نمی‌دهد.
• اگر درخواست از مسیری خارج از این پیکربندی عبور کند، ممکن است محدودیت اعمال نشود.

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

۷. محدودکردن درخواست‌های multipart به IPهای مجاز

در شرایطی که یک مسیر فقط باید از سوی IPهای مشخص سازمانی استفاده شود، می‌توان محدودیت IP را به همان قاعده اضافه کرد.

نمونه زیر پنج IP نمونه را مجاز می‌داند:

RewriteEngine On

RewriteCond %{REQUEST_METHOD} ^(POST|PUT|PATCH)$ [NC]
RewriteCond %{HTTP:Content-Type} ^[[:space:]]*multipart/form-data([;,[:space:]]|$) [NC]
RewriteCond %{REMOTE_ADDR} !^(192\.0\.2\.10|192\.0\.2\.11|198\.51\.100\.20|198\.51\.100\.21|203\.0\.113\.10)$
RewriteRule ^ - [F,L]

توجه: IPهای استفاده‌شده در این مثال، آدرس‌های رزروشده برای مستندسازی هستند و باید با IPهای عمومی واقعی و مورد اعتماد جایگزین شوند.

عملکرد قاعده:

• درخواست‌های منطبق با شرایط که از IPهای مجاز برسند، از این قاعده رد نمی‌شوند.
• درخواست‌های منطبق با شرایط که از سایر IPها برسند، پاسخ 403 دریافت می‌کنند.
• درخواست‌هایی که شرایط روش HTTP و نوع محتوا را ندارند، توسط این قاعده محدود نمی‌شوند.

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

نکات اجرایی مهم

۱. ابتدا قاعده را روی مسیر آزمایشی یا محیط کم‌خطر تست کنید.

۲. مطمئن شوید IP مشاهده‌شده در REMOTE_ADDR همان IP واقعی کلاینت است. در صورت استفاده از Reverse Proxy یا CDN، نباید بدون پیکربندی معتبر به سرآیندهای قابل جعل مانند X-Forwarded-For اعتماد کرد.

۳. تمام IPهای خروجی مورد اعتماد را شناسایی کنید؛ ممکن است دانشگاه چند IP عمومی یا مسیر NAT داشته باشد.

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

۵. بعد از اعمال تغییر، رفتار درخواست‌های مجاز و غیرمجاز و لاگ‌های وب‌سرور را بررسی کنید.

۸. اقدامات تکمیلی برای کاهش ریسک

در کنار محدودسازی درخواست‌ها، اقدامات زیر می‌توانند به کاهش سطح حمله کمک کنند:

• شناسایی تمام نسخه‌های PHP فعال در وب‌سرور، PHP-FPM و کانتینرها.
• بررسی تنظیمات محدودیت اندازه درخواست و فایل آپلود در وب‌سرور و PHP.
• بررسی تنظیمات session.upload_progress.enabled و اعمال تغییرات فقط مطابق راهنمای رسمی PHP و با درنظرگرفتن سازگاری برنامه.
• بازبینی لاگ‌های وب‌سرور، برنامه، احراز هویت و سیستم‌عامل برای شناسایی رفتارهای غیرعادی.
• بررسی فرایندها، فایل‌ها، حساب‌های کاربری و ارتباطات خروجی غیرمنتظره مرتبط با حساب سرویس وب.
• محدودکردن دسترسی فرایند PHP به فایل‌ها و منابع غیرضروری.
• در صورت امکان، محدودکردن دسترسی عمومی به سرویس آسیب‌پذیر تا زمان نصب اصلاحیه.

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

۹. جمع‌بندی

PHP2Shell نمونه‌ای از آسیب‌پذیری‌های جدی در لایه موتور اجرای زبان برنامه‌نویسی است. اهمیت این رخداد در آن است که وجود یک برنامه مدیریت محتوای آسیب‌پذیر شرط عمومی بهره‌برداری نیست؛ در برخی معماری‌ها، درخواست HTTP می‌تواند پیش از اجرای کد برنامه به مسیر آسیب‌پذیر PHP برسد.

دو شناسه CVE-2026-109618 و CVE-2026-109619 به نقص‌های متفاوت در مدیریت حافظه و وضعیت داخلی درخواست‌ها اشاره دارند. پیامد احتمالی آن‌ها می‌تواند اجرای کد از راه دور بدون احراز هویت باشد.

برای مدیران سرور، اولویت نخست شناسایی تمام محیط‌های PHP و نصب اصلاحیه رسمی است. محدودکردن درخواست‌های multipart/form-data، کنترل IPهای مجاز، کاهش سطح دسترسی سرویس و پایش لاگ‌ها می‌توانند در کاهش ریسک مؤثر باشند، اما هیچ‌یک به‌تنهایی جایگزین اصلاحیه امنیتی نیستند.

منابع

• PHP — Security Releases
• CERT-EU — Security Advisory 2026-018
• Wiz Research — PHP2Shell Technical Analysis
• Google Cloud — Responding to CVE-2026-109618 and CVE-2026-109619
• Canadian Centre for Cyber Security — Alert AL26-026