CVE-2026-109618 і CVE-2026-109619: розбір двох критичних вразливостей PHP і порядок реагування

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

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

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

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

Оцінка ризику для установ

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

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

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

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

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: оновлення не можна відкладати».