Дві діри в PHP на 9,2 бала: що це означає для бізнесу й скільки коштує зволікання

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

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

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

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