Критичні вразливості PHP: оновлення не можна відкладати

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

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

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

Вразливостей дві, обидві оцінені в 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

---

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