PHP випустила екстрені виправлення вразливостей php2shell, дані про які витекли заздалегідь
Команда PHP випустила версії 8.5.12, 8.4.27, 8.3.36 і 8.2.35, які усувають дві критичні вразливості віддаленого виконання коду без автентифікації. Відомості про них потрапили в мережу за день до релізу, тому розробники закликають оновитися негайно.
Головне
PHP 8.5.12, 8.4.27, 8.3.36 і 8.2.35 усувають CVE-2026-109618 та CVE-2026-109619 — вразливості віддаленого виконання коду без автентифікації.
Під загрозою всі інсталяції PHP, що обслуговують вебзапити; найвищий ризик — для Apache з mod_php.
Для PHP 7.4, 8.0 і 8.1 є лише мінімальні бекпорти вихідного коду, для старіших версій виправлень немає.
Тимчасові налаштування звужують окремі вектори атаки, але не замінюють оновлення.
PHP — одна з найпоширеніших мов серверного програмування. На ній працюють системи керування вмістом WordPress, Drupal і Joomla, інтернет-магазини на Magento, панелі керування хостингом і чимало корпоративного програмного забезпечення, яке взагалі не афішує, що використовує PHP.
У бюлетені безпеки, опублікованому 21 жовтня, розробники наголошують: ризик стосується всіх інсталяцій PHP, що обслуговують вебзапити, — PHP-FPM, Apache з mod_php, php-cgi, FrankenPHP і LiteSpeed. Найвищим його вважають для mod_php: для цієї конфігурації вже продемонстровано експлойт, у якому запит без автентифікації запускає атаку ще до виконання будь-якого коду застосунку. Обидві вразливості мають оцінку 9,2 за шкалою CVSS v4.0.
У чому суть вразливостей
CVE-2026-109618 повʼязана з обробкою нестачі памʼяті. Така помилка може перервати роботу PHP у момент, коли внутрішні дані запиту ініціалізовано лише частково, а під час очищення ці некоректні дані сприймаються як валідні.
CVE-2026-109619 стосується залишкового глобального стану. Внутрішній стан запиту може зберігатися після звільнення памʼяті, яку він займав, і наступний запит у тому самому робочому процесі здатен скористатися ним раніше, ніж стан буде скинуто.
Ситуація з PHP призведе до цілої лавини інцидентів — це одна з найбільших вразливостей за останні роки
Кевін Бомонт, дослідник кібербезпеки
Національний центр кібербезпеки Великої Британії (NCSC) закликав організації негайно оновити PHP, а системи, які не вдається оновити одразу, розглянути можливість відключити від мережі.
Як оновитися
Виправлені версії — PHP 8.5.12, 8.4.27, 8.3.36 і 8.2.35 — доступні на сторінці завантажень php.net. Розробники Linux-дистрибутивів і LTS-постачальники отримали патчі заздалегідь, тож оновлені пакети варто шукати в репозиторіях дистрибутива. Власникам сайтів на хостингу слід уточнити в провайдера, чи оновлено PHP на серверах.
Тим, хто встановлює PHP з волонтерського репозиторію rpms.remirepo.net, розробники радять перейти на пакети дистрибутива або зібрати PHP з вихідного коду: у день релізу оновлень у цьому репозиторії не буде.
PHP 8.1 і старіші версії офіційних оновлень від проєкту більше не отримують. Частина дистрибутивів і LTS-постачальників пропонує власні бекпорти виправлень. Крім того, через серйозність вразливостей команда безпеки PHP підготувала мінімальні бекпорти вихідного коду для PHP 7.4, 8.0 і 8.1 — для тих, хто збирає PHP самостійно. Для PHP 5 і гілок 7.0–7.3 виправлень немає: такі системи потрібно оновити до підтримуваної версії або ізолювати від інтернету.
Варто також врахувати, що підтримка PHP 8.2 завершується 31 грудня 2026 року — після цієї дати виправлень безпеки для неї не буде.
Якщо оновитися негайно неможливо
Розробники описали тимчасові заходи, але попереджають: вони лише звужують окремі шляхи атаки й не роблять систему безпечною. Повноцінний захист дає тільки оновлення.
Для CVE-2026-109618 рекомендовано:
встановити memory_limit=-1 так, щоб застосунки не могли змінити значення, — наприклад, через php_admin_value у конфігурації FPM-пулу або Apache;
знизити post_max_size: до 8 МБ для застосунків без завантаження файлів і до 32 МБ, якщо завантаження потрібні; upload_max_filesize має бути меншим за post_max_size;
обмежити розмір і складність запитів на рівні вебсервера або проксі.
Для CVE-2026-109619 рекомендовано:
вимкнути upload_progress.enabled у php.ini, конфігурації FPM-пулу чи сервера (не через ini_set() і не через .user.ini) та перезапустити всі робочі процеси;
на PHP 8.5 — додатково встановити fatal_error_backtraces=0 і перезапустити робочі процеси.
Сайти, що працюють через Cloudflare, отримали додатковий рубіж захисту. За словами технічного директора компанії Дейна Кнехта, якого цитує Help Net Security, Cloudflare уже розгорнула правила WAF для відомих векторів атаки на ці вразливості, і вони доступні всім клієнтам, зокрема на безплатному тарифі.
Як стався витік
20 жовтня на форумі Hacker News зʼявився допис про дві критичні вразливості в PHP, які нібито мали розкрити 22 жовтня. Допис швидко видалили, але знімки екрана встигли поширитися соцмережами. Невдовзі дослідники компанії watchTowr підтвердили BleepingComputer, що вразливості справжні.
За останню годину стався витік інформації про дві вразливості віддаленого виконання коду в PHP. Їх мали розкрити після завершення ембарго — у четвер об 11:00 за північноамериканським східним часом
Бенджамін Гарріс, генеральний директор watchTowr
Про витік watchTowr попередила і у дописі в X, назвавши їх вразливостями нульового дня, що перебували під ембарго. Після цього команда PHP опублікувала попереднє оголошення та призначила реліз на день раніше від початкової дати. Серед дослідників вразливості отримали неофіційну назву php2shell.
Неофіційні джерела оцінювали вразливості в максимальні 10 балів за CVSS. Остаточна офіційна оцінка розробників — 9,2 за CVSS v4.0.
Що ще варто зробити адміністраторам
Оновлення закриває вразливості, але не усуває наслідків можливого злому, якщо його вже скоїли. Huntress радить:
Скласти перелік усіх інсталяцій PHP — не лише на вебсерверах, а й у неочевидних місцях: у програмному забезпеченні постачальників із вбудованими php.exe чи php-cgi.exe, у панелях керування cPanel і Plesk, на сайтах з WordPress, Drupal, Joomla або Magento.
Після оновлення переконатися, що кожен сервер справді перейшов на нову версію, і перезапустити всі робочі процеси PHP.
Стежити за процесами, які запускає PHP. Насторожити має ситуація, коли php-fpm, php-cgi чи apache2 запускає командні оболонки, інтерпретатори або утиліти на кшталт curl і wget. Для Linux-серверів без засобів виявлення загроз дослідник Флоріан Рот підготував безплатний інструмент process-watcher.
У разі підозри на злам — ізолювати сервер, зберегти журнали вебсервера та PHP, перевірити наявність вебшелів, нових файлів у кореневому каталозі сайту, нових завдань cron і облікових записів.
Ця стаття PHP випустила екстрені виправлення вразливостей php2shell, дані про які витекли заздалегідь раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня
