PHP2Shell: критичні вразливості PHP і план захисту сайту

PHP2Shell: що вже підтверджено

PHP2Shell — назва дослідження критичних помилок у PHP, які можуть дозволити віддалене виконання коду. Для власника WordPress це привід перевірити серверне середовище сьогодні: звичайне оновлення теми або плагінів не змінює інтерпретатор, який виконує сайт.

Приводом для цього розбору стала новина DOU від 21 жовтня. Відтоді зʼявилися докладні офіційні повідомлення. Тож формулювання «патчі очікуються» вже застаріло, а пояснення обох проблем лише через прогрес завантаження — неповне.

Команда PHP повідомила про дві критичні вразливості, CVE-2026-109618 та CVE-2026-109619, з оцінкою CVSS v4.0 9,2. Виправлення випущені для підтримуваних гілок. Це підтверджує офіційне повідомлення PHP, а не тільки публікації в медіа.

Дві CVE — два механізми пошкодження памʼяті

CVE-2026-109618: помилка під час обробки нестачі памʼяті, або OOM. Аварійне завершення може залишати внутрішні структури PHP в некоректному стані; подальше очищення запиту звертається до них. Автори офіційного повідомлення описують підтверджене віддалене виконання коду для mod_php ще до запуску застосунку. Поведінка PHP-FPM відрізняється, тому не можна переносити один сценарій на всі сервери. Першоджерело: advisory CVE-2026-109618.

CVE-2026-109619: глобальний стан робочого процесу може зберігати посилання на вже звільнену памʼять попереднього запиту. Наступний запит використовує це застаріле посилання. Серед підтверджених шляхів — механізм прогресу завантаження файлів і обробка fatal-error backtrace у PHP 8.5. Конкретні умови залежать від способу запуску PHP та застосунку. Першоджерело: advisory CVE-2026-109619.

Практичний висновок редакції: перевіряти потрібно PHP, вебобробник і конфігурацію разом. Позначка «WordPress оновлено» відповідає на інше питання й не закриває цю перевірку.

Чому це стосується WordPress навіть без форми завантаження

PHP може обробляти дані запиту раніше, ніж почне працювати код сайту. Документація Session Upload Progress прямо пояснює: інформація про прогрес записується до виконання скриптів. Відсутність кнопки «Завантажити файл» на сторінці сама по собі не вимикає цей механізм.

Параметр session.upload_progress.enabled типово увімкнений і має режим зміни INI_PERDIR. Це видно в таблиці налаштувань сесій PHP. Порада додати ini_set() у тему WordPress не є надійним виправленням серверної проблеми.

Wiz, учасник дослідження, повідомляє про демонстрації виконання коду на WordPress, Drupal та Joomla, а також про можливість розкриття памʼяті. За даними дослідників, принаймні одна проблема зачіпає версії від PHP 5.4. Це свідчення широкого потенційного впливу, але не доказ однакової експлуатованості кожної інсталяції. Звіт Wiz Research.

Для власника сайту питання до підтримки має звучати конкретно: «Який PHP обслуговує HTTP-запити цього домену і яким пакетом закриті обидві CVE?» Відповіді «у нас сучасний хостинг» або «антивірус нічого не знайшов» цього не підтверджують.

Які версії PHP містять виправлення

Джерела таблиці: повідомлення PHP та офіційний журнал змін. Це мінімальні виправлені релізи відповідних гілок, а не вимога переходити з будь-якої версії саме на 8.5.

На керованому хостингу потрібне підтвердження постачальника. У дистрибутивах виправлення іноді переносять у пакет зі старішим номером базового PHP; у такому випадку доказом служать повний номер пакета та повідомлення постачальника, яке охоплює обидві CVE.

Старі гілки потребують окремого плану міграції. Надання аварійного патча не означає поновлення їхньої повної підтримки. Статус гілки перевіряйте на сторінці Supported Versions.

Що дають тимчасові заходи — і де їхні межі

Вимкнення session.upload_progress.enabled перекриває підтверджений session-шлях CVE-2026-109619. Для PHP 8.5 вимкнення fatal_error_backtraces стосується іншого підтвердженого шляху. Це часткові заходи: налаштування мають діяти до обробки запиту, а всі робочі процеси потрібно перезапустити. Для PHP-FPM офіційний advisory застерігає від покладання на .user.ini. Умови та обмеження тимчасового захисту.

В OOM-advisory згадано memory_limit=-1 як обмежений обхід одного механізму. Але це не загальне виправлення: збої виділення памʼяті залишаються можливими. Ми не радимо безумовно прибирати ліміт на робочому хостингу — потрібно оцінити системні обмеження ресурсів. Пояснення команди PHP.

Блокування multipart/form-data перед PHP може тимчасово зменшити поверхню атаки, але ламає легітимні завантаження й не доводить усунення всіх шляхів. Плагін, що перевіряє запит уже всередині WordPress, не рівнозначний фільтру перед інтерпретатором.

Cloudflare повідомляє про спостережені атаки й розгорнуті WAF-правила, зокрема для безплатного плану. Водночас компанія рекомендує оновлення PHP. Наявність DNS-запису в Cloudflare ще не доводить, що конкретний запит проходить через захист. Повідомлення Cloudflare.

План для власника сайту: від перевірки до доказу

Нижче — запропонований SEOWORK порядок робіт. Його мета — отримати перевірюваний результат і зберегти робочі функції сайту.

1. Зібрати перелік сервісів. Основний домен, піддомени, API, старі копії та окремі PHP-обробники. Для кожного вказати відповідального. Неперевірений сервіс залишати зі статусом «невідомо».
2. Зафіксувати фактичний runtime. У WordPress почати зі «Здоровʼя сайту → Інформація → Сервер». Консольний php -v перевіряє CLI і може показати іншу версію. Не залишати публічний phpinfo().
3. Підготувати відновлення. Перевірити дату резервної копії, доступ до неї та можливість відновлення на ізольованій копії. Призначити виконавця й критерії зупинки робіт.
4. Закрити непатчені середовища. Узгодити з хостингом підтримуваний виправлений пакет і перезапуск процесів. Якщо патч недоступний, окремо обрати тимчасові обмеження та описати їхній вплив.
5. Перевірити роботу після змін. Вхід, редагування, медіатека, форми, потрібні імпорти, API та фонові завдання. Для тестових повідомлень і замовлень заздалегідь визначити безпечний тестовий режим.
6. Переглянути історію. Зіставити журнали, зміни файлів і адміністративних облікових записів. Патч закриває вразливість, але сам по собі не встановлює, що було до нього.

У підсумковому записі потрібні дата, домен, вебверсія PHP, підтвердження пакета, результат перевірок і відкриті питання. Таке підтвердження корисніше за загальний напис «сайт захищено». Інші практичні матеріали зібрані в розділі кібербезпеки SEOWORK.

Повідомлення про проблеми після релізу: як їх читати

У коментарях до новини є твердження про проблеми навіть після 8.5.12. Це причина перевіряти першоджерела, а не автоматично оголошувати патч марним. У трекері PHP окремо описана регресія SimpleXML/GC у 8.4.27 та 8.5.12. Сам факт падіння процесу не є доказом універсального обходу виправлень обох CVE. PHP issue #24488.

Практична рекомендація SEOWORK: для сайтів з XML-імпортами додати перевірку саме цих сценаріїв і стежити за наступними виправленнями постачальника. При збої не повертати вразливу версію у відкритий інтернет без окремого захисту.

Закриття вразливостей сайту — послуга SEOWORK

Побачили новину про критичну вразливість і не знаєте, чи стосується вона вашого сайту? SEOWORK допоможе встановити реальний ризик, виконати погоджені виправлення та перевірити результат. Послуга для власників WordPress-сайтів, інтернет-магазинів і PHP-застосунків, яким потрібна технічна допомога з такими проблемами, як PHP2Shell.

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

Вартість і строк — після уточнення стану сайту. На обсяг впливають кількість сайтів, хостинг, сумісність компонентів і потреба у відновленні. Роботи починаємо після погодження. За потреби окремо узгодимо регулярні перевірки та оновлення.

Щоб почати, надішліть адресу сайту, назву хостингу та короткий опис проблеми. Паролі у першому зверненні не потрібні — спосіб надання доступу погодимо окремо.

Обговорити захист мого сайту

Поширені запитання