Критичні вразливості PHP: що це означає для сайтів проєктів відбудови

21 жовтня 2026 року команда PHP випустила позачергові оновлення, а Європейська група реагування на кіберінциденти CERT-EU опублікувала екстрене попередження. Дві вразливості з оцінкою небезпеки 9,2 з 10 дають виконати чужий код на сервері без авторизації.

PHP — мова, якою написана більшість сайтів: WordPress, Joomla, OpenCart, Bitrix, Laravel. У контексті відбудови це означає портали програм, сторінки збору коштів, реєстри пошкодженого майна, сайти громадських організацій і підрядників — тобто ресурси, де поруч лежать персональні дані, документи й платіжні реквізити.

Що саме знайшли

Вразливостей дві, обидві оцінені в 9,2 бала й обидві ведуть до одного результату — виконання чужого коду на сервері без авторизації.

CVE-2026-109618 — зрив під час нестачі пам'яті

У PHP є налаштування memory_limit: запит, який з'їв забагато пам'яті, обривається примусово. Проблема в тому, як саме він обривається. PHP може перерватися в момент, коли внутрішні дані запиту заповнені лише наполовину — наприклад, поки розбирається файл, надісланий через форму завантаження. Прибирання після такого запиту приймає недороблені дані за справжні й намагається звільнити пам'ять, якої ніколи не було. А в тій пам'яті може лежати те, що атакувальник поклав туди попередніми запитами.

CVE-2026-109619 — залишки попереднього запиту

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

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

Демонстраційний експлойт спрацьовує одним-єдиним неавторизованим запитом — ще до того, як почне виконуватися код самого сайту. Тобто ні плагіни безпеки, ні складні паролі, ні двофакторна автентифікація тут не допоможуть: атака відбувається рівнем нижче.

Які версії під загрозою

Усе, що нижче за ці версії, — уразливе:

Гілка PHP	Безпечна версія
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 і старіші	підтримки немає

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

Чому зламаний сайт проєкту — це питання довіри, а не лише техніки

Ніхто не шукає ваш проєкт окремо. Коли приклади експлуатації стають публічними — а вони вже публічні, — за кілька годин запускаються автоматичні сканери, які перебирають увесь інтернет підряд. Їм байдуже, це портал національної програми чи сторінка ініціативи на одну громаду: важить лише версія, якою відповідає сервер.

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

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

Що робити — покроково

1. Дізнайтеся свою версію. У панелі хостингу це розділ «Версія PHP» або «PHP Selector»; на власному сервері — команда php -v. Важливо перевірити версію, якою працює саме сайт, а не ту, що стоїть у командному рядку: вони часто різні.
2. Оновіться в межах своєї гілки. Перехід з 8.2.29 на 8.2.35 — це виправлення всередині однієї гілки: сумісність зберігається, сайт від цього не ламається. Не плутайте з переходом з 8.2 на 8.4 — ось він уже потребує перевірки.
3. Якщо у вас 8.1 або старіше — підтримки цих гілок немає. Через серйозність ситуації команда безпеки PHP випустила мінімальні виправлення й для 7.4, 8.0 та 8.1, а частина хостерів тримає власні збірки. Але правильне рішення — переїзд на підтримувану гілку, і краще планувати його зараз, а не наступного разу.
4. Перезапустіть обробники. Без перезапуску php-fpm чи Apache робочі процеси далі працюють на старому коді, і оновлення фактично не діє.
5. Перевірте результат. Найпростіше — тимчасова сторінка з phpinfo(), яку одразу після перевірки треба видалити, або ж розділ «Версія PHP» у панелі після перезавантаження.

Користувачам хостингу найчастіше нічого робити руками не доведеться: великі провайдери отримали виправлення заздалегідь і оновлюють свої машини самі. Варто написати в підтримку один рядок — «чи оновлено PHP до версій від 21 жовтня 2026» — і отримати відповідь письмово.

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

Буває, що сайт старий, а оновлення вимагає підготовки. Тоді є тимчасові заходи, які звужують вікно для атаки:

• заборонити переповнення пам'яті як точку входу: memory_limit=-1, заданий так, щоб застосунок не міг це перевизначити, і перевірка, що жоден пул чи каталог не повертає ліміт назад;
• зменшити post_max_size — 8M для сайтів без завантаження файлів, 32M якщо завантаження потрібні, а upload_max_filesize тримати нижче;
• вимкнути session.upload_progress.enabled і перезапустити всі робочі процеси;
• на PHP 8.5 додатково вимкнути fatal_error_backtraces;
• обмежити розмір і складність запитів на рівні вебсервера чи проксі.

Жоден із цих заходів не робить установку безпечною. Вони лише перекривають відомі шляхи — повністю проблему закриває тільки оновлення.

Якщо й це неможливо, CERT-EU радить просте й непопулярне рішення: прибрати вразливий сервіс із публічного інтернету, доки виправлення не буде встановлене й перевірене.

Звідки ці дані

• CERT-EU, Security Advisory 2026-018 «Critical Vulnerabilities in PHP»
• Оголошення про випуск оновлень на php.net
• Технічний опис CVE-2026-109618 і CVE-2026-109619

---

Якщо у вашому проєкті немає людини, яка відповідає за оновлення й доступи, аудит ресурсів можна замовити зовні — зокрема в SmartGT.

Автор матеріалу — SmartGT. Першоджерело: «Критичні вразливості PHP: оновлення не можна відкладати».