У PHP усунули дві критичні вразливості: перевірте оновлення

21 жовтня 2026 року розробники PHP випустили виправлення двох критичних вразливостей: CVE-2026-109618 і CVE-2026-109619. Обидві можуть дозволити зловмиснику виконати код на сервері без авторизації. Ці вразливості відомі під спільною назвою PHP2Shell.

Виправлення доступні в PHP 8.2.35, 8.3.36, 8.4.27 і 8.5.12. Команда PHP рекомендує встановити оновлення негайно. Перевірити потрібно й старі гілки, зокрема PHP 5.6: вони також уразливі.

Чим небезпечні ці вразливості

Проблема в самому PHP, який виконує код сайту. Тому оновити WordPress, інший рушій або плагіни недостатньо. Обидві вразливості отримали оцінку 9,2 за шкалою CVSS v4.0 і пов’язані з помилками керування пам’яттю.

• CVE-2026-109618: під час обробки нестачі пам’яті запит може перерватися до завершення підготовки внутрішніх даних PHP. Подальше очищення може некоректно звернутися до пам’яті.
• CVE-2026-109619: внутрішній стан може зберегтися після звільнення пам’яті. Наступний запит у тому самому робочому процесі може використати вже недійсні дані.

Перевірити оновлення потрібно для PHP-FPM, Apache з mod_php, php-cgi, FrankenPHP і LiteSpeed. Розробники вважають конфігурацію з mod_php найризикованішою: для неї продемонстровано атаку одним запитом без авторизації, до виконання коду застосунку.

Дослідники Wiz продемонстрували також читання пам’яті процесу PHP без досягнення віддаленого виконання коду. У пам’яті можуть бути паролі, токени та ключі API. Отже, ризик не обмежується зміною файлів сайту.

Nginx із PHP-FPM також потребує оновлення. Дослідники Calif опублікували демонстрацію атаки на таку конфігурацію. Серед перевірених ними застосунків є WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony і WHMCS. Це результати дослідницьких демонстрацій, а не список зламаних сервісів.

До якої версії оновити PHP

Якщо PHP встановлено з пакетів Linux, постачальник може перенести виправлення до попередньої версії без зміни її основного номера. Перевіряйте повну версію пакета й бюлетень постачальника: самого позначення «PHP 8.3» недостатньо. Рекомендації CERT-EU.

Що робити, якщо сайт працює на PHP 5.6, 7.x, 8.0 або 8.1

Старі гілки також уразливі. Їхня офіційна підтримка проєктом PHP завершена, але виправлення можуть надавати дистрибутиви, сторонні репозиторії та постачальники розширеної підтримки.

• PHP із репозиторію Sury, зокрема PHP 5.6. Ondřej Surý повідомив, що виправлення обох CVE мають отримати всі версії PHP у його репозиторії для всіх підтримуваних ним випусків Debian та Ubuntu. Спочатку будуть доступні пакети amd64, потім ARM у міру збирання; строків не названо. Перевірте наявність виправленого пакета для своєї гілки PHP, ОС та архітектури. Це повідомлення стосується пакетів Sury, а не всіх установок PHP 5.6. Коментар супроводжувача Sury PHP.
• Пакети дистрибутива або постачальника розширеної підтримки. Знайдіть його бюлетень безпеки та встановіть рекомендовану збірку.
• PHP із вихідного коду. Для PHP 7.4, 8.0 і 8.1 команда PHP опублікувала мінімальні виправлення. Для інших старих гілок наявність відповідного патча потрібно уточнювати окремо.
• PHP через панель хостингу. Запитайте провайдера, чи виправлена версія PHP, яку використовує сайт, і чи потрібні дії з вашого боку.

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

Оновлення PHP в Ubuntu, Debian та AlmaLinux

Статус перевірено 21 жовтня 2026 року. Для офіційних репозиторіїв Ubuntu та Debian підтверджено такі виправлені версії пакетів:

Номери в таблиці стосуються офіційних пакетів відповідного дистрибутива. Для Sury та інших сторонніх репозиторіїв перевіряйте їхні власні версії. Виправлення може бути перенесене до старого PHP без зміни його основного номера. Ubuntu USN-8948-1.

Canonical випустила виправлення обох CVE для зазначених версій Ubuntu. У Debian для Trixie опубліковано бюлетень DSA-6574-1, а для Bookworm виправлену версію вже позначено в security tracker. Перевірте доступність пакета на своєму дзеркалі та для потрібної архітектури. Debian Security Tracker.

AlmaLinux: за офіційним повідомленням пакети готуються для підтримуваних потоків AlmaLinux 8, 9 і 10: спочатку testing, потім production після перевірки. Підтвердження випуску до стабільних репозиторіїв поки немає. Це статус власних пакетів AlmaLinux, а не PHP зі сторонніх репозиторіїв. Повідомлення AlmaLinux.

Перша хвиля охоплює PHP 7.4 і 8.2 в AlmaLinux 8; PHP 8.0, 8.2 і 8.3 в AlmaLinux 9; PHP 8.3 і 8.4 в AlmaLinux 10. Застарілі потоки PHP 7.2, 7.3 і 8.0 в AlmaLinux 8 та PHP 8.1 в AlmaLinux 9 до першої хвилі не входять.

Оновлення PHP у панелях керування та CloudLinux

Статус перевірено 21 жовтня 2026 року. Випуск виправлень триває: доступність пакета залежить від гілки PHP, ОС і репозиторію.

cPanel. Представник cPanel повідомив про випуск виправлень для ea-php74, ea-php80, ea-php81, ea-php82, ea-php83, ea-php84 і ea-php85. Серед них є застарілі гілки 7.4, 8.0 і 8.1. Перевіряйте оновлення всіх використовуваних ea-php, а не лише версію панелі. Повідомлення cPanel.

Plesk. На офіційному форумі співробітник повідомив, що збірки з виправленнями для PHP 7.4, 8.0 і 8.1 завершені та проходять тестування. Це ще не підтвердження доступності кожного пакета. Перевіряйте потрібну гілку й платформу окремо; готовність Linux-збірки не підтверджує готовність Windows-збірки. Відповідь співробітника Plesk.

FASTPANEL. На момент перевірки окремого офіційного бюлетеня про PHP2Shell і списку виправлених збірок знайти не вдалося. Наявність версії PHP у панелі не підтверджує наявність патча: перевірте встановлений пакет і репозиторій або зверніться до підтримки по підтвердження.

DirectAdmin. PHP сайтів зазвичай збирається через CustomBuild. Тому оновлення пакетів ОС може бути недостатньо. Перевірте доступні версії в CustomBuild → Updates або командою da build versions; файл custom_versions.txt може утримувати стару версію. На момент перевірки повного підтвердженого розробником переліку виправлень, особливо для старих гілок, знайти не вдалося. Інструкції користувачів на форумі з ручною заміною номерів версій не рівнозначні офіційному випуску.

ispmanager. Системний PHP надходить із репозиторію ОС, альтернативні версії встановлюються з репозиторію ispmanager до /opt/. Перевіряйте обидва джерела: оновлення системного PHP не підтверджує виправлення альтернативних обробників сайтів. На момент перевірки окремого офіційного бюлетеня щодо цих CVE та списку виправлених збірок знайти не вдалося. Це відсутність підтвердження, а не доказ відсутності патчів.

CloudLinux. Заявлено патчі для alt-php 5.2–8.5; частину збірок, зокрема alt-php74, вже випущено. Перевіряйте свою ОС і гілку. Imunify360 ruleset 8.83 доступний у Stable за ввімкненого WAF, але не замінює оновлення PHP. Статус випуску CloudLinux.

На одному сервері можуть одночасно працювати PHP самої панелі, системний PHP, ea-php та alt-php. Оновлення одного набору пакетів не підтверджує виправлення решти. Після встановлення оновлень перезапустіть відповідні процеси й перевірте, який обробник використовує кожен сайт.

Чому проблема стосується стількох сайтів

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

На PHP працюють WordPress, Drupal, Joomla та MediaWiki. Його використовують і для власних застосунків, зокрема на Laravel. Тому перевірка потрібна й сайтам без готового рушія. Про відмінності систем керування сайтом читайте в огляді CMS.

Вікіпедія використовує MediaWiki, а NASA, NASA Science та WhiteHouse.gov використовують WordPress. 21 жовтня Wikimedia Foundation повідомила, що тимчасово вимкнула низку допоміжних сервісів, зокрема Toolforge та Cloud VPS, до безпечного оновлення. Водночас команда намагалася уникнути простою самих вікі. Це запобіжне обмеження, а не повідомлення про злам.

Рушій сайту та PHP оновлюються окремо. Актуальний WordPress зі свіжими плагінами може працювати на PHP без потрібного виправлення. У разі атаки до запуску застосунку перевірки всередині рушія ще не встигають виконатися.

Як перевірити, що сайт отримав виправлення

На хостингу почніть із запитання до підтримки: «Чи встановлені для PHP мого сайту виправлення CVE-2026-109618 і CVE-2026-109619?» Якщо сервер обслуговуєте ви або ваш адміністратор:

1. Перевірте всі версії PHP, які обробляють вебзапити. На одному сервері різні сайти можуть використовувати різні гілки.
2. Встановіть виправлені пакети та перезапустіть відповідні процеси PHP.
3. Переконайтеся, що сайт використовує оновлену збірку. Версія PHP у командному рядку може відрізнятися від версії сайту.
4. Перевірте сторінки, авторизацію, форми та завантаження файлів.

Чи можна тимчасово захиститися налаштуваннями

Повністю усунути проблему дозволяє лише оновлення. Тимчасові налаштування, описані розробниками, обмежують окремі способи атаки, але не усувають обидві вразливості. Якщо швидко встановити виправлення неможливо, CERT-EU рекомендує розглянути тимчасове обмеження публічного доступу до вразливих застосунків. Технічні заходи для адміністраторів наведено в бюлетені CERT-EU, посилання на який є вище.