21 жовтня 2026 року команда PHP випустила термінові оновлення 8.5.12, 8.4.27, 8.3.36 і 8.2.35. Вони закривають дві критичні вразливості з оцінкою 9,2 за CVSS v4.0, які дозволяють віддалено виконати код без авторизації. У пресі пара отримала назву PHP2Shell. Офіційна рекомендація однозначна: оновитися негайно, бо повноцінного обхідного шляху немає.

Ситуацію ускладнює те, що спробу експлуатації зафіксували ще 17 жовтня – за чотири дні до публічного розкриття. Британський NCSC радить подумати про те, щоб тимчасово вимкнути системи, які неможливо оновити одразу. Якщо ваш сайт працює на PHP – а це більшість сайтів на WordPress, Laravel та інших популярних рушіях, – ця стаття про вас.

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

CVE-2026-109618: виконання коду через пошкодження пам’яті при out-of-memory

Коли PHP вичерпує ліміт пам’яті, він аварійно перериває обробку запиту. Проблема в тому, що це може статися в момент, коли внутрішні дані запиту ініціалізовані лише частково, – і код очищення потім працює з ними як з коректними. Атакувальник може навмисно спровокувати нестачу пам’яті спеціально сформованим multipart-запитом (тим самим форматом, яким надсилаються форми з файлами): величезною кількістю заголовків в одній частині, порожніми полями файлів, глибоко вкладеними іменами полів.

Для Apache з mod_php повне виконання коду через HTTP підтверджено на стандартних налаштуваннях. Для PHP-FPM аналіз коду показує вразливість, хоча повного робочого експлойту не продемонстровано.

CVE-2026-109619: «застарілий» стан між запитами

Робочий процес PHP обслуговує запит за запитом. Друга вразливість полягає в тому, що частина внутрішнього стану може пережити свій запит і вказувати на пам’ять, яку вже звільнено. Якщо наступний запит, що потрапив у той самий процес, звернеться до цього стану раніше, ніж він скинеться, – виникає використання звільненої пам’яті, яке можна довести до виконання коду.

Один із підтверджених шляхів – session upload progress, механізм відстеження прогресу завантаження файлів. Він увімкнений за замовчуванням і працює навіть тоді, коли застосунок не викликає session_start(). Цей шлях підтверджено і для mod_php, і для PHP-FPM.

Кого це стосується

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

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

  • PHP 8.2–8.5 – оновіться до 8.2.35, 8.3.36, 8.4.27 або 8.5.12 відповідно.
  • PHP 8.1 і старіші – офіційних релізів не буде. Команда PHP виклала мінімальні патчі вихідного коду для 7.4, 8.0 і 8.1 для тих, хто збирає PHP самостійно, а деякі дистрибутиви й постачальники розширеної підтримки випускають власні виправлення. Але правильна відповідь – перехід на підтримувану версію.

Як виправити: крок за кроком

1. З’ясуйте, яка версія реально обслуговує сайт

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

php -v
php-fpm8.4 -v
ls /etc/php/
systemctl list-units 'php*-fpm*'

Під час нещодавнього аудиту ми знайшли на сервері зайвий PHP 8.3, яким ніщо не користувалося, але його процеси були запущені. Невикористана версія – це та сама вразливість, тільки без жодної користі. Її краще видалити.

2. Оновіть пакети

На Ubuntu/Debian з репозиторієм Ondřej Surý:

sudo apt update
sudo apt install --only-upgrade 'php8.4-*'

Якщо PHP встановлено з офіційних репозиторіїв дистрибутива, ставте його оновлення безпеки. Номер версії при цьому може лишитися «старим», бо дистрибутиви переносять виправлення у свої пакети. Перевірити можна в changelog пакета; якщо ідентифікаторів CVE там немає, уточніть статус у постачальника – деякі з них не згадують CVE у changelog.

У Docker недостатньо перезапустити контейнер: перезберіть образ на свіжій версії (наприклад, php:8.4.27-fpm) і задеплойте заново. На спільному хостингу перевірте версію в панелі керування або напишіть у підтримку.

3. Перезапустіть процеси PHP

Робочі процеси, запущені до оновлення, тримають у пам’яті старий код. Після встановлення пакетів обов’язково перезапустіть сервіси:

sudo systemctl restart php8.4-fpm
# або для Apache з mod_php
sudo systemctl restart apache2

4. Перевірте результат

php-fpm8.4 -v
systemctl show -p ActiveEnterTimestamp php8.4-fpm

Версія має бути виправленою, а час запуску сервісу – пізнішим за час оновлення.

Якщо оновитися прямо зараз неможливо

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

  • Вимкніть session upload progress: session.upload_progress.enabled=0 і перезапустіть процеси. Якщо ця функція вам не потрібна, advisory радить лишити її вимкненою і після оновлення.
  • Блокуйте multipart-запити там, де застосунок не приймає форми з файлами, і обмежте розмір запиту на рівні вебсервера.
  • Для PHP 8.5 – fatal_error_backtraces=0.
  • WAF: Cloudflare розгорнув правила для відомих векторів атаки, зокрема на безкоштовному тарифі.

Чому «PHP 7.4 працює ж» – більше не аргумент

Ця історія добре показує, чим закінчується робота на непідтримуваній версії. Виправлення отримують лише гілки з підтримкою безпеки:

Версія Підтримка безпеки до Статус
PHP 7.4 28.11.2022 не підтримується
PHP 8.0 26.11.2023 не підтримується
PHP 8.1 31.12.2025 не підтримується
PHP 8.2 31.12.2026 лише безпека, закінчується за два місяці
PHP 8.3 31.12.2027 лише безпека
PHP 8.4 31.12.2028 активна підтримка
PHP 8.5 31.12.2029 активна підтримка

Цього разу для старих гілок виклали патчі вихідного коду – але це виняток, а не правило, і зібрати PHP з патчем самостійно під силу далеко не кожному. Наступного разу такої «милості» може не бути.

Друга проблема – застарілі сервери. На Ubuntu 18.04, наприклад, PHP 8 уже не встановити зі стандартних репозиторіїв, тож перехід на нову версію означає переїзд на новий сервер. Саме так було в нашому випадку – про те, як зробити це без простою, ми розповіли в окремій статті: Переїзд сайту на новий сервер без простою.

Якщо ви плануєте перехід, ось короткий план:

  1. Оновіть WordPress, тему й плагіни до актуальних версій – більшість сумісності вже вирішено там.
  2. Перевірте власний код: php -l потрібної версії, а для глибшої перевірки – набір правил PHPCompatibility для PHP_CodeSniffer.
  3. Розгорніть копію сайту на новій версії PHP і пройдіть ключові сценарії: форми, оплату, адмінку.
  4. Перемикайте робочий сайт, лише коли копія працює без помилок у логах.
  5. Цільова версія – PHP 8.4: вона матиме підтримку безпеки до кінця 2028 року.

Потрібна допомога з оновленням PHP?

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

Обговорити оновлення

Джерела