Критична уразливість PHP (php2shell): чи зачіпає вона ваш сайт

21 жовтня 2026 року PHP Foundation позапланово випустила виправлення двох критичних уразливостей у самому PHP — не в плагіні, не в темі, не в CMS, а в мові, на якій працює більшість сайтів у світі. Пара отримала назву php2shell і рейтинг небезпеки 9.2 з 10. Нижче — що саме сталося, чому звичні засоби захисту тут не допомагають, як за п’ять хвилин перевірити свій сайт і що робити, якщо виявиться, що версія стара.

Що знайшли

Йдеться про дві окремі уразливості:

• CVE-2026-109618 — помилка в обробці ситуації, коли PHP вичерпує доступну пам’ять. Якщо пам’ять закінчується в момент, коли внутрішні дані запиту ще не до кінця сформовані, прибирання після збою працює з ними як із нормальними.
• CVE-2026-109619 — звернення до вже звільненої пам’яті. Залишки стану від одного запиту вказують на пам’ять, яку вже віддано системі, і наступний запит у тому самому робочому процесі може цим скористатися. Підтверджений наслідок — зчитування чужих даних із пам’яті.

Обидві дозволяють виконати власний код на сервері без будь-якої авторизації. Уразливий фрагмент, за даними дослідників, присутній у коді щонайменше з PHP 5.4 — тобто понад десять років.

Чому це серйозніше за звичайну дірку в плагіні

Ключова деталь: атака відбувається до того, як запускається код вашого сайту. Звичайний HTTP-запит обробляє спочатку PHP, і лише потім керування отримує WordPress, OpenCart чи ваш власний код. Через це не працює нічого з того, на що зазвичай розраховують:

• складний пароль адміністратора й двофакторна автентифікація — до форми входу справа не доходить;
• плагіни безпеки, ліміти спроб входу, капчі — вони живуть усередині CMS;
• закритий /wp-admin/ чи інша адмінка за IP — атака не потребує адмінки взагалі.

Під удар потрапляють усі способи запуску PHP для вебу: PHP-FPM, Apache з mod_php, php-cgi, LiteSpeed, FrankenPHP. Найвищим ризик вважають для mod_php.

Які версії виправлені

• Виправлено: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35. Якщо у вас одна з них або новіша — цю конкретну проблему закрито.
• PHP 7.4 – 8.1: офіційних релізів немає, команда безпеки PHP віддала мінімальні правки у вихідному коді. Великі хостинги й збірки на їхній основі ці правки застосували й перезібрали пакети — але це потрібно перевіряти в конкретного провайдера, а не вважати за замовчуванням.
• PHP 5.x – 7.3: підтримки немає, виправлення не буде й не з’явиться. Єдиний варіант — переходити на сучасну версію.

Як перевірити свій сайт за п’ять хвилин

Три способи, від простого до точного:

• Панель хостингу. У будь-якій панелі є розділ вибору версії PHP для домену. Там видно поточну версію — наприклад 8.2 або 8.3. Проблема в тому, що панель зазвичай показує лише дві цифри, а нам потрібна третя: не «8.2», а «8.2.35».
• Адмінка WordPress. «Інструменти» → «Стан сайту» → вкладка «Інформація» → розділ «Сервер». Там повна версія PHP із трьома цифрами.
• Заголовки відповіді сервера. Багато серверів самі повідомляють версію в заголовку X-Powered-By. Перевірити можна будь-яким онлайн-сервісом перевірки заголовків. Якщо заголовок приховано — це нормально й навіть добре, просто скористайтеся попередніми способами.

Що робити з результатом:

• версія 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 або вища — усе гаразд;
• версія 8.2 – 8.5, але нижча за вказані — потрібно оновити, це робиться в панелі хостингу або запитом у підтримку;
• версія 7.4 – 8.1 — напишіть у підтримку хостингу й запитайте прямо: чи застосовано виправлення php2shell у вашій збірці. Якщо відповідь невиразна — вважайте, що ні;
• версія 7.3 і нижче — переходити на нову версію, причому це окрема робота: старі сайти часто не запускаються на сучасному PHP без правок коду.

Якщо оновити прямо зараз не виходить

PHP опублікувала тимчасові налаштування, які зменшують ризик, але не роблять сервер безпечним: memory_limit=-1 без можливості перевизначення з боку застосунку, session.upload_progress.enabled=0, а на PHP 8.5 додатково fatal_error_backtraces=0. Після змін обов’язково перезапустити всі робочі процеси PHP. Окремо варто знати, що популярна порада «просто вимкніть session upload progress» виправленням не є — це покриває лише частину проблеми.

Якщо сайт критичний, а оновити хостинг швидко неможливо, адекватний тимчасовий захід — закрити його від зовнішнього доступу до оновлення, а не сподіватися на налаштування.

Чи вже атакують

Картина станом на кінець жовтня неоднозначна й це варто знати чесно. Amazon повідомила про спробу використання проти своїх приманок 17 жовтня — за чотири дні до публічного розкриття; дослідники watchTowr бачать активність у своїй мережі приманок із 21 жовтня. Водночас Cisco Talos і Rapid7 на 21–22 жовтня підтверджених випадків успішного зламу не зафіксували, а в каталог активно експлуатованих уразливостей CISA ці CVE на 23 жовтня не внесені. Публічні демонстрації працюють лише для конкретних поєднань операційної системи, версії PHP і веб-сервера, універсального й надійного експлойта поки не видно.

Висновок із цього не «можна не поспішати», а протилежний: зараз є вікно, коли оновитися ще не дорого. Так уже було з минулими уразливостями такого класу — масові автоматичні сканування починаються через тижні після розкриття, коли хтось доводить демонстрацію до стабільного вигляду.

Що з цього варто винести на майбутнє

php2shell — окремий випадок, але причина, через яку такі історії болючі, системна:

• Версія PHP — не «технічна дрібниця». Сайт на PHP 7.3 працює й виглядає нормально, доки не з’явиться саме така новина, після якої варіантів уже немає.
• Оновлення мають бути керованими. Між «оновити версію PHP» і «сайт відкрився після оновлення» лежить перевірка: частина старих плагінів і саморобного коду відмовляється працювати на нових версіях. Саме тому цим краще займатися планово, а не в день появи CVE.
• Бекап потрібен до, а не після. Перед будь-якою зміною версії PHP має бути свіжа копія файлів і бази, яку ви вмієте розгорнути.

Ми тримаємо версії PHP актуальними на всіх проєктах, які у нас на підтримці, — тож цього разу оновлення пройшли без участі клієнтів. Про те, що взагалі входить у такий супровід, ми писали окремо: що входить у підтримку сайту і скільки вона коштує. Загальна гігієна безпеки сайту — у статті як захистити сайт від зламу.

Перевіримо ваш сайт

Якщо не хочеться розбиратися самостійно — напишіть, подивимося. Що робимо:

• перевіряємо реальну версію PHP на вашому сервері, а не ту, що показує панель;
• з’ясовуємо, чи застосовано виправлення, якщо версія з тих, де офіційного релізу немає;
• дивимося решту: версію CMS, застарілі плагіни, права на файли, наявність робочих бекапів, сліди вже наявного зламу;
• оновлюємо версію PHP із попередньою копією й перевіркою, що сайт після цього працює повністю, а не «головна відкривається»;
• віддаємо перелік знайденого з поясненням, що критично, а що зачекає.

Перевірка сайту на цю уразливість — безкоштовна, це п’ятнадцять хвилин роботи. Пишіть у Telegram @imajik або на in@aws.in.ua. Якщо після перевірки знайдеться що лагодити — скажемо обсяг і ціну до початку робіт, беремо й чужі сайти: підтримка та доробка сайтів.