Дві критичні вразливості PHP можуть призвести до RCE: що відомо зараз

21 жовтня 2026 року команда безпеки PHP опублікувала повідомлення про дві критичні вразливості: CVE-2026-109618 і CVE-2026-109619.

Обидві можуть призвести до віддаленого виконання коду без авторизації (RCE).

Це не вразливість Laravel, Symfony або окремого пакета Composer. Проблема знаходиться нижче - у самому середовищі виконання PHP, яке обробляє HTTP-запити.

Команда безпеки PHP прямо вказує, що обидві вразливості можуть дозволити віддалене виконання коду без авторизації.

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

Найвищим команда PHP вважає ризик для mod_php, де продемонстровано сценарій, за якого неавторизований запит може запустити атаку ще до виконання коду застосунку.

Для Laravel-проєктів це особливо важливо, тому що типовий продакт стек часто використовує Nginx + PHP-FPM.

Наявність Nginx перед PHP не усуває вразливість самого PHP. Якщо запит доходить до PHP-FPM, уразливий шлях виконання все ще може бути доступним.

PHP може перервати виконання в момент, коли внутрішні дані запиту ще лише частково ініціалізовані.

Після цього логіка очищення може сприйняти некоректний стан як валідний. Таке пошкодження внутрішнього стану створює шлях до віддаленого виконання коду.

Друга вразливість пов’язана з внутрішнім станом одного запиту, який може зберегтися після звільнення пам’яті, що його підтримувала.

Наступний запит, оброблений тим самим робочим процесом (worker), може використати цей застарілий стан до того, як звичайна ініціалізація повністю його скине.

Тому межа проблеми тут проходить ще й між послідовними запитами всередині довгоживучого процесу PHP.

Вхід у систему, перевірка прав, API-токени та middleware працюють уже на рівні застосунку.

Вразливість PHP, яка не потребує авторизації, може спрацювати під час або ще до звичайної обробки запиту застосунком. Тому твердження "маршрут захищений автентифікацією" і "сам PHP не доступний для атаки" - це не одне й те саме.

Composer керує залежностями застосунку в vendor/. CVE-2026-109618 і CVE-2026-109619 знаходяться в самому PHP.

Тому проєкт може мати актуальні пакети й чисту перевірку залежностей, але все одно працювати на вразливій версії PHP.

Команда PHP випустила 8.2.35, 8.3.36, 8.4.27 і 8.5.12 із виправленнями обох вразливостей.

PHP 8.1 і старіші гілки більше не отримують звичайні оновлення безпеки від самого проєкту PHP. Водночас окремі дистрибутиви Linux і постачальники довгострокової підтримки можуть переносити виправлення у свої старіші пакети (backport).

Тому для пакета з репозиторію дистрибутива одного php -v іноді недостатньо: потрібно враховувати, чи додав постачальник виправлення без зміни номера версії до номера офіційного випуску PHP.

PHP-FPM на продакт сервері, CLI для cron і обробників черги, сервер розробки, Docker-контейнери, образи CI та локальний інтерпретатор можуть використовувати різні версії PHP.

Тому ця вразливість ще й про інвентаризацію: оновлений PHP на локальному комп’ютері не доводить, що PHP-FPM на сервері або старий Docker-образ теж уже безпечні.

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

Повідомлення про вразливість описує можливий сценарій атаки. Воно не доводить, що конкретний сервер уже був скомпрометований.

Так само відсутність очевидних помилок у журналах не доводить, що вразлива версія PHP безпечна.

Оцінка наявності вразливості та розслідування можливого інциденту - це дві різні задачі, і їх не варто змішувати без доказів.

Офіційне повідомлення команди безпеки PHP від 21 жовтня 2026 року:

Критичні вразливості з можливістю віддаленого виконання коду

У цьому матеріалі я свідомо не додаю команди й покрокове оновлення.

Наступне питання практичне: які версії PHP реально працюють на продакт сервері, сервері розробки, у Docker і локально, як врахувати виправлення від постачальника Linux-пакетів і як перевірити застосунок після оновлення PHP.

Головний висновок зараз: CVE-2026-109618 і CVE-2026-109619 знаходяться на рівні самого PHP, можуть призвести до віддаленого виконання коду без авторизації та стосуються встановлень PHP, що обслуговують вебзапити.