اوپن‌ای‌آی می‌گوید مدل GPT-5.6 Sol در کشف آسیب‌پذیری‌های PHP2Shell نقش داشته است؛ هوش مصنوعی چه تغییری در امنیت متن‌باز ایجاد می‌کند؟
نویسنده: لس-لی ای | ۲۳ اکتبر ۲۰۲۶
حالا ربات‌ها هستند که آسیب‌پذیری‌های نرم‌افزاری را پیدا می‌کنند، اما همچنان باید کسی آن‌ها را برطرف کند؛ مسئولیتی که اغلب بر دوش گروه کوچکی از توسعه‌دهندگان داوطلب قرار می‌گیرد.
نمونه روشنی از این وضعیت همین هفته با انتشار جزئیات PHP2Shell مطرح شد؛ دو آسیب‌پذیری امنیتی شدید در زبان برنامه‌نویسی سمت سرور PHP که بخش بزرگی از وب به آن وابسته است. هر دو نقص اکنون در نسخه‌های پشتیبانی‌شده برطرف شده‌اند. بااین‌حال، اوپن‌ای‌آی می‌گوید مدل GPT-5.6 Sol این شرکت آن‌ها را شناسایی کرده و پیش‌بینی می‌کند که در آینده نزدیک، تعداد کشفیات مشابه «به‌شدت افزایش یابد».
به زبان ساده، PHP2Shell شامل دو آسیب‌پذیری با شناسه‌های CVE-2026-109618 و CVE-2026-109619 است که به بخش‌های مدیریت حافظه و رسیدگی به خطا در PHP مربوط می‌شوند؛ بخش‌هایی که هنگام پردازش درخواست‌های معمول وب به کار می‌روند. به گفته بنیاد PHP، مهاجمی که احراز هویت نشده است، در شرایط خاص می‌تواند محتوای حافظه را دست‌کاری کند یا از بخش‌هایی از آن دوباره استفاده کند و در نهایت کد دلخواه خود را روی سرور اجرا کند. این بنیاد می‌گوید امکان چنین حمله‌ای روی وب‌سرور آپاچی با تنظیمات پیش‌فرض نیز به‌صورت عملی نشان داده شده است.
ممکن است تصور شود کشف این آسیب‌پذیری‌ها صرفاً دستاورد اوپن‌ای‌آی بوده است، اما گروه‌های دیگری نیز نقش مهمی در این فرایند داشته‌اند. شرکت‌های Calif.io، ویز (Wiz)، اوپن‌ای‌آی و Quarkslab همگی در فرایند افشای آسیب‌پذیری‌ها مشارکت کردند. بنیاد PHP همچنین از OSTIF، تیم امنیتی خود و توسعه‌دهندگان داوطلب قدردانی کرده است.
اوپن‌ای‌آی این ماجرا را نشانه‌ای از توانایی مدل‌های پیشرفته هوش مصنوعی در شناسایی حفره‌های امنیتی پیش از سوءاستفاده هکرها معرفی می‌کند. بااین‌حال، روایت توسعه‌دهندگان PHP نشان می‌دهد واقعیت پیچیده‌تر از این تصویر است.
ماه‌ها تلاش تا انتشار اصلاحیه‌های امنیتی
کشف این آسیب‌پذیری‌ها مدت‌ها پیش از اعلام عمومی آن‌ها اتفاق افتاده بود.
طبق اعلام بنیاد PHP، شرکت Calif نخستین گزارش خود را ۱۱ اوت ارسال کرد. شرکت Wiz نیز در ۲۴ اوت مشکلاتی را گزارش داد که با یافته‌های قبلی هم‌پوشانی داشتند. سپس اوپن‌ای‌آی در ۱۸ سپتامبر، به‌طور مستقل دقیقاً همان علت ریشه‌ای آسیب‌پذیری‌ها را گزارش کرد. با وجود این، اصلاحیه‌ها تا ۲۱ اکتبر منتشر نشدند و سرانجام در نسخه‌های 8.5.12، 8.4.27، 8.3.36 و 8.2.35 زبان PHP در دسترس قرار گرفتند.
انتشار این اصلاحیه‌ها یک روز زودتر از برنامه اولیه انجام شد. بنیاد PHP می‌گوید حدود ساعت ۱۵ به وقت هماهنگ جهانی در ۲۰ اکتبر، شناسه‌های CVE در انجمن‌های اینترنتی و شبکه‌های اجتماعی فاش شدند. همراه این اطلاعات، زمان نادرستی برای انتشار اصلاحیه‌ها و امتیاز اشتباه ۱۰ از ۱۰ در سامانه ارزیابی شدت آسیب‌پذیری CVSS منتشر شده بود؛ درحالی‌که امتیاز واقعی ۹٫۲ بود. این اتفاق بنیاد را مجبور کرد برنامه انتشار را به‌صورت اضطراری تغییر دهد.
اشتباهات دیگری نیز در این فرایند رخ داد. به گفته بنیاد PHP، شرکت Calif به‌اشتباه ویدئویی را منتشر کرد که روش عملی بهره‌برداری از آسیب‌پذیری را نشان می‌داد و بعداً آن را حذف کرد. شرکت Chainguard نیز نسخه‌های اصلاح‌شده ایمیج‌های کانتینری را بیش از شش ساعت پیش از زمان هماهنگ‌شده منتشر کرد.
تیم اطلاعات تهدید آمازون وب سرویسز نیز می‌گوید داده‌های ثبت‌شده در سامانه‌های تله امنیتی یا هانی‌پات این شرکت، تلاشی برای بهره‌برداری از آسیب‌پذیری را در تاریخ ۱۷ اکتبر نشان می‌دهند؛ یعنی چهار روز پیش از افشای عمومی. البته این ادعا بر اساس داده‌ها و تحلیل خود AWS مطرح شده است.
وقتی گزارش‌های آسیب‌پذیری انباشته می‌شوند، چه کسی هزینه را می‌پردازد؟
بنیاد PHP می‌گوید پژوهش‌های امنیتی با کمک هوش مصنوعی از همین حالا تعداد گزارش‌های دریافتی را افزایش داده‌اند. از اول ژوئیه تاکنون، تیم امنیتی این بنیاد ۱۵ شناسه CVE منتشر کرده و بیش از ۱۰۰ گزارش نامعتبر، تکراری یا غیرقابل‌بازتولید را بررسی کرده است. به گفته بنیاد، هوش مصنوعی در اعتبارسنجی گزارش‌ها و دسته‌بندی مواردی که علت ریشه‌ای مشترک دارند کمک می‌کند، اما تصمیم‌گیری نهایی درباره هر گزارش و کار روی هر اصلاحیه همچنان بر عهده انسان است.
بنیاد PHP اضافه می‌کند که رفع آسیب‌پذیری‌های PHP2Shell از ۱۱ اوت به مهم‌ترین اولویت تیم امنیتی تبدیل شد. بدون حمایت مالی بنیاد، امکان اختصاص نیرو به‌صورت تمام‌وقت و کار در تعطیلات آخر هفته وجود نداشت. خود فرایند اصلاح نیز بسیار پیچیده بود، زیرا بخش‌هایی از کد مدیریت حافظه و رسیدگی به خطا را در بر می‌گرفت که تقریباً در هر درخواست وب اجرا می‌شوند. تیم توسعه ناچار بود هم‌زمان سازگاری با نسخه‌های قبلی، خطر حملات منع سرویس و عملکرد افزونه‌های شخص ثالث را در نظر بگیرد.
گزارش‌ها حاکی از آن است که اصلاحیه‌ها فقط نسخه‌های PHP 8.2 و جدیدتر را پوشش می‌دهند. به گفته شرکت PwC، این یعنی نسخه‌های PHP 8.1 و قدیمی‌تر اصلاحیه مستقیمی از توسعه‌دهندگان اصلی دریافت نمی‌کنند و کاربران آن‌ها برای دسترسی به اصلاحیه‌های احتمالی باید به توزیع‌های لینوکس یا شرکت‌های ارائه‌دهنده پشتیبانی بلندمدت متکی باشند.
اگر آمار گزارش‌های بنیاد PHP نشانه‌ای از وضعیت کلی باشد، حجم کاری تیم‌هایی که گزارش‌های آسیب‌پذیری را دریافت می‌کنند از همین حالا رو به افزایش است. به همین دلیل از کارشناسان پرسیدیم: کشف آسیب‌پذیری‌ها به کمک هوش مصنوعی چه تأثیری بر حجم کار، هزینه‌ها و فرایند افشای امنیتی برای نگهدارندگان پروژه‌های متن‌باز می‌گذارد؟
کارشناسان ما
- مودیتا خورانا، مهندس ارشد امنیت در Airbnb
- مغیث احمد، بنیان‌گذار DistroCode
- رودیون سوروکین، هم‌بنیان‌گذار و مدیر ارشد فناوری The Capital Index
- رومن مارتیننکو، مهندس بنیان‌گذار فول‌استک در Henry AI
- راجش‌کومار راجاسکاران نایر، متخصص آزمون در شرکت IBM
- تی. جی. مارلین، بنیان‌گذار و مدیرعامل Guardrail Technologies
- کادان اشتادلمن، بنیان‌گذار و مدیر ارشد فناوری سابق Komodo Platform
- مندی آندرس، مدیر ارشد امنیت اطلاعات در Elastic
مودیتا خورانا، مهندس ارشد امنیت در Airbnb
«شناسایی آسیب‌پذیری‌ها با کمک هوش مصنوعی می‌تواند هزینه پیدا کردن نقص‌های پیچیده را کاهش دهد، اما بخش بزرگی از این هزینه را به نگهدارندگان پروژه‌های متن‌باز منتقل می‌کند. بنیاد PHP می‌گوید از ماه ژوئیه بیش از ۱۰۰ گزارش را بررسی کرده که نامعتبر، تکراری یا غیرقابل‌بازتولید بوده‌اند. بااین‌حال، هر گزارش همچنان به فردی نیاز دارد که مشکل را بازتولید کند، تأثیر آن را بفهمد، راهکاری طراحی کند که نرم‌افزارهای موجود را از کار نیندازد و انتشار به‌روزرسانی‌ها را با توزیع‌کنندگان نرم‌افزار و شرکت‌های میزبانی هماهنگ کند.
«این وضعیت افشای هماهنگ آسیب‌پذیری‌ها را نیز دشوارتر می‌کند، زیرا ممکن است نگهدارندگان چندین گزارش تولیدشده با هوش مصنوعی دریافت کنند که هرکدام نشانه متفاوتی از یک نقص ریشه‌ای مشترک را توصیف می‌کنند. هم‌زمان، توسعه روش‌های سوءاستفاده از آسیب‌پذیری‌ها نیز سریع‌تر شده است. برنامه‌های امنیتی مبتنی بر هوش مصنوعی باید یک نمونه آزمایشی قابل‌بازتولید ارائه دهند، پژوهشگر انسانی مشخصی برای پاسخ‌گویی به پرسش‌ها داشته باشند و فرصت کافی در اختیار ارائه‌دهندگان پایین‌دستی قرار دهند تا بتوانند خود را آماده کنند.»
مغیث احمد، بنیان‌گذار DistroCode
«ما افزونه‌های وردپرس توسعه می‌دهیم و از وب‌سایت‌های مشتریان نگهداری می‌کنیم؛ بنابراین هر دو سوی این مسئله را می‌بینیم. هوش مصنوعی پیدا کردن آسیب‌پذیری‌ها را ارزان‌تر می‌کند، نه برطرف کردن آن‌ها را. نگهدارندگان گزارش‌های بیشتری دریافت خواهند کرد، درحالی‌که ساعات کاری آن‌ها تغییری نمی‌کند. همچنان باید کسی هر مشکل را بازتولید کند، احتمال هشدار اشتباه را بررسی کند و سپس اصلاحیه را بنویسد و آزمایش کند.
«حفظ محرمانگی اطلاعات تا زمان تعیین‌شده برای افشا نیز دشوارتر می‌شود، زیرا گروه‌های بیشتری به‌طور مستقل یک آسیب‌پذیری مشترک را کشف می‌کنند. نشریه فورچون گزارش داده که Calif و Wiz، هر دو با استفاده از هوش مصنوعی، در ماه اوت بخش‌هایی از PHP2Shell را مستقل از یکدیگر کشف کردند. این بار شناسه‌های CVE فاش شدند و PHP مجبور شد اصلاحیه‌ها را یک روز زودتر منتشر کند.»
رودیون سوروکین، هم‌بنیان‌گذار و مدیر ارشد فناوری The Capital Index
«هوش مصنوعی هزینه کشف آسیب‌پذیری‌ها را کاهش داده است، اما رفع آن‌ها همچنان پرهزینه است و بار مالی آن بر دوش داوطلبان می‌افتد. بخش بزرگی از وب به PHP وابسته است، بااین‌حال بنیاد PHP سال گذشته ۷۸۴ هزار و ۳۷۶ دلار هزینه کرده و منابع مالی لازم برای فعالیت ۱۱ توسعه‌دهنده را تأمین کرده است. اوپن‌ای‌آی انتظار دارد تعداد کشفیات مشابه به‌شدت افزایش یابد، اما ظرفیت نگهدارندگان با همین سرعت رشد نمی‌کند.
«فرایند افشای آسیب‌پذیری‌ها نیز زیر فشار قرار گرفته است. افشای هماهنگ بر این فرض استوار است که اطلاعات محرمانه باقی بمانند. اما در این پرونده، شناسه‌های CVE فاش شدند و PHP یک روز زودتر اصلاحیه‌ها را منتشر کرد. قاعده منصفانه این است: اگر با هوش مصنوعی آسیب‌پذیری پیدا می‌کنید، فقط گزارش نفرستید؛ اصلاحیه‌ای آزمایش‌شده و منابع مالی لازم را هم ارائه دهید. در غیر این صورت، نگهدارندگان با سیلی از گزارش‌ها روبه‌رو می‌شوند.»
رومن مارتیننکو، مهندس بنیان‌گذار فول‌استک در Henry AI
«کشف آسیب‌پذیری‌ها با هوش مصنوعی پیش از آنکه فناوری نگهداری نرم‌افزار را تغییر دهد، معادلات اقتصادی آن را دگرگون می‌کند. پیدا کردن نقص‌ها ارزان‌تر و سریع‌تر شده است. اما اثبات واقعی بودن مشکل، نوشتن اصلاحیه‌ای که نرم‌افزار کاربران فعلی را مختل نکند، آزمایش آن در نسخه‌های مختلف و افشای اطلاعات با ترتیب درست، همچنان کار انسان است. بیشتر پروژه‌های متن‌باز نیز نیروی انسانی چندانی برای اختصاص دادن به این وظایف ندارند.
«خطر اصلی همین فاصله میان سرعت کشف و توان اصلاح است. اگر سامانه‌های هوش مصنوعی آسیب‌پذیری‌های جدی را با سرعت بسیار بیشتری آشکار کنند، نگهدارندگان زمان کمتری برای جست‌وجوی نقص‌ها و زمان بیشتری برای اولویت‌بندی گزارش‌ها، اعتبارسنجی و هماهنگی انتشار نسخه‌های جدید زیر فشار خواهند داشت. پروژه‌هایی که بودجه مناسبی دارند می‌توانند این فشار را تحمل کنند، اما پروژه کوچکی که داوطلبان آن را اداره می‌کنند چنین ظرفیتی ندارد؛ حتی اگر کد آن در هزاران سامانه عملیاتی استفاده شود.
«راه‌حل این نیست که سرعت کشف آسیب‌پذیری‌ها را کاهش دهیم. باید برای بخش‌های کمتر جذاب اما ضروری کار، یعنی بررسی اولیه گزارش‌ها، آزمایش اصلاحیه‌ها و تعیین جدول زمانی روشن برای افشا، بودجه و نیروی انسانی فراهم کنیم. کشف آسیب‌پذیری‌ها در حال گسترش است و ظرفیت نگهداری نرم‌افزار نیز باید هم‌پای آن افزایش یابد؛ وگرنه انباشت مشکلات حل‌نشده، خودش به یک آسیب‌پذیری تبدیل می‌شود.»
راجش‌کومار راجاسکاران نایر، متخصص آزمون در شرکت IBM
«شناسایی آسیب‌پذیری‌ها به کمک هوش مصنوعی در حال تغییر معادلات اقتصادی امنیت نرم‌افزارهای متن‌باز است. گلوگاه اصلی دیگر صرفاً پیدا کردن نقص‌ها نیست؛ بلکه اعتبارسنجی آن‌هاست.
«هوش مصنوعی می‌تواند ضعف‌های احتمالی را در مقیاسی شناسایی کند که بررسی دستی به‌سختی توان رقابت با آن را دارد. اما پیش از انتشار اصلاحیه، همچنان باید امکان بازتولید یافته‌ها بررسی شود، تأثیر آن‌ها ارزیابی شود، راهکار اصلاحی تهیه شود و آزمون‌های بازگشت اجرا شوند تا اطمینان حاصل شود تغییرات جدید عملکرد قبلی نرم‌افزار را مختل نمی‌کنند. برای نگهدارندگان داوطلب، این روند می‌تواند به معنای افزایش کار بدون دستمزد باشد؛ به‌ویژه زمانی که گزارش‌های تولیدشده با هوش مصنوعی شامل هشدارهای اشتباه یا موارد تکراری باشند.
«افشای آسیب‌پذیری‌ها نیز دشوارتر می‌شود. گزارش انتشار زودهنگام اصلاحیه‌های PHP2Shell پس از پخش شدن شناسه‌های CVE نشان می‌دهد وقتی اطلاعات آسیب‌پذیری پیش از تکمیل فرایند افشای هماهنگ منتشر می‌شود، نگهدارندگان با چه سرعتی ممکن است تحت فشار قرار بگیرند.
«گزارش‌های آسیب‌پذیری تولیدشده با هوش مصنوعی باید شواهد قابل‌بازتولید داشته باشند و در صورت امکان، آزمون‌های بازگشت را نیز شامل شوند تا نگهدارندگان بتوانند یافته‌ها را تأیید کنند، نه اینکه ناچار باشند بررسی را از ابتدا انجام دهند. سازمان‌هایی که ابزارهای کشف آسیب‌پذیری با هوش مصنوعی توسعه می‌دهند نیز باید در تأمین هزینه بررسی و اولویت‌بندی گزارش‌ها مشارکت کنند، نه اینکه فقط برای کشف نقص‌ها بودجه اختصاص دهند.
«کشف سریع‌تر آسیب‌پذیری‌ها تنها زمانی امنیت را بهبود می‌دهد که نگهدارندگان بتوانند با این سرعت همراه شوند.»
تی. جی. مارلین، بنیان‌گذار و مدیرعامل Guardrail Technologies
«نگهدارندگان پروژه‌های متن‌باز با حجم کاری روبه‌رو شده‌اند که بیشتر این پروژه‌ها اساساً برای مدیریت آن طراحی نشده‌اند. هوش مصنوعی در کدهایی که دهه‌ها از عمرشان می‌گذرد آسیب‌پذیری پیدا می‌کند، اما تیم‌هایی که مسئول رفع آن‌ها هستند اغلب گروه‌های کوچکی از داوطلبان‌اند. ارزیابی هر گزارش جدید زمان می‌برد و بخشی از یافته‌های تولیدشده با هوش مصنوعی نیز در نهایت بی‌اساس از آب درمی‌آیند.
«نگرانی بزرگ‌تر، کوتاه‌تر شدن فرصت واکنش است. کشف آسیب‌پذیری فقط نخستین گام محسوب می‌شود. نگهدارندگان همچنان باید آن را تأیید کنند، اصلاحیه‌ها را آماده کنند، تغییرات امنیتی را به نسخه‌های قدیمی‌تر منتقل کنند و به کاربران هشدار دهند. هوش مصنوعی سرعت کشف را افزایش داده، اما سایر مراحل هنوز با آن هماهنگ نشده‌اند. اگر جزئیات پیش از آماده شدن اصلاحیه‌ها فاش شود، کاربران نرم‌افزار در معرض خطر باقی می‌مانند. ماجرای PHP2Shell یادآوری می‌کند که انتشار اطلاعات پیش از آمادگی نگهدارندگان، چقدر سریع می‌تواند فرایند افشای آسیب‌پذیری را به بحرانی جدی تبدیل کند.»
کادان اشتادلمن، بنیان‌گذار و مدیر ارشد فناوری سابق Komodo Platform
«در نتیجه جست‌وجوی آسیب‌پذیری‌ها با ابزارهای مبتنی بر هوش مصنوعی، نگهدارندگان اکنون بیش از هر زمان دیگری مجبورند گزارش‌های مربوط به نقص‌های نرم‌افزاری را بررسی کنند. بسیاری از این گزارش‌ها به دست انسان بررسی می‌شوند و در نهایت نادرست تشخیص داده می‌شوند. بعضی گزارش‌ها نیز از قلم می‌افتند و یا به‌موقع بررسی نمی‌شوند یا هرگز به آن‌ها رسیدگی نمی‌شود.
«هزینه‌ها می‌توانند بسیار سنگین باشند؛ همان‌طور که در پرونده PHP2Shell شاهد بودیم. منابع و امکاناتی از سراسر جهان، از جمله دولت‌ها و شرکت‌ها، برای سازمان‌دهی فرایند اصلاح و اعلام عمومی آن به کار گرفته شدند. کار روی اصلاحیه‌ها همچنان ادامه دارد. گزارش‌های بیشتری نیز دریافت می‌شوند که بررسی و تأیید آن‌ها به نیروی انسانی نیاز دارد.
«نظارت بر فرایند افشای آسیب‌پذیری‌ها همچنان بر عهده انسان است و همین مسئله می‌تواند خلأهایی ایجاد کند. اکنون رقابتی میان مدافعان و مهاجمان برای جست‌وجو و شناسایی آسیب‌پذیری‌ها در جریان است. این تازه آغاز ماجراست.
«در پرونده PHP2Shell، گزارش‌هایی درباره این مشکل پیش از آنکه بنیاد PHP به آن رسیدگی کند منتشر شدند و به دلیل ساختار حاکمیتی بنیاد، برای به حرکت درآوردن فرایند رسیدگی به پیگیری و فشار نیاز بود.
«همه‌چیز از جایی آغاز شد که هوش مصنوعی بر پایه تلاش‌های پژوهشگران انسانی امنیت سایبری پیش رفت و توانست حوزه‌هایی را بررسی کند که ورود به آن‌ها برای انسان‌ها عملاً امکان‌پذیر یا مقرون‌به‌صرفه نبود.»
مندی آندرس، مدیر ارشد امنیت اطلاعات در Elastic
«در چند روز گذشته، چندین آسیب‌پذیری مهم افشا شده‌اند که بسیاری از آن‌ها با کمک هوش مصنوعی شناسایی شده‌اند. اگر احساس می‌کنید سرعت اتفاقات تغییر کرده، درست احساس می‌کنید. این تحول غافلگیرکننده نیست؛ ما انتظارش را داشتیم، اما برای آن کاملاً آماده نبودیم.
«اگر مسئول امنیت یک سازمان باشید، تأثیر این وضعیت را در تیم خود احساس می‌کنید. صف اصلاحیه‌های در انتظار نصب طولانی‌تر می‌شود، هشدارهای امنیتی فوری روی هم انباشته می‌شوند و از همان افراد انتظار می‌رود با تک‌تک موارد مانند یک وضعیت اضطراری برخورد کنند. این مسیر به خستگی ناشی از مواجهه مداوم با آسیب‌پذیری‌ها و فرسودگی شغلی منتهی می‌شود. تیم‌های فرسوده نیز ممکن است مسائل واقعاً مهم را از دست بدهند. باید سرعت کار خود و اعضای تیم را مدیریت کنید و صریح بپذیرید که نمی‌توان با همه شناسه‌های CVE با سرعت یکسان برخورد کرد.
«اکنون فرصت مناسبی است که نگاه خود را از صف اصلاحیه‌ها فراتر ببریم. اگر میزان آسیب‌پذیری سازمان شما به این بستگی دارد که بتوانید سریع‌تر از مهاجمان اصلاحیه نصب کنید، معماری سامانه‌هایتان عملاً علیه شما عمل می‌کند. از این دوره استفاده کنید و بپرسید کدام اصول بنیادین می‌توانند اثر آسیب‌پذیری‌ها را کاهش دهند: بخش‌بندی قوی‌تر شبکه، کاهش سطح حمله، اجرای اصل حداقل سطح دسترسی، کنترل‌های سخت‌گیرانه‌تر هویت، شناسایی بهتر تهدیدها و واکنش مؤثرتر در مواردی که مهاجم موفق به عبور از دفاع‌ها می‌شود و اقدامات مشابه.
«نصب اصلاحیه‌های امنیتی همیشه اهمیت خواهد داشت، اما این تاب‌آوری است که به ما کمک می‌کند این دوره را پشت سر بگذاریم، بدون آنکه افرادی را که مسئول دفاع از ما هستند فرسوده کنیم.»