روز ۲۱ اکتبر ۲۰۲۶، شماری از وب‌سایت‌های دولتی، بیمارستان‌ها، شرکت‌ها و خدمات عمومی در کشورهای مختلف موقتاً از دسترس خارج شدند. در آلمان، فرانسه، هلند و چند کشور دیگر، مسئولان برخی سامانه‌ها ترجیح دادند خدمات اینترنتی خود را متوقف کنند تا فرصت نصب اصلاحیه‌های امنیتی را داشته باشند.
این اختلال‌ها عمدتاً حاصل یک اقدام پیشگیرانه بودند، نه حمله‌ای که به‌طور هم‌زمان همهٔ این وب‌سایت‌ها را از کار انداخته باشد. اما تصمیم به توقف خدمات، نشان‌دهندهٔ جدیت خطری بود که سازمان‌های امنیت سایبری دربارهٔ آن هشدار داده بودند.
منشأ این نگرانی، کشف دو آسیب‌پذیری خطرناک در هستهٔ PHP بود؛ زبان برنامه‌نویسی پرکاربردی که بخش بزرگی از اینترنت بر آن متکی است.
این دو آسیب‌پذیری با شناسه‌های CVE-2026-109618 و CVE-2026-109619 و امتیاز شدت ۹٫۲ از ۱۰ ثبت شدند. در شرایط مشخص، مهاجم می‌توانست بدون احراز هویت، کد دلخواه خود را از راه دور روی سرور آسیب‌پذیر اجرا کند.
اما موضوعی که این حادثه را از یک هشدار امنیتی معمولی متمایز می‌کند، نقش هوش مصنوعی در بررسی و اثبات امکان بهره‌برداری از ضعف‌هایی است که ریشهٔ آن‌ها به سال‌ها قبل بازمی‌گردد.
در روزهای پس از انتشار اصلاحیه‌ها، اتفاقات تازه‌ای نیز رخ داد. تلاش‌های واقعی برای بهره‌برداری از این آسیب‌پذیری‌ها شناسایی شد، پژوهشگران شواهد اجرای موفق فرمان را در سامانه‌های آزمایشی ثبت کردند و سرانجام آژانس امنیت سایبری آمریکا تأیید کرد که این ضعف‌ها مورد سوءاستفاده قرار گرفته‌اند.
این رویداد اکنون با نام PHP2Shell شناخته می‌شود و می‌تواند نمونه‌ای مهم از تغییر شرایط امنیت نرم‌افزار در عصر هوش مصنوعی باشد.
حفره‌ای در قلب بخش بزرگی از اینترنت
PHP یکی از مهم‌ترین زبان‌های برنامه‌نویسی سمت سرور است و سامانه‌هایی مانند وردپرس، جوملا، دروپال و مدیاویکی از آن استفاده می‌کنند.
براساس آمار W3Techs در ۲۸ اکتبر ۲۰۲۶، حدود ۶۹٫۲ درصد وب‌سایت‌هایی که زبان سمت سرور آن‌ها قابل‌شناسایی است، از PHP استفاده می‌کنند.² البته این آمار به معنای آسیب‌پذیر بودن تمام این وب‌سایت‌ها نیست. خطر واقعی به نسخهٔPHP ، پیکربندی سرور و شرایط اجرای برنامه بستگی دارد.
نکتهٔ مهم‌تر آن است که آسیب‌پذیری‌های تازه در هستهٔ PHP قرار داشتند، نه لزوماً در کد برنامه‌هایی که با آن نوشته شده‌اند.
برای درک اهمیت این تفاوت، باید بدانیم که یک برنامهٔ تحت وب معمولاً پیش از اجرای منطق اختصاصی خود، به موتور PHP متکی است. وقتی نقص در همین موتور وجود داشته باشد، حتی یک برنامهٔ ساده نیز ممکن است در شرایط مناسب در معرض تهدید قرار گیرد.
یکی از آسیب‌پذیری‌ها به مدیریت حافظه هنگام بروز خطای کمبود حافظه مربوط می‌شد. در وضعیت‌های خاص، درخواست در حال پردازش می‌توانست باعث شود داده‌های داخلی به‌طور ناقص مقداردهی شوند و سپس بخش‌های دیگری از برنامه آن‌ها را معتبر فرض کنند.
آسیب‌پذیری دوم به باقی ماندن وضعیت داخلی مربوط به یک درخواست پیشین ارتباط داشت؛ اطلاعاتی که پس از آزاد شدن حافظه، ممکن بود دوباره مورد استفاده قرار گیرند.
پیامد چنین خطاهایی می‌توانست افشای داده‌های حساس حافظه یا اجرای کد از راه دور باشد.
اما این مشکلات در اکتبر ۲۰۲۶ به وجود نیامده بودند.
مشکلی که در سال ۲۰۲۴ دیده شد، اما حل نشد
یکی از مهم‌ترین بخش‌های این ماجرا در گزارش رسمی بنیاد PHP آمده است.
در سال ۲۰۲۴، هنگام رسیدگی به نتایج یک ممیزی امنیتی، یکی از توسعه‌دهندگان هستهٔ PHP نشانه‌های مشکل مدیریت حافظه را شناسایی کرده بود. حتی احتمال بهره‌برداری امنیتی از آن مطرح شد، اما در آن زمان مسیر مشخصی برای تبدیل این ضعف به یک حملهٔ عملی پیدا نشد.
از سوی دیگر، اصلاح مشکل دشوار بود. راه‌حل‌های مختلف ممکن بود سازگاری PHP با برنامه‌های قدیمی را مختل کنند، خطرهای تازه ایجاد کنند یا به تغییر بسیاری از افزونه‌های جانبی نیاز داشته باشند.
تیم امنیتی PHP باید میان چند گزینهٔ پرهزینه تصمیم می‌گرفت. محدودیت نیروی انسانی متخصص و شیوهٔ تصمیم‌گیری مبتنی بر توافق عمومی نیز فرایند را کند کرده بود. در نتیجه، رفع مشکل بارها به تأخیر افتاد.
بنیاد PHP بعدها صریحاً پذیرفت که این تأخیر ناشی از یک شکست ساختاری در فرایند تصمیم‌گیری و کمبود منابع بوده است.
این اعتراف از نظر مدیریتی اهمیت زیادی دارد. مسئله فقط این نبود که برنامه‌نویسان نتوانسته بودند نقصی را پیدا کنند؛ آن‌ها نشانه‌های مشکل را دیده بودند، اما هنوز شواهد کافی برای تعیین فوریت آن و ظرفیت سازمانی لازم برای اصلاح سریعش وجود نداشت.
چیزی که در سال ۲۰۲۶ تغییر کرد، توانایی نشان دادن پیامد عملی این نقص بود.
هوش مصنوعی چگونه وارد ماجرا شد؟
در تابستان ۲۰۲۶، چند گروه پژوهشی مستقل بررسی امنیتی PHP را آغاز کردند. در ماه اوت، پژوهشگران شرکت Calif در چارچوب برنامهٔ Patch the Planet و با استفاده از GPT-5.6 Sol توانستند امکان اجرای کد از راه دور را در ارتباط با مشکل مدیریت حافظه نشان دهند .OpenAI نیز به‌طور مستقل همان علت ریشه‌ای را گزارش کرد.
در همان دوره، پژوهشگران شرکت Wiz با استفاده از ابزارهایی از جملهWiz Atlas ، Gemini 4 Argon و GPT-5.6 Solآسیب‌پذیری‌ها و روش‌های بهره‌برداری از آن‌ها را بررسی کردند.
به گفتهٔWiz ، مدل‌های هوش مصنوعی در پیدا کردن ضعف‌ها، توسعهٔ روش‌های آزمایش، تحلیل شکست‌ها و تطبیق آزمایش‌ها با نسخه‌ها و محیط‌های مختلف PHP نقش مهمی داشتند. این شرکت توانست اجرای کد از راه دور را در محیط‌های آزمایشی مبتنی بر وردپرس، دروپال و جوملا نشان دهد.
البته نباید این دستاورد را به معنای آن دانست که هوش مصنوعی به‌تنهایی و بدون دخالت متخصصان انسانی، تمام فرایند کشف و بهره‌برداری را انجام داده است.
پژوهشگران انسانی، ابزارهای امنیتی، محیط‌های آزمایش و دانش تخصصی همچنان بخش جدایی‌ناپذیر این فرایند بودند. اما هوش مصنوعی توانست در بخش‌هایی از کار که به تحلیل پیچیدهٔ کد، آزمودن فرضیه‌های متعدد و اصلاح مکرر روش‌های آزمایش نیاز داشت، به پژوهشگران کمک کند.
اهمیت واقعی این اتفاق همین‌جاست. وقتی یک آسیب‌پذیری نظری به تهدید عملی تبدیل می‌شود در امنیت نرم‌افزار، وجود یک نقص الزاماً به معنای آسان بودن بهره‌برداری از آن نیست. بعضی آسیب‌پذیری‌ها از جنبه نظری خطرناک‌اند، اما تبدیل آن‌ها به حمله‌ای قابل‌اجرا به دانش تخصصی بسیار بالا، آزمایش‌های طولانی و شناخت عمیق از ساختار نرم‌افزار نیاز دارد.
به همین دلیل، پیچیدگی بهره‌برداری در عمل می‌تواند مانعی در برابر مهاجمان باشد؛ هرچند هیچ‌گاه تضمین‌کننده امنیت نیست.
هوش مصنوعی ممکن است این مانع را تا حدی کاهش دهد. مدل‌های پیشرفته می‌توانند در تحلیل کدهای پیچیده، توضیح رفتارهای غیرمنتظره، بررسی خروجی آزمایش‌ها و پیشنهاد مسیرهای تازهٔ بررسی کمک کنند.
به این ترتیب، فعالیتی که پیش‌تر مستلزم صرف زمان طولانی و استفاده از متخصصان بسیار باتجربه بود، ممکن است با منابع کمتر انجام شود.
این تغییر را می‌توان نوعی دگرگونی در اقتصاد بهره‌برداری از آسیب‌پذیری‌ها دانست. تا پیش از این، هزینهٔ فنی و زمانی بهره‌برداری از برخی ضعف‌ها چنان بالا بود که تنها گروه‌های محدودی توانایی انجام آن را داشتند. اکنون ابزارهای هوش مصنوعی می‌توانند بخشی از این هزینه را کاهش دهند و امکان تکرار و تطبیق آزمایش‌ها را افزایش دهند.
البته این مزیت فقط در اختیار مهاجمان نیست. همان‌طور که ماجرای PHP نشان داد، پژوهشگران مدافع نیز با کمک هوش مصنوعی می‌توانند ضعف‌هایی را کشف و بررسی کنند که سال‌ها از دید پنهان مانده‌اند یا بهره‌برداری از آن‌ها دشوار بوده است.
بنابراین مسئله، ذاتاً مخرب بودن هوش مصنوعی نیست؛ مسئله آن است که قابلیت‌های تازهٔ آن می‌توانند هم قدرت دفاع و هم قدرت حمله را افزایش دهند و اینجاست که پرسش مهم‌تری مطرح می‌شود: آیا ظرفیت دفاع سازمان‌ها هم‌پای افزایش سرعت کشف و بهره‌برداری رشد خواهد کرد؟
از هشدار امنیتی تا حملات عملی
تحولات چند روز پس از انتشار خبر PHP2Shell نشان داد که خطر صرفاً در حد یک احتمال نظری باقی نمانده است. شرکت آمازون اعلام کرد که در داده‌های شبکهٔ امنیتی MadPot تلاشی برای بهره‌برداری از این آسیب‌پذیری‌ها را در ۱۷ اکتبر شناسایی کرده است؛ یعنی چهار روز پیش از افشای عمومی آن‌ها.
این فعالیت از طریق زیرساختی مرتبط با یک شبکهٔ ناشناس‌ساز انجام شده بود. آمازون تأکید کرد که مشخص نیست عامل حمله چگونه پیش از افشای رسمی به اطلاعات لازم دست یافته و آیا تلاش او در سامانه‌های واقعی موفق بوده است یا نه.
در روزهای بعد نیز آزمایش‌ها و تلاش‌های بیشتری شناسایی شدند. در ۲۴ اکتبر، پژوهشگری دیگری شواهدی از اجرای موفق فرمان در سه سرور آزمایشیِ عمداً آسیب‌پذیر ثبت کرد. براساس گزارش منتشرشده، ۳۵ مورد اجرای شل در این محیط‌ها مشاهده شد.
البته این نتایج در یک پیکربندی مشخص Apache و PHP به دست آمدند و نمی‌توان آن‌ها را به تمام سامانه‌های اینترنتی تعمیم داد. این شواهد، اجرای عملی فرمان در محیط‌های تحت نظارت را نشان می‌دهند، نه تعداد وب‌سایت‌های واقعی که مورد نفوذ قرار گرفته‌اند.
دو روز بعد، در ۲۶ اکتبر، آژانس امنیت سایبری و امنیت زیرساخت آمریکا، CISA، هر دو آسیب‌پذیری را به فهرست Known Exploited Vulnerabilities یا آسیب‌پذیری‌های دارای شواهد بهره‌برداری واقعی اضافه کرد. این تحول اهمیت زیادی دارد. زیرا نشان می‌دهد نگرانی‌های اولیه دربارهٔ امکان تبدیل ضعف‌های PHP به حملات عملی، دیگر صرفاً بر آزمایش‌های کنترل‌شدهٔ پژوهشگران متکی نیست. با این حال، تا زمان تنظیم این مقاله، اطلاعات عمومی کافی برای تعیین تعداد سازمان‌های واقعاً آسیب‌دیده یا میزان خسارت احتمالی وجود ندارد.
از سوی دیگر، هنوز شواهد عمومی معتبری وجود ندارد که نشان دهد مهاجمان مشاهده‌شده در این حملات الزاماً از هوش مصنوعی استفاده کرده‌اند. نقش هوش مصنوعی در پژوهش‌های امنیتی مستند است؛ اما تعمیم آن به روش کار تمام مهاجمان، نیازمند شواهد مستقل خواهد بود.
چرا اصلاح یک ضعف از کشف آن دشوارتر است؟
در ماجرای PHP2Shell، میان دو فرایند تفاوت مهمی وجود داشت: کشف و اثبات آسیب‌پذیری از یک سو، و اصلاح و انتشار امن وصله‌ها از سوی دیگر.
برای ساخت یک روش بهره‌برداری، پژوهشگر می‌تواند فرضیه‌های مختلف را در محیط آزمایشی بررسی کند. اما توسعه‌دهنده‌ای که قرار است نقص هستهٔ PHP را اصلاح کند، باید مطمئن شود راه‌حل انتخاب‌شده، میلیون‌ها برنامه و افزونهٔ وابسته را دچار مشکل نمی‌کند.
هر تغییر در یک نرم‌افزار زیربنایی ممکن است پیامدهایی فراتر از همان بخشی داشته باشد که اصلاح شده است.
علاوه بر این، پس از آماده شدن اصلاحیه، شرکت‌های ارائه‌دهندهٔ سیستم‌عامل، سرویس‌های میزبانی، خدمات ابری و سازمان‌های استفاده‌کننده باید آن را آزمایش و نصب کنند.
در مقابل، مهاجم لزوماً به چنین هماهنگی گسترده‌ای نیاز ندارد. او می‌تواند روی یک هدف مشخص تمرکز کند و در صورت شکست، روش خود را تغییر دهد. در نتیجه ممکن است سرعت توسعهٔ روش‌های بهره‌برداری از ظرفیت سازمان‌ها برای اصلاح و استقرار به‌روزرسانی‌ها پیشی بگیرد.
گزارش جدید Wiz در ۲۷ اکتبر تصویری از هر دو سوی این رقابت ارائه می‌دهد. این شرکت اعلام کرد شمار روزانهٔ ماشین‌های در معرض اینترنت که در داده‌های خودش آسیب‌پذیر تشخیص داده می‌شدند، طی چند روز حدود ۶۷ درصد کاهش یافته است. همچنین تعداد سازمان‌هایی که دست‌کم یک نمونهٔ آسیب‌پذیرِ در دسترس داشتند، در داده‌های رصدشده حدود ۴۸ درصد کاهش پیدا کرده بود. این آمار نشانه‌ای امیدوارکننده از واکنش سریع مدافعان است؛ اما به معنای ایمن شدن همهٔ سامانه‌های اینترنتی نیست. همچنان سرورهای آسیب‌پذیر وجود دارند و سامانه‌هایی که بر نسخه‌های قدیمی و بدون پشتیبانی PHP متکی هستند، با دشواری بیشتری برای رفع خطر مواجه‌اند.
یک مشکل دیگر؛ سیل گزارش‌های امنیتی
بنیاد PHP در گزارش رسمی خود به مسئلهٔ دیگری هم اشاره کرده است.
ابزارهای مبتنی بر هوش مصنوعی تعداد گزارش‌های امنیتی را افزایش داده‌اند، اما همهٔ این گزارش‌ها معتبر نیستند. از ابتدای ژوئیهٔ ۲۰۲۶، تیم امنیتی PHP علاوه بر انتشار ۱۵ شناسهٔ آسیب‌پذیری، بیش از صد گزارش نامعتبر، تکراری یا غیرقابل‌بازتولید را نیز بررسی کرده بود.
این موضوع یک تناقض عملی ایجاد می‌کند. از یک طرف، توانایی بیشتر برای شناسایی مشکلات می‌تواند امنیت نرم‌افزار را بهبود دهد. از طرف دیگر، اگر حجم گزارش‌ها سریع‌تر از ظرفیت بررسی آن‌ها افزایش یابد، تیم‌های امنیتی با فشار تازه‌ای روبه‌رو می‌شوند.
تفاوت میان یک گزارش واقعی و یک هشدار اشتباه، نیازمند دانش تخصصی، آزمایش و قضاوت انسانی است.
هوش مصنوعی می‌تواند در این فرایند هم کمک کند، اما تصمیم دربارهٔ پذیرش یک گزارش، انتخاب اصلاحیه و ارزیابی پیامدهای تغییر همچنان بر عهدهٔ مسئولان نرم‌افزار است.
بنابراین پیشرفت ابزارهای کشف امنیتی، ضرورت تقویت تیم‌های انسانی و فرایندهای سازمانی را از میان نمی‌برد؛ بلکه ممکن است آن را بیشتر کند.
آیا خطر برطرف شده است؟
توسعه‌دهندگان PHP در ۲۱ اکتبر چهار نسخهٔ اصلاح‌شدهٔ 8.2.35، 8.3.36، 8.4.27 و 8.5.12 را منتشر کردند.
این نسخه‌ها دو آسیب‌پذیری اصلی PHP2Shell را برطرف می‌کنند. سازمان‌هایی که هنوز از نسخه‌های آسیب‌پذیر استفاده می‌کنند، باید اصلاحیه‌های مناسب را دریافت و نصب کنند. استفاده از فایروال برنامه‌های تحت وب می‌تواند در کاهش خطر برخی روش‌های حمله مؤثر باشد، اما جایگزین اصلاح کامل مشکل نیست.
در ۲۳ اکتبر، آسیب‌پذیری دیگری با شناسهٔ CVE-2026-115560 نیز اعلام شد. این مشکل تنها در ترکیب غیرمعمولی از تنظیمات و رفتار برنامه امکان بهره‌برداری دارد و اصلاحیه‌های ۲۱ اکتبر آن را پوشش نمی‌دهند. تیم PHP برای این مورد راهکار موقت پیکربندی ارائه کرده و انتشار اصلاحیهٔ کامل را به چرخهٔ عادی بعدی موکول کرده است.
لازم به یادآوری است که اصلاح یک مجموعه از آسیب‌پذیری‌ها الزاماً به معنای پایان تمام خطرهای مرتبط نیست.
برای مدیران سامانه‌ها، درس عملی روشن است: شناسایی نسخه‌های PHP مورد استفاده، بررسی وابستگی نرم‌افزارها، نصب اصلاحیه‌های معتبر و ارزیابی نشانه‌های فعالیت مشکوک باید در اولویت قرار گیرد.
امنیت در عصر هوش مصنوعی؛ مسئله فقط کشف حفره‌ها نیست
ماجرای PHP2Shell چند واقعیت مهم را هم‌زمان آشکار کرد. نخست این‌که بعضی ضعف‌های نرم‌افزاری ممکن است سال‌ها در زیرساخت‌های پرکاربرد باقی بمانند، زیرا کشف مسیر عملی بهره‌برداری از آن‌ها بسیار دشوار است.
دوم این‌که هوش مصنوعی می‌تواند با کمک به تحلیل کد و آزمایش فرضیه‌ها، بخشی از این دشواری را کاهش دهد.
سوم این‌که سرعت بیشتر کشف و بهره‌برداری، لزوماً با افزایش مشابهی در سرعت اصلاح و انتشار به‌روزرسانی‌ها همراه نیست.
و سرانجام، امنیت نرم‌افزار فقط به کیفیت کد وابسته نیست؛ به منابع انسانی، ساختار تصمیم‌گیری، هماهنگی میان شرکت‌ها و سرعت واکنش سازمان‌ها نیز بستگی دارد.
در این میان، یک برداشت اشتباه می‌تواند خطرناک باشد: این‌که چون هوش مصنوعی به کشف حفره‌ها کمک می‌کند، پس خودِ هوش مصنوعی عامل اصلی ناامنی اینترنت شده است.
واقعیت پیچیده‌تر است. همین فناوری که به پژوهشگران امکان می‌دهد ضعف‌های قدیمی را به تهدیدهای قابل‌آزمایش تبدیل کنند، می‌تواند به مدافعان نیز کمک کند تا آن ضعف‌ها را پیش از وقوع حملات گسترده‌تر شناسایی و اصلاح کنند. مسئلهٔ تعیین‌کننده این است که کدام طرف می‌تواند از این توانایی بهتر و سریع‌تر استفاده کند و آیا سازمان‌ها برای مواجهه با سرعت تازهٔ تحولات آماده‌اند یا نه.
شاید مهم‌ترین درس PHP2Shell این باشد: در عصر هوش مصنوعی، پیچیدگی یک آسیب‌پذیری دیگر لزوماً همان مانع عملی گذشته نیست؛ اما امنیت واقعی همچنان به توانایی انسان‌ها و سازمان‌ها در شناسایی، تصمیم‌گیری و اصلاح به‌موقع وابسته است.
نظر شما چیست؟