چرا دولت‌ها برای مقابله با دو باگ خطرناک، سایت‌های خودشان را خاموش کردند؟

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

چهارشنبه ۲۱ اکتبر ۲۰۲۶، وب‌سایت مرکز ملی امنیت سایبری هلند از دسترس خارج شد و هم‌زمان، پرتال خدمات دولتی MijnOverheid و وب‌سایت مجلس نمایندگان هلند نیز خاموش شدند؛ اما مهاجمان، این وب‌سایت‌ها را از کار نینداخته بودند؛ خود مدیران تصمیم گرفتند دسترسی را قطع کنند.

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

دو آسیب‌پذیری با شناسه‌های CVE-2026-109618 و CVE-2026-109619 که با نام مشترک PHP2Shell شناخته می‌شوند، در معیار شدت آسیب‌پذیری امتیاز ۹٫۲ از ۱۰ گرفته‌اند؛ اما داستان PHP2Shell از اکتبر ۲۰۲۶ آغاز نشده بود. با ما همراه باشید تا ببینیم چطور خطایی در موتور یک زبان، به تعطیلی موقت خدمات دولتی در دست‌کم ۱۲ کشور منجر شد؛ از درگاه‌های شهروندی هلند و ۳۲ خدمت دولتی بریتانیا گرفته تا وب‌سایت ریاست‌جمهوری آفریقای جنوبی .

خاموشی چند سرویس دولتی در هلند فقط یکی از پیامدهای بحرانی بود که می‌توانست بخش بزرگی از وب را تحت‌تأثیر قرار دهد. بسیاری از وب‌سایت‌ها در پشت‌صحنه از زبان PHP استفاده می‌کنند؛ مثلاً وردپرس، دروپال، جوملا و مدیاویکی ، نرم‌افزاری که ویکی‌پدیا را اداره می‌کند، همگی با PHP ساخته شده‌اند. طبق آمار W3Techs در ۲۲ اکتبر ۲۰۲۶، حدود ۶۹٫۳ درصد از وب‌سایت‌هایی که زبان برنامه‌نویسی سمت سرورشان شناسایی شده بود، از PHP استفاده می‌کردند.

نزدیک به ۷۰ درصد از وب‌سایت‌هایی که زبان برنامه‌نویسی سمت سرورشان شناسایی شده، از PHP استفاده می‌کنند

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

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

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

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

وقتی در یک وب‌سایت، فُرمی را پُر می‌کنید و دکمه‌ی «ارسال» را می‌زنید، اطلاعات به‌طور مستقیم به کد برنامه نمی‌رسد. در وب‌سایت‌هایی که از PHP استفاده می‌کنند، موتور این زبان ابتدا درخواست را می‌خواند، داده‌ها را در حافظه مرتب می‌کند، سپس در اختیار برنامه قرار می‌دهد. همه‌چیز ساده و معمولی به‌نظر می‌رسد؛ اما یکی از خطرناک‌ترین مسیرهای حمله‌ی PHP2Shell دقیقاً در همین مرحله پنهان شده بود.

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

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

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

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

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

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

آشپز بعدی، به عدد بالای صفحه توجه می‌کند؛ درحالی‌که فقط ۱۰ سفارش واقعاً ثبت شده‌اند. وقتی به‌جای سفارش یازدهم می‌رسد، به‌جای اطلاعات یک سفارش معتبر، ممکن است با نوشته‌های قدیمی، خط‌خوردگی‌ها یا اطلاعات نامربوط مواجه شود. همین اشتباه فرصت حمله را فراهم می‌کرد. موتور هنگام پاک‌سازی به شمارنده اعتماد می‌کرد و محتوای خانه‌ی نیمه‌ساخته را مانند داده‌ای معتبر می‌خواند. پژوهشگران نشان دادند که مهاجم با طراحی دقیق درخواست و دست‌کاری چیدمان حافظه می‌تواند داده‌های خودش را در آن خانه‌ی نیمه‌ساخته بنشاند.

در آزمایش Datadog، همین زنجیره روی آپاچی با mod_php به اجرای یک دستور سیستم‌عامل رسید؛ PHP پیش از رسیدن به کدِ وب‌سایت و بدون ورود کاربر، دستور مهاجم را اجرا کرد؛ وضعیتی که در اصطلاح، اجرای کد از راه دور (RCE) نامیده می‌شود و در صورت موفقیت، می‌تواند زمینه‌ی سرقت اطلاعات، دست‌کاری سایت یا نصب بدافزار را فراهم کند.

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

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

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

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

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

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

نکته‌ی غیرمنتظره اینکه طبق آزمایش Wiz، این مسیر حتی وقتی که برنامه‌ی وب خودش، تابع session_start() را فراخوانی نکرده بود هم کار می‌کرد؛ زیرا پردازش مرتبط با پیشرفت بارگذاری فایل می‌توانست پیش از اجرای کد برنامه آغاز شود. Wiz خطر یادشده را با هارت‌بلید مقایسه می‌کند؛ آسیب‌پذیری مشهور سال ۲۰۱۴ که امکان خواندن بخش‌هایی از حافظه‌ی سرورها را فراهم کرده بود.

پژوهشگران Wiz در مجموع چهار مسیر قابل‌بهره‌برداری را زیر دو شناسه‌ی PHP2Shell گزارش کردند؛ استفاده پس از آزادسازی در پردازش اطلاعات بارگذاری فایل، نشت حافظه‌ی پروسه، استفاده پس از آزادسازی در اطلاعات خطاهای مرگبار و خطای «سردرگمی نوع» در OPcache، سازوکاری که PHP برای نگه‌داری کدِ از پیش کامپایل‌شده به‌کار می‌برد. شرکت هشدار داد که گونه‌های دیگری از همین الگو، تحت پیگیری یا بدون پیگیری، هنوز در کد PHP وجود دارند.

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

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

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

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

ریشه‌ی ماجرا به خطایی به‌ظاهر بی‌خطر در سال ۲۰۲۴ برمی‌گردد، وقتی بنیاد PHP با کمک مالی آژانس آلمانی Sovereign Tech Agency و از طریق سازمان OSTIF، ممیزی امنیتی خارجیِ کد زبان را به شرکت Quarkslab سپرد. هنگام رفع یکی از یافته‌های ممیزی، توسعه‌دهنده‌ای که با بنیاد همکاری می‌کرد رفتار نگران‌کننده‌ای را در زمان کمبود حافظه دید؛ همان قطع ناگهانی عملیات که پیش‌تر توضیح دادیم.

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

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

شاید تا همین‌جا هم متوجه تناقضی بزرگ شده باشید. PHP نرم‌افزاری متن‌باز است و هر پژوهشگری می‌تواند کدش را بخواند؛ اما نگهداریِ بخشی حساس از موتور، به دانش عمیق و وقتِ گروهی بسیار کوچک وابسته مانده بود. در سال ۲۰۲۴ هنوز معلوم نبود این خطا تا کجا پیش می‌رود. اوت ۲۰۲۶، پژوهشگران سرانجام نشان دادند که می‌توان از آن برای اجرای دستور روی سرور سوءاستفاده کرد.

کد آسیب‌پذیر سال‌ها در PHP وجود داشت و بعضی از نسخه‌های آسیب‌دیده حتی به PHP 5.4، منتشرشده در سال ۲۰۱۲، برمی‌گشتند. بعضی منابع، ریشه‌ی معماریِ این نقص‌ها را حتی به انتشار PHP 5 در سال ۲۰۰۴ می‌رسانند؛ چیزی که در سال ۲۰۲۶ تغییر کرد، نه خودِ خطا، بلکه توانایی تبدیل آن به یک حمله‌ی کارآمد و عملی بود.

ساختن چنین حمله‌ای به شناسایی و ترکیب چند خطا و آزمایش‌های متعدد نیاز داشت. به گفته‌ی شرکت امنیتی Wiz، مدل‌های پیشرفته‌ی هوش مصنوعی این فرایند دشوار را بسیار سریع‌تر کردند. شرکت از Wiz Atlas، Gemini 4 Argon و GPT-5.6 Sol استفاده کرد و توانست اکسپلویت‌های کارآمد را روی چند برنامه‌ی مختلف بسازد و تطبیق دهد. به روایت Wiz، یک پژوهشگر در یک هفته، کاری را انجام داد که پیش‌تر ماه‌ها از یک تیم درجه‌یک وقت می‌گرفت.

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

خط زمانی کشف هم شلوغ به نظر می‌رسید. بنیاد PHP در ماه مه ۲۰۲۶ تیم امنیت اکوسیستم را تشکیل داد و شرکت امنیتی Calif از ۳۰ ژوئیه‌ی ۲۰۲۶ بررسی PHP را در برنامه‌ی Patch the Planet آغاز کرد. روز ۱۱ اوت، پژوهشگری به‌نام Ryan A از این شرکت گزارش داد که توانسته از همان مشکل شناسایی‌شده در سال ۲۰۲۴ برای اجرای دستور روی سرور استفاده کند. OpenAI هم‌زمان و مستقل، همان ریشه را گزارش کرد. Wiz در ۲۴ اوت و OpenAI در ۱۸ سپتامبر مسیرهای دیگری برای سوءاستفاده شناسایی و گزارش کردند.

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

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

قرار بود اصلاحیه‌های PHP روز پنجشنبه ۲۲ اکتبر ۲۰۲۶ منتشر شوند؛ اما سه‌شنبه ۲۰ اکتبر، حدود ساعت ۱۵ به‌وقت جهانی، شناسه‌های دو آسیب‌پذیری در انجمن‌ها و شبکه‌های اجتماعی پخش شدند. اطلاعات منتشرشده حتی چند اشتباه داشتند؛ از جمله امتیاز خطر ۱۰ از ۱۰ درحالی‌که امتیاز واقعی ۹٫۲ بود. به گفته‌ی بنیاد PHP در آن مرحله هنوز جزئیات فنی حمله فاش نشده بود؛ اما برنامه‌ی انتشار هماهنگ اصلاحیه‌ها به‌هم ریخت.

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

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

صبح چهارشنبه نیز شرکت Chainguard ایمیج‌های حاوی وصله را پیش‌از موعد هماهنگ‌شده در دسترس گذاشت. بنیاد PHP به این تصمیم اعتراض کرد؛ زیرا مهاجم می‌توانست تغییرات نسخه‌ی اصلاح‌شده را بررسی و آسیب‌پذیری را بازسازی کند؛ درحالی‌که بسیاری از مدیران هنوز منتظر بسته‌ی رسمی بودند.

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

گزارش بعدی خط زمانی تهدید را حتی عقب‌تر برد. آمازون در داده‌های شبکه‌ی تله‌ی امنیتی خود ، تلاش مشکوکی برای سوءاستفاده از PHP2Shell پیدا کرد که به ۱۷ اکتبر برمی‌گشت؛ چهار روز پیش از افشای عمومی آسیب‌پذیری‌ها. هنوز معلوم نیست عامل این تلاش چگونه به اطلاعات لازم رسیده بود؛ اما نشان می‌داد فعالیت‌های مشکوک حتی پیش‌از انتشار رسمی خبر آغاز شده‌اند.

چهار نسخه‌ی اصلاح‌شده‌ی PHP، یعنی ۸.۵.۱۲، ۸.۴.۲۷، ۸.۳.۳۶ و ۸.۲.۳۵، چهارشنبه ۲۱ اکتبر منتشر شدند. برای نسخه‌های قدیمی‌تر هم تغییراتی در کد منبع ارائه شد؛ اما این نسخه‌ها دیگر پشتیبانی عادی ندارند و نصب نسخه‌ی قدیمیِ اصلاح‌شده به بسته‌ی معتبر توزیع‌کننده یا کار اضافه‌ی مدیر سرور بستگی دارد.

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

مهاجمان پس‌از انتشار وصله نیز به حمله‌ها ادامه دادند؛ برای مثال کلادفلر ترافیکی را مشاهده کرد که برای حمله به مشتریانش طراحی شده بود و گزارش داد مهاجمان شکل داده‌های ارسالی را برای عبور از حفاظ‌ها تغییر می‌دادند. آمار کلادفلر نشان می‌دهد تلاش برای سوءاستفاده از PHP2Shell با چه سرعتی افزایش یافت. به‌گفته‌ی متیو پرینس، مدیرعامل این شرکت، در ۱۰ ساعت پیش‌از اعلام عمومی رسمی آسیب‌پذیری‌ها، هزاران تلاش برای حمله در شبکه‌ی کلادفلر ثبت شد.

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

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

گزارش شرکت‌های دیگر نیز از گسترش سریع حمله‌ها حکایت داشت. Wordfence تا ۲۲ اکتبر بیش‌از ۷۴هزار تلاش برای حمله، وارسی آسیب‌پذیری و فعالیت‌های مرتبط را مسدود کرده بود؛ البته این آمارها به‌معنای نفوذ موفق نیستند و شرکت‌های امنیتی تعداد درخواست‌های مشکوک مشاهده‌شده در شبکه‌های خود را گزارش کرده‌اند.

۲۳ اکتبر، تیم PHP از آسیب‌پذیری مرتبط دیگری با شناسه‌ی CVE-2026-115560 خبر داد که اصلاحیه‌های ۲۱ اکتبر آن را پوشش نمی‌دادند. توسعه‌دهندگان احتمال سوءاستفاده‌ی عملی از آن را پایین ارزیابی کردند و اعلام کردند اصلاحیه‌اش را در انتشار بعدی ارائه خواهند کرد.

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

کاربران وردپرس برای بررسی نسخه‌ی نصب‌شده، می‌توانند به مسیر «ابزارها ← سلامت سایت ← اطلاعات ← سرور» مراجعه کنند.

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

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

تیم PHP به‌طور مشخص توصیه می‌کند تنظیم session.upload_progress.enabled غیرفعال شود و پردازش‌های PHP دوباره راه‌اندازی شوند. این توصیه را پس‌از انتشار اصلاحیه‌ها نیز جدی بگیرید؛ زیرا تیم PHP روز ۲۳ اکتبر از مسیر احتمالی دیگری برای اجرای کد مخرب در شرایطی خاص خبر داد که قرار است در به‌روزرسانی بعدی اصلاح شود.

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

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

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