Критична вразливість PHP: що робити власникам сайтів та інтернет-магазинів

21 жовтня 2026 року PHP Group випустила екстрені оновлення, які закривають дві критичні вразливості — CVE-2026-109618 та CVE-2026-109619. Обидві дозволяють виконати на сервері довільний код без жодної авторизації: зловмиснику достатньо надіслати сайту спеціально підготовлений запит. Під загрозою практично всі сайти на PHP — WordPress, WooCommerce, OpenCart, ocStore, Laravel, самописні системи. Оновлення самої CMS чи плагінів тут не допомагає: вразливість у PHP, а не в коді сайту.

Що сталося

Команда безпеки PHP оцінила обидві вразливості в 9.2 бала за шкалою CVSS v4.0 — це критичний рівень. Деталі мали залишатися закритими до виходу виправлень, але частина інформації просочилася заздалегідь, а разом з нею — знімок екрана готового інструменту для атаки. За оцінками дослідників безпеки, масові автоматичні атаки починаються в перші години після публікації виправлень: боти просто обходять інтернет і перевіряють усі сайти поспіль.

Виправлені версії: PHP 8.5.12, 8.4.27, 8.3.36 та 8.2.35. Усе, що старіше, — вразливе.

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

Чому це небезпечно саме для бізнесу

Виконання коду на сервері означає, що зловмисник отримує все, до чого має доступ ваш сайт. Для інтернет-магазину це:

• Уся база клієнтів — імена, телефони, адреси доставки, email, історія замовлень. Це витік персональних даних з усіма юридичними наслідками.

• Ключі платіжних модулів. LiqPay, WayForPay, Monobank та інші платіжні системи зберігають секретні ключі в налаштуваннях сайту. З ними можна підробляти відповіді платіжної системи — наприклад, позначати замовлення як оплачені, хоча грошей не надходило.

• Підміна сторінки оплати. На сторінку оформлення замовлення можна непомітно вбудувати фальшиву форму введення картки. Картки викрадають у ваших покупців, а репутаційний удар отримуєте ви.

• Токени інтеграцій — Нова Пошта, обмін з 1С/BAF, поштові скриньки сайту, рекламні кабінети.

• Сусідні сайти. На звичайному хостингу всі сайти одного акаунта зазвичай доступні один одному: зламаний один — під загрозою решта.

• Використання вашого сайту проти вас — розсилка спаму, фішингові сторінки під вашим доменом, SEO-спам. Як наслідок — блокування в Google, проблеми з рекламою та поштою.

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

Хто під загрозою: таблиця версій

Зверніть увагу: PHP 8.2 підтримується лише до 31 грудня 2026 року. Якщо переходите зараз — краще одразу на 8.3 або 8.4.

Що робити: покроковий план

Крок 1. Дізнайтеся реальну версію PHP сайту

Панель хостингу зазвичай показує лише гілку — «8.2» чи «8.4». А важлива повна версія: 8.2.34 вразлива, 8.2.35 — ні. Найнадійніший спосіб — тимчасовий файл у корені сайту. Створіть файл з довільною назвою, наприклад v_8264.php, з таким вмістом:

<?php echo PHP_VERSION, " ", PHP_SAPI;

Відкрийте його в браузері (https://ваш-сайт/v_8264.php), запишіть результат і одразу видаліть файл. Не використовуйте для цього phpinfo() і не залишайте такі файли на сервері: вони показують зловмисникам зайву інформацію.

Команда php -v в SSH показує версію для командного рядка — вона може відрізнятися від тієї, на якій працює сайт.

Крок 2. Звичайний хостинг: напишіть у техпідтримку

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

Доброго дня. Щодо критичних вразливостей PHP CVE-2026-109618 та CVE-2026-109619 (php.net, 21.10.2026): коли на нашому хостингу будуть встановлені виправлені версії PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12? Чи застосовуєте ви бекпорт виправлень для гілок 8.1 і старіших? Який обробник PHP використовується для наших сайтів (mod_php, PHP-FPM чи LSAPI)? Дякую.

Паралельно перевірте в панелі, на якій версії працює кожен сайт. Усе, що на 8.1 і нижче, — пріоритет номер один (див. крок 5).

Крок 3. Власний сервер або VPS: оновіть пакети

Дистрибутиви Linux отримали виправлення заздалегідь, тож оновлення вже мають бути в репозиторіях. Для Debian/Ubuntu:

apt update
apt list --upgradable 2>/dev/null | grep -i php
apt install --only-upgrade 'php*'
systemctl restart 'php*-fpm'   # і apache2, якщо використовується mod_php

Після оновлення обов'язково перезапустіть усі процеси PHP — без цього сервер працюватиме зі старим кодом у пам'яті. У дистрибутивних пакетах номер версії може не збігатися з офіційним, тому наявність виправлення перевіряйте в changelog пакета за номером CVE.

Якщо PHP встановлено з репозиторію remi, врахуйте: за даними PHP Group, оновлення там з'являться із затримкою. На час до їх виходу застосуйте тимчасові заходи з кроку 4.

Крок 4. Тимчасові заходи до оновлення

Це не замінює оновлення, а лише закриває відомі шляхи атаки. У панелі хостингу (розділ налаштувань PHP або «Власний php.ini») задайте:

session.upload_progress.enabled = Off
post_max_size = 32M
upload_max_filesize = 30M

Якщо сайт взагалі не приймає завантаження файлів від відвідувачів, post_max_size можна зменшити до 8M. На PHP 8.5 додайте також fatal_error_backtraces = Off.

Важливо: ці налаштування мають діяти на рівні сервера — через php.ini, налаштування пулу PHP-FPM або панель хостингу. Файл .user.ini і виклики ini_set() у коді тут не працюють: вони застосовуються вже після того, як запит розібрано.

Для сайтів, де відвідувачі не завантажують файли (більшість інтернет-магазинів на OpenCart, сайтів-візиток), можна додатково заборонити запити з завантаженням файлів на рівні вебсервера. На Apache — на початку .htaccess:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteCond %{REQUEST_URI} !^/admin/
RewriteRule .* - [F,L]

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

Крок 5. Сайт на PHP 7.x або 8.0–8.1

Це найскладніший випадок. Офіційних виправлень для цих версій немає, а старий сайт часто просто не запускається на новому PHP. Варіанти:

1. Запитати хостинг про бекпорт. Команда PHP опублікувала мінімальні виправлення для 7.4, 8.0 та 8.1 у вигляді вихідного коду, а деякі провайдери (наприклад, на CloudLinux) підтримують власні збірки старих версій. Уточніть це прямо.

2. Перевірити сайт на PHP 8.2+ на копії. Багато сайтів на OpenCart 3.x, старих версіях WordPress запускаються на новому PHP після виправлення кількох модулів. Це значно дешевше, ніж розробка нового сайту. Перевіряйте на тестовому піддомені, не на робочому сайті.

3. Заплануйте оновлення рушія. Якщо сайт не вдається перевести на сучасний PHP, це вже питання не однієї вразливості: наступна буде так само без виправлення. До завершення робіт — обов'язково тимчасові заходи з кроку 4.

Крок 6. Резервна копія та нагляд

Зробіть свіжу резервну копію файлів і бази даних саме зараз та збережіть її окремо — як «еталон до». Протягом одного-двох тижнів після оновлення стежте за сайтом: так ви помітите злам, якщо він стався до встановлення виправлення.

Чого не робити

• Не покладайтеся на оновлення CMS, плагінів чи теми — вразливість у самому PHP.

• Не відкладайте до вихідних: автоматичні атаки вже йдуть.

• Не вважайте тимчасові заходи повноцінним захистом — це лише страховка до оновлення.

• Не перемикайте версію PHP на робочому магазині без резервної копії та перевірки — можна отримати «білий екран» посеред робочого дня.

Ознаки того, що сайт уже могли зламати

• Нові файли .php у папках із зображеннями, кешем, завантаженнями (image/, uploads/, cache/, storage/).

• Змінені файли шаблону, особливо сторінки оформлення замовлення та оплати.

• Незнайомі адміністратори в адмінці сайту, змінені налаштування платіжних модулів.

• Скарги покупців на дивну форму оплати, переадресації на сторонні сайти.

• Попередження Google Search Console, різке зростання вихідної пошти з сервера.

Якщо знайшли сліди злому

Не видаляйте підозрілі файли поодинці — так легко пропустити головне. Збережіть копію поточного стану для аналізу, змініть паролі до бази даних, адмінки, FTP/SSH і хостинг-акаунта, перевипустіть ключі платіжних модулів та API-токени інтеграцій. Далі — відновлення з чистої копії або ретельне очищення з пошуком точки входу.

Матеріал актуальний станом на 21 жовтня 2026 року. Офіційне повідомлення з повним технічним описом — на сайті php.net.

Потрібна допомога?

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