PHP — мова програмування, на якій працюють 69,3% сайтів з відомою серверною мовою. 21 жовтня її розробники випустили термінове оновлення, яке закриває дві критичні вразливості під спільною назвою PHP2Shell.
Частина організацій, від урядових сервісів Фінляндії та Нідерландів до Nintendo, на час оновлення превентивно вимикала свої сайти. Для більшості сайтів достатньо вчасно оновити PHP, але є винятки, на які варто звернути увагу.
Розбираємо, як помилка в мові програмування за дві доби переросла в глобальний інцидент, чому до нього причетний ШІ, кого він зачіпає найбільше і що змінює для власників сайтів.
Що таке PHP2Shell і чому це стосується більшості сайтів
Масштаб інциденту визначає не стільки оцінка, скільки поширеність самої мови: за даними W3Techs, PHP використовують 69,3% сайтів, серверна мова яких відома. На ньому працюють WordPress, Drupal, Joomla, Magento, шеред-хостинги, панелі керування і чимало програм, які не афішують, що всередині в них PHP.
Обидві помилки виникають, коли PHP аварійно перериває обробку запиту. У першому випадку запит вичерпує ліміт памʼяті в невдалий момент, і PHP залишає частково сформовані дані, які згодом сприймає як коректні. У другому стан попереднього запиту зберігається в памʼяті, і ним може скористатися наступний запит, який обробляє той самий процес. В обох випадках зловмисник отримує змогу виконати на сервері власний код. Звідси й назва: shell — це доступ до командного рядка сервера.
Від більшості вразливостей, про які власники сайтів дізнаються з новин, PHP2Shell відрізняють три речі:
- Атака не потребує авторизації. Компанія Calif підтвердила таку атаку на конкретних версіях популярних CMS.
- На серверах з Apache mod_php продемонстрований експлойт спрацьовує ще до запуску коду сайту, тож захисні плагіни CMS, які працюють усередині цього коду, не встигають втрутитися.
- Дослідники Wiz зазначають, що щонайменше одна з двох вразливостей є в кожній версії PHP за останні десять років, починаючи з 5.4.
На практиці атака складається з трьох кроків. Зловмисник надсилає на сайт спеціально сформований запит, PHP аварійно обриває його обробку, а в памʼяті залишаються дані, якими можна скористатися. Після цього зловмисник запускає на сервері власний код — з тими самими правами, що й у сайту. Що він зробить далі, залежить від його цілей: викрадення даних, підміну вмісту сторінок і контроль над сервером.
Як ШІ прискорив і пошук вразливостей, і атаки
Вразливості, які існували в PHP понад десять років, у серпні–вересні знайшли дослідники трьох компаній — Calif, OpenAI і Wiz, і всі три використовували для цього ШІ-моделі. Майже два місяці PHP Foundation тримала знахідку в таємниці, поки готувала виправлення. Зазвичай подробиці таких вразливостей стають публічними одночасно з релізом, щоб у зловмисників не було часу підготувати атаки.
Цього разу схема дала збій. 20 жовтня номери вразливостей зʼявилися в соцмережах, Calif помилково опублікувала відео з робочим прикладом атаки, а вранці 21 жовтня компанія Chainguard виклала у відкритий доступ збірки PHP з виправленням — за кілька годин до офіційного релізу. PHP Foundation вважає, що Chainguard порушила домовленість, а гендиректор компанії — що лише захистила клієнтів від атак, які вже почалися. Cloudflare справді зафіксувала перші атаки ще до виходу оновлення, тому частина організацій вимкнула сайти до встановлення виправлень.
ШІ відіграв роль і з боку нападу. Гендиректор Chainguard розповів, що його команда, знаючи лише про сам факт проблеми, знайшла ті самі вразливості за допомогою ШІ і базового запиту «знайди серйозні вразливості в PHP». Компанія watchTowr фіксує атаки з експлойтів, написаних за допомогою ШІ: станом на 21 жовтня жодна не була успішною, але в компанії не очікують, що так буде довго. В Україні цю тенденцію бачить і CERT-UA: у січні–вересні 2026 року команда фіксувала ознаки використання ШІ зловмисниками значно частіше, ніж торік.
Практичний наслідок — вікно між новиною про вразливість і першими атаками скоротилося до кількох годин. Цикл оновлень, розрахований на тижні, за таких умов не встигає.
Яким сайтам варто приділити більше уваги
Для більшості сайтів питання закриває звичайне оновлення: виправлення вийшли для всіх гілок PHP, які зараз підтримуються, — від 8.2 до 8.5. Складніше тим, чий сайт працює на PHP 8.1 або старішій версії: ці версії більше не підтримуються, тож офіційного оновлення для них немає.
Для 7.4, 8.0 і 8.1 команда PHP опублікувала мінімальні патчі вихідного коду, але, як пояснюють у CybelAngel, застосувати їх може лише той, хто сам збирає PHP, а не власник звичайного хостинг-акаунта. Частина Linux-дистрибутивів і постачальників розширеної підтримки випускає власні виправлення для старих версій, тож тут усе залежить від конкретного провайдера. AWS радить власникам таких сайтів переходити на підтримувану гілку PHP.
Таких сайтів чимало. За даними WordPress.org, які наводить The Repository, 35,1% сайтів на WordPress працюють на версії PHP, яку вже не підтримують, зокрема 16,46% — на PHP 7.4. Найчастіше це сайти, які давно не оновлювали: старі корпоративні сторінки, архівні промосторінки, інтернет-магазини на застарілих модулях. Malwarebytes називає таку забуту інфраструктуру головним довгостроковим завданням після PHP2Shell.
Якщо сайт на незахищеній версії все ж атакують, дослідники Wiz попереджають про можливу втрату контролю над сервером, витік даних і підміну вмісту сторінок. Тому версію PHP варто перевірити, навіть якщо сайт працює стабільно.
Як захистити сайт від PHP2Shell
Єдиний повноцінний захист — оновити PHP до виправленої версії: 8.2.35, 8.3.36, 8.4.27 або 8.5.12. PHP наголошує, що тимчасові налаштування лише знижують ризик, а повністю закриває обидві вразливості тільки оновлення. Хто має це зробити, залежить від того, де працює ваш сайт.
Якщо сайт працює на хостингу
На шеред-хостингу PHP зазвичай оновлює провайдер. Великі хостери почали це робити в день релізу: Namecheap, зокрема, встановлював оновлення на всіх своїх платформах, а Automattic повідомила, що сайти на її хостингу для WordPress уже захищені.
Втім, оновлення на рівні провайдера не завжди означає оновлення конкретного сайту. Malwarebytes радить отримати від хостингу чи ІТ-підрядника підтвердження, що виправлення вже встановлені, а не лише заплановані. Ось що варто уточнити в листі до підтримки:
- Чи оновлено PHP на сервері, де працює ваш сайт, і до якої версії.
- Яку версію PHP використовує ваш сайт і чи вона ще підтримується.
- Чи охоплює оновлення всі ваші сайти, піддомени й тестові копії.
- Чи варто тимчасово закрити сайт, якщо оновити PHP одразу неможливо.
Якщо у вас власний сервер
Якщо сайт працює на VPS, виділеному сервері чи в хмарі, оновлення — відповідальність вашої команди або підрядника.
Варто попросити розробника перевірити всі місця, де працює PHP, а не лише основний сайт. Як зауважує дослідник Huntress Джон Геммонд, кількість місць, де доводиться шукати вразливі версії PHP, дуже швидко стає великою.
Якщо сайт працює на PHP 8.1 або старішій версії
Для таких сайтів простого оновлення немає. Можливі два шляхи: перейти на підтримувану гілку PHP або знайти постачальника, який випускає виправлення для старої версії. Перший шлях надійніший, але може потребувати доопрацювання коду сайту, тому його варто обговорити з розробником якнайшвидше.
Якщо плануєте перехід, враховуйте, що PHP 8.2 отримуватиме оновлення безпеки лише до 31 грудня 2026 року. Тому раціональніше одразу переходити на 8.3 або новішу версію.
Як закрити сайт на час оновлення без втрати позицій у Google
Для тих, хто закриває сайт на час оновлення, Джон Мюллер з Google радить віддавати код HTTP 503 замість таймаутів, 404 чи 500 і налаштовувати його поза PHP: через DNS або CDN.
Google рекомендує тримати 503 годинами, а не тижнями, тож закриття варто планувати як коротку операцію. Порядок дій описаний у документації Google про планований простій і тимчасове призупинення сайту.
Регулярні оновлення стали частиною базової безпеки сайту
Багато компаній роками не оновлюють сайт, поки він працює без збоїв. PHP2Shell показав, що така стратегія більше не захищає. Якщо ШІ дозволяє знайти вразливість і зібрати атаку за години, сайт, який оновлюють раз на кілька років, залишається відкритим саме тоді, коли атаки вже почалися. Експерти висловлюють занепокоєння тим, що мільйони сайтів досі працюють на версіях PHP, які, найімовірніше, неможливо оновити.
Захист у такій реальності тримається не на технічних знаннях власника, а на організації процесу. Версія PHP і дата завершення її підтримки мають бути відомі так само, як термін дії домену чи SSL-сертифіката. За оновлення відповідає конкретна людина чи підрядник: CERT-UA серед базових рекомендацій для вебресурсів називає саме наявність фахівців, відповідальних за розгортання, налаштування та оновлення.
Ще одна складова — заздалегідь узгоджений сценарій на випадок наступної критичної вразливості: хто ухвалює рішення про закриття сайту, хто налаштовує код 503 і хто комунікує з клієнтами. З таким сценарієм термінова новина перетворюється на робоче завдання на кілька годин.
PHP2Shell — проблема не окремого плагіна чи CMS, а основи, на якій працює більшість сайтів у світі. Поширеність PHP пояснює масштаб превентивних відключень, а ШІ — швидкість подій: він допоміг і знайти вразливості, і за години побудувати атаки.
Для сайтів на підтримуваних версіях PHP ключова дія — переконатися, що встановлено 8.2.35, 8.3.36, 8.4.27 або 8.5.12, і отримати підтвердження від хостингу чи розробника. Для сайтів на PHP 8.1 і старших версіях простого оновлення немає, тому перехід на підтримувану гілку варто планувати вже зараз.
Ширше PHP2Shell змінює саму роль оновлень: це вже не технічна дрібниця, а регулярний процес з відповідальною людиною і планом дій, такий самий обовʼязковий, як хостинг і домен.
