Дві критичні діри в PHP: як вони працюють, чому довгоживучі воркери під ударом і де після оновлення ще крутиться стара версія

Критичні вразливості в самому PHP трапляються рідко. Зазвичай небезпека живе в застосунку: SQL-ін'єкція, завантаження файлу, забутий {!! !!}. Цього разу проблема в інтерпретаторі, тобто в тому, що виконує будь-який PHP-код на сервері, а не в коді розробника. Тому 21 жовтня 2026 року команда PHP опублікувала пораду безпеки із закликом оновитися негайно, і виправлення вийшли для всіх підтримуваних гілок: 8.5.12, 8.4.27, 8.3.36 і 8.2.35.

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

Дві помилки, один наслідок

Обидві вразливості можуть дати неавтентифікованому нападнику віддалене виконання коду, обидві оцінені в 9.2 за CVSS v4.0. Спільне в них те, що йдеться про життєвий цикл запиту всередині PHP: як інтерпретатор готує внутрішній стан на початку запиту і прибирає його наприкінці.

CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) стосується нестачі памʼяті. Якщо PHP не вдається виділити памʼять у невдалий момент, обробка цієї помилки може перервати роботу, коли внутрішні дані запиту ініціалізовані лише частково. Очищення після запиту потім сприймає недобудовані дані як нормальні, а працювати з некоректними структурами це вже шлях до виконання чужого коду.

CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) про застарілий стан. Внутрішні дані, що належать запиту, можуть пережити звільнення памʼяті, на яку посилаються. Наступний запит у тому самому воркері здатен скористатися цим залишком раніше, ніж звичайна ініціалізація його скине.

Друга помилка пояснює, чому в пораді наголошено на воркерах. Якщо один і той самий процес обслуговує багато запитів поспіль, а так працюють PHP-FPM, Octane і FrankenPHP у worker-режимі, шкідливий запит може підготувати ґрунт для наступного, і між ними є вікно, у якому стан ще не чистий.

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

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

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

Старі гілки

Дистрибутиви й LTS-вендори отримали патчі заздалегідь, тож перша дія для серверних пакетів полягає в перевірці оновлень свого вендора. PHP 8.1 і старші офіційних оновлень не отримують. Для тих, хто збирає з вихідного коду або не має LTS-постачальника, команда безпеки PHP виклала мінімальні бекпорти для 7.4, 8.0 і 8.1 в окремих гілках репозиторію php-src. PHP 8.2 дійде до кінця підтримки 31 грудня 2026 року, тож перехід на новішу гілку варто закласти в плани вже зараз.

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

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

Проти CVE-2026-109618:

• виставити memory_limit=-1, бажано так, щоб застосунок не міг його змінити, наприклад через php_admin_value у конфігурації FPM-пулу чи Apache. Потім перевірити, що жоден пул, каталог чи застосунок не повертає скінченний ліміт. Це прибирає керований збій через ліміт памʼяті PHP, але справжня помилка виділення памʼяті все одно може дійти до вразливого місця;
• задати малий post_max_size: 8M для застосунків без завантаження файлів і 32M, якщо файли потрібні, а upload_max_filesize тримати нижчим. Радять також обмежити на рівні вебсервера чи проксі розмір розкодованого запиту, кількість полів, частин multipart і заголовків та глибину вкладення. Ліміти мають діяти й на запити без придатного Content-Length;
• використати ліміт контейнера чи cgroup як межу доступності, бажано з політикою, що вбиває лише постраждалий воркер. RLIMIT_AS і RLIMIT_DATA не підходять, бо самі можуть спричинити вразливий збій виділення памʼяті.

Проти CVE-2026-109619:

• вимкнути session.upload_progress.enabled=0 у php.ini, конфігурації FPM-пулу чи сервера, які діють до розбору запиту, і перезапустити всі воркери. ini_set() і .user.ini не допоможуть. Це закриває підтверджені шляхи через сесії, але не інші варіанти;
• на PHP 8.5 виставити fatal_error_backtraces=0 і перезапустити воркери. Це блокує лише підтверджений шлях через зворотне трасування фатальних помилок;
• прибрати некоректні або застарілі налаштування, які застосовуються під час запиту й виводять діагностику до ініціалізації. Приховування діагностики через error_reporting, display_errors чи @ не допомагає;
• виправити фатальні помилки й перевищення часу виконання, які можна викликати ззовні, зокрема в колбеках, обробці завантажень та імпорту.

Де стара версія лишається працювати

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

PHP-FPM. Після оновлення пакета сервіс треба перезапустити, наприклад systemctl restart php8.4-fpm. Воркери, що вже працюють, тримають стару версію в памʼяті. Якщо на сервері кілька версій PHP, перевірте кожну, бо оновлення однієї не торкається інших.

Docker. docker build бере базовий образ із локального кешу й нову версію не підтягує, поки його не попросять: docker compose build --pull. Фраза «образ перезібрано» нічого не гарантує, якщо шар з PHP лишився кешованим. Образи з тегами на кшталт 1-php8.4 оновлюються, коли виходить нова версія, але не в ту саму хвилину, тож варто перевірити, яку версію PHP образ насправді містить.

Octane, FrankenPHP у worker-режимі, черги. Довгоживучі процеси самі нову версію не підхоплять. Їх треба перезапустити: php artisan octane:restart, queue:restart, Horizon. Друга вразливість стосується стану, який може пережити запит у тому самому воркері, тож перезапуск після оновлення тут особливо важливий. Воркери черг HTTP-запитів не обробляють, але їх теж слід перезапустити, щоб вони працювали на новому PHP.

CLI проти веб. php -v у терміналі показує версію CLI, а запити може обробляти інша. Перевіряти треба ту, що відповідає на HTTP, наприклад командою всередині контейнера веб-процесу:

docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

Якщо числа в різних місцях не збігаються, у системі лишилося дві інсталяції, і одна з них, імовірно, стара.

Така перевірка все ж іде через CLI, а не через вебсервер. Остаточну відповідь дає запит до самого застосунку: тимчасовий закритий маршрут (за авторизацією або з секретним токеном), який повертає PHP_VERSION, і який після перевірки треба видалити. Залишена публічно сторінка з версією PHP допомагає лише нападникові.

Порядок дій

1. Зробіть знімок сервера або бекап бази.
2. Оновіть PHP до виправленої версії або перезберіть образ з --pull, щойно вона стане доступною для вашого дистрибутива чи образу.
3. Перезапустіть усе, що тримає PHP: FPM, вебсервер, воркери черг, Octane.
4. Переконайтеся, що веб-процес віддає виправлену версію.
5. Поки оновитися не можна, застосуйте тимчасові заходи з розділу вище.
6. Огляньте сервер на ознаки компрометації: незнайомі файли у веб-теках, нові завдання cron, незвичне навантаження чи вихідний трафік.

Першоджерела: оголошення на php.net, GHSA-w8hw-w9fx-j79w і GHSA-6wmf-4rv5-p3rp.