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 актуальними на всіх проєктах, які у нас на підтримці, — тож цього разу оновлення пройшли без участі клієнтів. Про те, що взагалі входить у такий супровід, ми писали окремо: що входить у підтримку сайту і скільки вона коштує. Загальна гігієна безпеки сайту — у статті How to Protect a Website from Hacking.
Перевіримо ваш сайт
Якщо не хочеться розбиратися самостійно — напишіть, подивимося. Що робимо:
- перевіряємо реальну версію PHP на вашому сервері, а не ту, що показує панель;
- з’ясовуємо, чи застосовано виправлення, якщо версія з тих, де офіційного релізу немає;
- дивимося решту: версію CMS, застарілі плагіни, права на файли, наявність робочих бекапів, сліди вже наявного зламу;
- оновлюємо версію PHP із попередньою копією й перевіркою, що сайт після цього працює повністю, а не «головна відкривається»;
- віддаємо перелік знайденого з поясненням, що критично, а що зачекає.
Перевірка сайту на цю уразливість — безкоштовна, це п’ятнадцять хвилин роботи. Пишіть у Telegram @imajik або на in@aws.in.ua. Якщо після перевірки знайдеться що лагодити — скажемо обсяг і ціну до початку робіт, беремо й чужі сайти: підтримка та доробка сайтів.
Telegram