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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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