Як усунути PHP2Shell

php.net висловлюється однозначно: «Повноцінних заходів захисту немає, оновлення — єдиний безпечний варіант». Цей посібник описує оновлення, перезапуск, про який часто забувають, перевірку і те, на що звернути увагу, якщо сервер був доступний для атак.

1 Знайдіть кожен PHP на сервері

На багатьох серверах працює більше одного PHP: системний пакет, версії, встановлені панеллю керування (cPanel EA-PHP, Plesk, CWP/CloudLinux alt-php, DirectAdmin), контейнери та збірки командного рядка, які використовує cron. Кожну версію, що обслуговує вебзапити, потрібно оновити.

Виконайте php -v, виведіть процеси php-fpm командою ps aux | grep php-fpm і перевірте селектор PHP у вашій панелі.

2 Оновіть до виправленої версії

Виправлені версії upstream: 8.5.12, 8.4.27, 8.3.36 і 8.2.35. Пакети дистрибутивів можуть містити виправлення під старішим номером версії — перевірте журнал змін на CVE-2026-109618 і CVE-2026-109619.

Для PHP 8.1 і старіших проєкт PHP випусків не робить. Для тих, хто збирає з вихідних кодів, опубліковано мінімальні бекпорти для 7.4, 8.0 і 8.1, але надійне рішення — перехід на підтримувану гілку.

Debian / Ubuntu (пакети дистрибутива)

Встановіть оновлення безпеки з вашого дистрибутива і перезапустіть PHP. Номер версії може не змінитися; CVE зазначено в журналі змін пакета.

sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart 'php*-fpm' apache2 2>/dev/null
apt changelog php8.3-fpm | grep -i -m3 CVE-2026-1096

RHEL / AlmaLinux / Rocky (dnf)

Встановіть виправлення (errata) постачальника для вашого потоку модуля PHP, потім виконайте перезапуск.

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm httpd
rpm -q --changelog php-common | grep -i -m3 CVE-2026-1096

Docker / офіційні образи php

Завантажте або перезберіть образ із виправленим тегом і пересоздайте контейнери.

docker pull php:8.3-fpm   # must report 8.3.36 or later
docker compose up -d --build --force-recreate
docker compose exec app php -v

cPanel, Plesk, CWP, DirectAdmin

Використайте засіб оновлення панелі для кожної встановленої версії PHP (EA-PHP, обробники PHP у Plesk, alt-php, CustomBuild), потім перезапустіть PHP-FPM. Панелі часто залишають старі версії для окремих сайтів — оновіть або видаліть і їх.

Віртуальний або керований хостинг

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

Windows / IIS

Завантажте виправлену збірку з windows.php.net, замініть каталог PHP і перезапустіть (recycle) пули застосунків IIS.

3 Перезапустіть усі процеси PHP

Встановлення пакета не змінює вже запущений код. Перезапустіть PHP-FPM, Apache (для mod_php), LiteSpeed, FrankenPHP, обробники черг і супервізори. Для контейнерів перезберіть або завантажте новий образ — перезапуск того самого образу виправлення не встановлює.

4 Перевірте

Виконайте php -v для кожного бінарного файлу і переконайтеся, що запущені процеси використовують нову збірку (наприклад, ls -l /proc/$(pgrep -o php-fpm)/exe не повинен показувати «deleted»). Потім запустіть цю перевірку ще раз.

5 Якщо оновитися сьогодні неможливо

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

6 Пошукайте ознаки компрометації — і змініть секрети

Якщо вразливий сайт був доступний з інтернету, перегляньте активність починаючи з 20 жовтня 2026 року: аварійні завершення робочих процесів PHP (SIGSEGV) у журналі помилок PHP-FPM або Apache, нові чи змінені PHP-файли в корені сайту, нові завдання cron, нові облікові записи адміністраторів і неочікувані вихідні з’єднання.

Оскільки CVE-2026-109619 може розкрити пам’ять процесу PHP без виконання жодного коду, чиста файлова система не доводить, що нічого не витекло. Для сайтів, які були доступні, змініть паролі баз даних, ключі API, облікові дані платіжних систем і пошти та анулюйте сесії користувачів.

7 Після оновлення

Виправлення запроваджує новий жорсткий ліміт пам’яті: процес, що його досягає, негайно завершується, а обробники завершення (shutdown handlers) не виконуються. Перевірте, як ваш застосунок поводиться за нестачі пам’яті, перегляньте memory_limit разом із post_max_size і max_input_nesting_level та скасуйте тимчасове налаштування memory_limit = -1, якщо ви задали його до встановлення виправлення. Приховування версії за допомогою expose_php = Off — необов’язковий захід посилення захисту, а не виправлення.

Часткові заходи захисту (за даними php.net і бюлетенів)

Вони лише звужують відомі шляхи атаки. php.net зазначає, що оновлення — єдиний безпечний варіант.

; php.ini / FPM pool (php_admin_value) — після цього перезапустіть усі робочі процеси
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; PHP 8.5
post_max_size = 8M                ; 32M якщо завантаження файлів потрібне
max_input_nesting_level = 16      ; default 64
display_errors = 0

; FPM pool
pm.max_requests = 200

Задавайте ці параметри в php.ini, у пулі PHP-FPM (php_admin_value) або в конфігурації сервера — не через ini_set() чи .user.ini — і перезапустіть робочі процеси. Додаткові заходи з бюлетенів і від дослідницької групи:

memory_limit = -1 блокує деякі шляхи, що спираються на власний ліміт пам’яті PHP, але передає вичерпання пам’яті операційній системі — використовуйте його лише разом з лімітом memory.max у cgroup v2. Не використовуйте RLIMIT_AS чи RLIMIT_DATA: вони можуть задіяти ті самі вразливі шляхи.
Знизьте max_input_nesting_level настільки, наскільки дозволяють ваші форми.
Зменште pm.max_requests у PHP-FPM, щоб робочі процеси перезапускалися частіше (ціною продуктивності).
Обмежте розмір запиту, кількість полів і глибину вкладеності на рівні вебсервера або проксі; видаліть некоректні або застарілі налаштування INI, що задаються для окремих запитів.
Політики SELinux або AppArmor можуть обмежити, що здатен запустити скомпрометований робочий процес, — вони зменшують шкоду, але не запобігають розкриттю пам’яті.

Джерела

Джерело: бюлетень безпеки php.net від 21 жовтня 2026 року. Остання перевірка: 2026-10-23.