PHP2Shell در 2026: آسیب‌پذیری‌های بحرانی PHP و کارهایی که باید کرد

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

در 21 اکتبر 2026، تیم توسعه‌ی PHP به‌روزرسانی‌های امنیتی اضطراری برای دو آسیب‌پذیری بحرانی منتشر کرد: CVE-2026-109618 و CVE-2026-109619 که با هم به PHP2Shell معروف‌اند.

هر دو آسیب‌پذیری امتیاز شدت بحرانی 9.2 از 10 در CVSS v4.0 گرفته‌اند. در شرایط خاص، به مهاجم اجازه می‌دهند بدون احراز هویت روی سرورهای آسیب‌پذیر کد مخرب اجرا کند.

پیامدهای آن خیلی فراتر از چند سایت است. PHP پایه‌ی سیستم‌های مدیریت محتوای بزرگ، پلتفرم‌های فروشگاهی، نرم‌افزارهای تجاری و سرویس‌های وب اختصاصی است.

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

”وقتی آسیب‌پذیری زیر خود نرم‌افزار وجود دارد، سایت شما چقدر امن است؟

این تحلیل بررسی می‌کند چه اتفاقی افتاد، این آسیب‌پذیری‌ها چطور کار می‌کنند، چه سایت‌هایی درگیرند، پژوهشگران امنیتی چه دیده‌اند و کسب‌وکارها برای کاهش خطر چه باید بکنند.

PHP2Shell چیست؟

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

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

این آسیب‌پذیری‌ها روی نحوه‌ی برخورد PHP با برخی خطاها و مدیریت حافظه در همین فرایند اثر می‌گذارند.

هر دو می‌توانند به اجرای کد از راه دور (RCE) منجر شوند؛ یعنی مهاجم ممکن است بتواند روی سرور آسیب‌پذیر دستور اجرا کند.

مهم‌تر اینکه این حملات لزوماً نیازی ندارند مهاجم وارد سایت شود.

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

PHP2Shell خود محیط اجرای PHP را درگیر می‌کند.

در نتیجه، فقط به‌روزرسانی افزونه‌های وردپرس این آسیب‌پذیری‌ها را برطرف نمی‌کند.

اطلاعیه‌ی امنیتی رسمی PHP چند محیط سرور را که ممکن است درگیر باشند نام می‌برد، از جمله PHP-FPM، Apache با mod_php، php-cgi، FrankenPHP و LiteSpeed.

توضیح دو آسیب‌پذیری بحرانی PHP

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

1. CVE-2026-109618: خرابی حافظه هنگام خطای کمبود حافظه

شدت: بحرانی — CVSS 9.2

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

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

اما پژوهشگران دریافتند این توقف ممکن است درست زمانی رخ دهد که ساختارهای داده‌ی داخلی فقط نیمه‌کاره مقداردهی شده‌اند.

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

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

این مشکل در پیکربندی‌های Apache که از mod_php استفاده می‌کنند جدی‌تر است؛ پژوهشگران نشان دادند یک درخواست HTTP بدون احراز هویت می‌تواند پیش از شروع اجرای کد نرم‌افزار، آسیب‌پذیری را فعال کند.

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

جزئیات فنی در اطلاعیه‌ی امنیتی رسمی CVE-2026-109618 آمده است.

2. CVE-2026-109619: استفاده‌ی دوباره از حافظه پس از آزاد شدن

شدت: بحرانی — CVSS 9.2

آسیب‌پذیری دوم به وضعیت داخلی کهنه و یک مشکل ایمنی حافظه به نام استفاده پس از آزادسازی (use-after-free) مربوط است.

پردازشگرهای PHP هنگام پردازش درخواست‌ها برخی ساختارهای داخلی را نگه می‌دارند.

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

پژوهشگران دریافتند خطاهای خاصی می‌توانند این فرایند پاک‌سازی را قطع کنند.

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

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

این حمله از نظر فنی پیچیده است و به عواملی مثل پیکربندی PHP، رفتار پردازشگرها و شرایط پردازش درخواست بستگی دارد.

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

اطلاعیه‌ی رسمی CVE-2026-109619 جزئیات فنی بیشتری ارائه می‌دهد.

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

در 21 اکتبر 2026، تیم توسعه‌ی PHP برای هر چهار شاخه‌ی پایدار پشتیبانی‌شده به‌روزرسانی امنیتی منتشر کرد.

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

پروژه‌ی PHP دیگر برای PHP 8.1 و نسخه‌های قدیمی‌تر پشتیبانی منظم ارائه نمی‌دهد. برخی توزیع‌های سازمانی لینوکس و ارائه‌دهندگان پشتیبانی بلندمدت ممکن است وصله‌های امنیتی را به نسخه‌های قدیمی منتقل کنند؛ یعنی سیستم ممکن است وصله را دریافت کند بدون اینکه شماره‌ی نسخه‌اش تغییر کند.

اما کسب‌وکارها باید این اصلاحات را با ارائه‌دهنده‌ی نرم‌افزار یا هاستینگ خود تأیید کنند.

یک نکته‌ی بلندمدت هم هست: پشتیبانی PHP 8.2 در 31 دسامبر 2026 تمام می‌شود. سایت‌هایی که روی این شاخه‌اند باید برنامه‌ریزی برای مهاجرت به نسخه‌ی جدیدتر و پشتیبانی‌شده را شروع کنند.

منبع: نسخه‌های پشتیبانی‌شده‌ی PHP .

آسیب‌پذیری سوم در 23 اکتبر افشا شد

اعلام اولیه‌ی PHP2Shell پایان ماجرا نبود.

در 23 اکتبر، تیم PHP یک مشکل احتمالی دیگر از نوع اجرای کد از راه دور را با شناسه‌ی CVE-2026-115560 افشا کرد.

این آسیب‌پذیری با دو مورد اول فرق دارد.

طبق اطلاعیه‌ی PHP، سوءاستفاده از آن نیازمند ترکیب غیرمعمولی از پیکربندی و رفتار نرم‌افزار است.

به‌طور مشخص، نرم‌افزار باید ابتدا session.serialize_handler را روی php_binary یا php_serialize تنظیم کند، پیش از شروع سشن در حین اجرا آن را به php تغییر دهد و قابلیت پیشرفت آپلود سشن PHP هم فعال باشد.

نرم‌افزارهایی که هیچ‌وقت در حین اجرا هندلر سریال‌سازی سشن را تغییر نمی‌دهند در معرض این مسیر حمله نیستند.

نکته‌ی مهم اینکه به‌روزرسانی‌های 21 اکتبر PHP مشکل CVE-2026-115560 را برطرف نمی‌کنند.

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

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

session.upload_progress.enabled=0

این تنظیم باید از طریق پیکربندی مناسب در سطح سرور اعمال شود و پس از آن پردازشگرهای PHP دوباره راه‌اندازی شوند.

برای دو آسیب‌پذیری اول، تغییر پیکربندی جایگزین کاملی برای نصب وصله نیست.

این تفاوت مهم است: سایتی که در برابر دو آسیب‌پذیری بحرانی PHP2Shell به‌روز شده، ممکن است هنوز برای مشکل تازه افشاشده به بازبینی پیکربندی نیاز داشته باشد.

منبع: اطلاعیه‌های امنیتی PHP، 23 اکتبر .

این خطر چقدر گسترده است؟

دامنه‌ی احتمالی خطر قابل‌توجه است.

واحد 42 شرکت Palo Alto Networks در تحلیل تهدید اکتبر 2026 گزارش داد که با داده‌های Cortex Xpanse بیش از 22.6 میلیون نمونه‌ی در دسترس از اینترنت را که احتمالاً آسیب‌پذیرند در برابر CVE-2026-109618 و CVE-2026-109619 شناسایی کرده است.

این عدد را باید با احتیاط تفسیر کرد.

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

قابلیت واقعی سوءاستفاده به نسخه‌های PHP، پیکربندی‌ها، معماری وب‌سرور و سایر شرایط فنی بستگی دارد.

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

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

منبع: گزارش تهدید Unit 42 شرکت Palo Alto Networks .

آیا مهاجمان واقعاً از PHP2Shell سوءاستفاده کرده‌اند؟

برای جواب به این سؤال باید سه رویداد متفاوت را از هم جدا کرد:

این رویدادها یکی نیستند.

قابلیت سوءاستفاده از این آسیب‌پذیری‌ها اثبات شده و انتشار عمومی کدهای اثبات مفهوم (PoC) خطر را بیشتر کرده است.

واحد هوش تهدید آمازون گزارش داد که یک تلاش برای سوءاستفاده از PHP2Shell را در 17 اکتبر 2026 شناسایی کرده؛ چهار روز پیش از انتشار به‌روزرسانی‌های امنیتی رسمی.

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

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

گزارش‌های اولیه‌ی چند شرکت امنیتی هم به اصلاح نیاز پیدا کردند.

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

در 25 اکتبر، Unit 42 شرکت Palo Alto Networks هم انتساب قبلی یک حادثه‌ی مرتبط با دولت به PHP2Shell را پس گرفت، چون مشخص شد روش دسترسی اولیه قابل تأیید نیست.

مرکز ملی امنیت سایبری هلند هم گزارش داد که سوءاستفاده پیچیده‌تر از برآورد اولیه به نظر می‌رسد و این احتمال حملات موفق گسترده را کم می‌کند.

”تا 26 اکتبر 2026، شواهد معتبری از تلاش‌های واقعی برای سوءاستفاده وجود دارد، اما شواهد عمومی موجود هک‌های موفق گسترده را ثابت نمی‌کند.

این تفاوت را نباید دلیلی برای عقب انداختن نصب وصله دانست.

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

منابع: وبلاگ امنیتی AWS ، پژوهش تهدید Sophos و NCSC هلند .

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

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

ووکامرس هم که به‌طور گسترده برای ساخت فروشگاه اینترنتی استفاده می‌شود، داخل اکوسیستم وردپرس کار می‌کند.

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

اما مهم است بدانیم این آسیب‌پذیری چه معنایی دارد — و چه معنایی ندارد.

PHP2Shell آسیب‌پذیری خود وردپرس نیست.

پروژه‌ی وردپرس در 21 اکتبر صریحاً تأیید کرد که برای رفع این آسیب‌پذیری‌های PHP، هیچ به‌روزرسانی در هسته‌ی وردپرس لازم نیست و برنامه‌ای هم برایش وجود ندارد.

بخش درگیر، محیط اجرای PHP است که روی سرور نصب شده.

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

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

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

با این حال، صاحبان کسب‌وکار باید محیط اجرای PHP را بخش اساسی امنیت سایت‌شان بدانند.

منبع: اطلاعیه‌ی امنیتی رسمی وردپرس .

اثر بر کسب‌وکار: فراتر از امنیت فنی

پیامدهای احتمالی PHP2Shell به تیم فنی‌ای که سرور را نگهداری می‌کند محدود نیست.

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

1. در دسترس بودن سایت و درآمد

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

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

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

ممکن است یک کمپین بازاریابی همچنان ترافیک را به سایتی بفرستد که دیگر نمی‌تواند بازدیدکننده را به مشتری تبدیل کند.

2. محرمانگی داده‌ها

اجرای موفق کد از راه دور می‌تواند به مهاجم دسترسی به منابعی بدهد که در اختیار فرایند PHP هک‌شده است.

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

میزان دسترسی به نحوه‌ی استقرار هر سیستم بستگی دارد.

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

3. سئو و دیده شدن در جست‌وجو

حوادث امنیتی می‌توانند خطرهای جانبی برای سئو هم ایجاد کنند.

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

چنین حوادثی می‌تواند به هشدارهای جست‌وجو، مشکلات ایندکس و کاهش اعتماد کاربران منجر شود.

از دسترس خارج شدن سایت و ناپایداری فنی هم ممکن است روی خزش موتورهای جست‌وجو و دسترسی بازدیدکنندگان به صفحه‌های مهم اثر بگذارد.

اما وجود یک آسیب‌پذیری PHP به‌خودی‌خود باعث جریمه‌ی رتبه در گوگل نمی‌شود.

پیامدهای سئو به این بستگی دارد که هکی رخ دهد یا نه و آیا روی در دسترس بودن، محتوا یا دسترسی موتورهای جست‌وجو به سایت اثر بگذارد.

4. اعتبار برند

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

آن‌ها فقط نتیجه را تجربه می‌کنند.

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

برای شرکت‌هایی که روی تبلیغات دیجیتال، برندینگ و جذب مشتری سرمایه‌گذاری سنگینی می‌کنند، امنیت سایت مستقیماً با عملکرد تجاری‌شان گره خورده است.

چرا رفع این آسیب‌پذیری این‌قدر طول کشید؟

یکی از مهم‌ترین جنبه‌های ماجرای PHP2Shell، تاریخچه‌ی آن است.

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

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

رفع این مشکل هم بده‌بستان‌های فنی جدی داشت.

برخی راه‌حل‌های پیشنهادی ممکن بود سازگاری با نسخه‌های قبلی را بشکنند، مشکلات از کار انداختن سرویس (DoS) ایجاد کنند یا تغییرات گسترده‌ای در افزونه‌های شخص ثالث PHP لازم داشته باشند.

بنیاد PHP پذیرفت که منابع مهندسی محدود و دشواری در تصمیم‌گیری در این تأخیر نقش داشته‌اند.

در اوت 2026، پژوهش‌های بیشتر سناریوهای عملی حمله را نشان داد و شدت مشکل را روشن کرد.

مشارکت پژوهشی Calif، OpenAI، Wiz و سایر تیم‌های امنیتی به مشخص شدن میزان اثر و سرعت گرفتن واکنش کمک کرد.

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

درس بزرگ‌تر به چالش‌های امنیتی نگهداری زیرساخت‌های متن‌باز پرکاربرد مربوط است.

نرم‌افزارهای امروزی به اجزای پیچیده‌ای وابسته‌اند که گروه‌های نسبتاً کوچکی از توسعه‌دهندگان متخصص نگهداری‌شان می‌کنند.

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

منبع: بنیاد PHP — انتشار امنیتی امروز PHP و اینکه چطور امنیت PHP را تقویت می‌کنیم .

چطور بفهمید سایت‌تان درگیر است

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

سایت‌های وردپرسی

وارد پیشخوان مدیریت وردپرس شوید و به این مسیر بروید:

Tools → Site Health → Info → Server (ابزارها ← سلامت سایت ← اطلاعات ← سرور)

نسخه‌ی PHP باید در بخش اطلاعات سرور نمایش داده شود.

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

سایت‌هایی که از cPanel استفاده می‌کنند

هاست‌هایی که cPanel دارند معمولاً مدیریت نسخه‌ی PHP را از طریق ابزارهایی مثل MultiPHP Manager یا انتخابگر PHP شرکت هاستینگ ارائه می‌دهند.

این ابزارها به شناسایی یا تغییر نسخه‌ی PHP یک دامنه کمک می‌کنند.

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

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

سرور مجازی (VPS)، سرور اختصاصی و محیط‌های ابری

مدیران سرور باید نسخه‌ی PHP‌ای را که نرم‌افزار وب فعال از آن استفاده می‌کند بررسی کنند.

دستور php -v نسخه‌ی PHP خط فرمان را نشان می‌دهد، اما لزوماً محیط اجرای PHP‌ای را که به درخواست‌های سایت پاسخ می‌دهد مشخص نمی‌کند.

سرورها ممکن است چند نسخه‌ی PHP یا پیکربندی‌های جداگانه برای خط فرمان و ترافیک وب داشته باشند.

برای همین مدیران باید PHP-FPM pool واقعی، ماژول Apache، ایمیج کانتینر یا محیط هاستینگ مربوط را بررسی کنند.

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

صاحبان سایت همین حالا چه کنند

یک واکنش هماهنگ مؤثرتر از تغییر تصادفی تنظیمات امنیتی یا این فرض است که فایروال محافظت کامل می‌دهد.

آیا Cloudflare یا فایروال نرم‌افزار وب (WAF) از سایت در برابر PHP2Shell محافظت می‌کند؟

فایروال نرم‌افزار وب (WAF) می‌تواند به شناسایی و مسدود کردن برخی درخواست‌های HTTP مخرب کمک کند.

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

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

تیم PHP صریحاً اعلام کرده که راهکارهای موقت در برابر دو آسیب‌پذیری بحرانی اول محافظت کامل نمی‌دهند.

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

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

مثلاً غیرفعال کردن سقف عادی حافظه‌ی PHP بدون کنترل‌های زیرساختی مناسب می‌تواند خطرهای تازه‌ای برای در دسترس بودن سایت ایجاد کند.

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

امنیت باید بر کنترل‌های مکمل تکیه کند، نه بر یک ابزار دفاعی واحد.

اگر شرکت هاستینگ PHP را به‌روز نکرده باشد چه؟

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

در این وضعیت، شرکت هاستینگ بخش مهمی از واکنش است.

از هاستینگ بخواهید نسخه‌ی دقیق PHP، وضعیت وصله برای CVE-2026-109618 و CVE-2026-109619 و هر اقدام اضافه‌ای را که برای CVE-2026-115560 انجام داده تأیید کند.

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

برای سرویس‌های خیلی حساس یا در معرض، ممکن است لازم باشد دسترسی عمومی موقتاً محدود شود تا سیستم امن شود.

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

مسئولیت این است که شواهد رفع مشکل را به دست بیاورید.

PHP2Shell درباره‌ی امنیت سایت چه چیزی را نشان می‌دهد

ماجرای PHP2Shell ضعف بزرگ‌تری را در نگاه بسیاری از کسب‌وکارها به نگهداری سایت آشکار می‌کند.

امنیت اغلب مجموعه‌ای از کارهای قابل‌دیدن در نظر گرفته می‌شود: به‌روزرسانی افزونه‌ها، نصب گواهی SSL، فعال کردن فایروال یا مدیریت رمزهای عبور.

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

سایت یک کسب‌وکار معمولی به چند لایه‌ی به‌هم‌پیوسته وابسته است:

هر لایه وابستگی‌ها و خطرهای احتمالی خودش را دارد.

مشکل در یک لایه می‌تواند روی سیستم بالاتر اثر بگذارد، حتی وقتی اجزای لایه‌های بالاتر درست نگهداری شده‌اند.

PHP2Shell یادآوری می‌کند که امنیت سایت نیازمند شناخت کل لایه‌های فناوری است.

یک درس عملیاتی هم هست.

کسب‌وکارها باید بدانند چه کسی مسئول نگهداری هر لایه است، چه کسی اطلاعیه‌های امنیتی را دریافت می‌کند و تغییرات حیاتی با چه سرعتی قابل اعمال‌اند.

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

نتیجه لزوماً یک نفوذ فوری نیست.

نتیجه، در معرض خطر بودن طولانی و بی‌دلیل است.

سؤالات متداول

جمع‌بندی: امنیت بخشی از عملکرد دیجیتال است

PHP2Shell نشان می‌دهد چطور یک ضعف در عمق یک فناوری رایج وب می‌تواند برای هزاران کسب‌وکار بی‌ارتباط با هم خطر ایجاد کند.

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

افشای سوم نکته‌ی مهم دیگری را تأکید می‌کند: واکنش امنیتی یک فرایند مستمر است و اطلاعات تازه ممکن است حتی بعد از نصب وصله‌ی اولیه اقدام بیشتری لازم داشته باشد.

برای صاحبان کسب‌وکار، اولویت روشن است.

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

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

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

در آژانس مارکتینگ بیسان باور داریم عملکرد سایت، تجربه‌ی کاربری و پایداری فنی باید با هم دیده شوند.

منابع و مطالعه‌ی بیشتر

این مقاله بر پایه‌ی اطلاعیه‌های فنی و پژوهش‌های امنیتی عمومی تهیه شده و اطلاعات آن تا 26 اکتبر 2026 بررسی شده است.