Штучний інтелект допомагає дослідникам знаходити небезпечні помилки у програмному забезпеченні, яке роками забезпечувало роботу сайтів. Але безпека інтернету залежить і від того, чи встигають люди перевіряти знахідки, готувати виправлення та встановлювати їх на серверах.
Саме про цю нерівність темпів говорили Ентоні Га, Шон О’Кейн і Кірстен Коросек у подкасті Equity. Скорочену версію розмови TechCrunch опублікував 24 жовтня. Приводом стали вразливості PHP2Shell, а ширше питання звучить неприємно: що станеться, коли складні помилки почнуть знаходити швидше, ніж індустрія навчиться їх виправляти?
Інтернет «на клеї та мріях»
Шон О’Кейн описав інтернет як конструкцію, що тримається «на клеї та мріях». За цим образом — залежність великих сервісів від спільних програмних компонентів, які часом підтримують невеликі команди з обмеженими ресурсами.
Старий код може роками виконувати свою роботу. Проте тривалий строк використання не гарантує, що всі небезпечні сценарії вже перевірили. Зміна інструментів дослідження здатна показати проблему там, де раніше бачили лише незручний збій.
PHP2Shell добре ілюструє цю складність. У історії дослідження Calif є попередні повідомлення про проблеми, нові перевірки та поступове з’ясування того, як вони можуть призвести до виконання стороннього коду. Це довга робота з переоцінювання ризику.
Відкритий код дозволяє незалежним командам досліджувати такі помилки й допомагати з виправленнями. Водночас доступність вихідних текстів сама собою не забезпечує проєктові достатньо людей, часу та фінансування.
Яку роль тут відіграв штучний інтелект
У розмові Ентоні Га виправив власне попереднє твердження про те, що конкретні вразливості знайшла мовна модель: він наголосив на роботі дослідників і допомозі ШІ з експлуатацією. Водночас первинні матеріали описують ширшу участь моделей у дослідженнях.
Зокрема, в описі спільного реагування на PHP2Shell OpenAI повідомляє, що Calif виявила критичну помилку з використанням GPT‑5.6 Sol, а Wiz незалежно знайшла й повідомила про обидві вразливості. Виправлення та випуск оновлень очолювали розробники PHP.
Точніше говорити про роботу дослідницьких команд із моделями. Люди ставлять запитання, перевіряють результати й визначають, чи справді знайдена поведінка створює загрозу. ШІ може прискорювати окремі етапи цієї роботи — і так само допомагати атакувальникам.
Між знахідкою та захищеним сервером
21 жовтня розробники опублікували виправлення для двох вразливостей PHP2Shell — CVE-2026-109618 і CVE-2026-109619. Однак реліз ще потрібно доставити до дистрибутивів, хостингів і конкретних серверів. На Desing уже є окремий розбір того, що перевірити власнику сайту після виходу виправлень PHP2Shell.
Зазвичай дослідники спочатку конфіденційно повідомляють про помилку розробникам. Це дає час підготувати захист до оприлюднення подробиць. Для поширеного компонента доводиться узгоджувати дії багатьох незалежних організацій.
При цьому спільна дата розкриття не гарантує, що ніхто не знайшов проблему раніше. Amazon Threat Intelligence зафіксувала спробу експлуатації 17 жовтня у своїй системі серверів-приманок MadPot. Компанія не встановила, як атакувальник отримав потрібні відомості. Сам запис також не доводить успішного проникнення в реальний сервіс.
Тому я б оцінював готовність інфраструктури за всім шляхом виправлення: від підтвердження помилки до перевірки оновленого сервера. Швидкість пошуку — лише одна його частина.
Невеликі сайти можуть заплатити доступністю
Кірстен Коросек звернула увагу на можливі наслідки для невеликих організацій і вебресурсів. Якщо власник не має коштів або фахівця для термінових робіт, відновлення сайту може затягнутися. Частина ресурсів теоретично може не повернутися взагалі. Це побоювання щодо майбутнього, а не підтверджений результат PHP2Shell.
Тимчасова зупинка теж потребує уваги: ми вже розбирали, чому під час обслуговування важливий HTTP 503. Проте правильний код відповіді не замінить людей, які повернуть сайт до роботи.
ШІ може допомагати й захисникам — з аналізом коду, перевіркою виправлень та пошуком споріднених помилок. Але якщо швидкість досліджень зростатиме, підтримка базових компонентів також потребуватиме більше ресурсів. Інакше між повідомленням про вразливість і реально захищеним сайтом залишатиметься надто довга пауза.