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