PHP2Shell: що робити після CVE-2026-109618 і CVE-2026-109619

PHP2Shell: що робити на своєму сервері після CVE-2026-109618 і CVE-2026-109619

21 жовтня 2026 року команда PHP випустила екстрені оновлення для двох критичних вразливостей у ядрі мови: CVE-2026-109618 і CVE-2026-109619. Обидві мають оцінку 9.2 за CVSS v4.0, обидві дозволяють виконати код на сервері без автентифікації, і обидві зачіпають не окремий застосунок, а сам рушій PHP. Для цієї пари вразливостей уже закріпилася назва PHP2Shell.

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

У цій статті немає переказу новин. Є робочий порядок дій для тих, хто відповідає за VPS чи виділений сервер: як знайти весь PHP на машині (його там часто більше, ніж здається), як оновитися правильно, що робити, коли оновитися одразу неможливо, і як перевірити, чи вас уже не відвідали. Окремо розберемо контейнери, бо в Docker-стеках ця історія має свої нюанси.

2. Що відомо про вразливості

2.1 Дві вади, один результат

Дослідники по-різному розставляють акценти в описі механізму (одні пов'язують одну з вад з обробником upload progress у сесіях), але практичний висновок спільний: вразливість лежить у внутрішній обробці запитів PHP. Для експлуатації не потрібен вразливий плагін чи форма завантаження файлів у вашому застосунку. Атака йде по HTTP-запитах типу multipart/form-data, і за описом дослідників вона може спрацювати ще до того, як почне виконуватись код вашого сайту.

2.2 Що це означає для захисту застосунку

Звична відповідь «ми оновили WordPress і плагіни» тут не працює. Вразливий сам інтерпретатор, тому ні WAF-плагін всередині CMS, ні режим обслуговування не рятують: запит обробляється PHP раніше, ніж застосунок встигає його перевірити. Закрити проблему повністю можна лише оновленням PHP.

2.3 Яких конфігурацій це стосується

За даними аналітиків, зачеплені всі способи обробки веб-запитів: PHP-FPM, Apache з mod_php, php-cgi, FrankenPHP і LiteSpeed. Найвищим ризик названо для mod_php, оскільки там експлойт здатен спрацювати найраніше. Це не робить FPM безпечним: це лише порядок пріоритетів, коли часу на всі сервери одразу не вистачає.

2.4 Виправлені версії та ті, що лишились без патча

Для гілок 7.4, 8.0 і 8.1 проєкт опублікував мінімальні бекпорт-патчі у вигляді вихідного коду, які придатні тим, хто збирає PHP самостійно. Деякі дистрибутиви та постачальники довгострокової підтримки (CloudLinux, Ubuntu ESM та інші) випускають власні пакети з виправленням під старими номерами версій, тому для дистрибутивних пакетів не варто орієнтуватись лише на номер: перевіряйте примітки до пакета (changelog) вашого постачальника.

3. «У нас немає PHP»: чому ця відповідь потребує перевірки

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

3.1 Де PHP ховається найчастіше

• Адмінські інструменти. phpMyAdmin, Adminer, веб-клієнти пошти на кшталт Roundcube, панелі моніторингу, старі панелі керування хостингом.
• Біллінг і CRM. WHMCS та подібні системи, інвентарні системи (DCIM), форуми, внутрішні вікі.
• Старі сайти. «Тимчасова» лендінг-сторінка, піднята три роки тому й забута, але досі доступна із зовнішньої мережі.
• Контейнери. Образ, у якому PHP є лише як залежність одного зі скриптів чи інструментів збірки.
• Сторонні сервіси на вашому сервері. Чужі проєкти клієнтів чи підрядників, до яких адміністратор формально не причетний, але які працюють на тій самій машині.

3.2 Чому «перевірити лише читанням» правильно

Початковий етап не потребує жодних змін на сервері: версії, процеси, пакети, образи, логи. Це безпечно, швидко, і саме з нього розумно починати, перш ніж щось перезапускати чи оновлювати.

4. Крок 1: знайти весь PHP на сервері

4.1 Пакети й версії на хості

php -v
php-fpm -v 2>/dev/null || ls /usr/sbin | grep php-fpm
apachectl -M 2>/dev/null | grep -i php
dpkg -l | grep -i php      # Debian / Ubuntu
rpm -qa | grep -i php      # RHEL / AlmaLinux / Rocky

Важлива деталь: версія в командному рядку (php -v) і версія, якою відповідає веб-сервер, можуть відрізнятись. На сервері часто одночасно стоять кілька PHP (наприклад, 7.4 для старого сайту й 8.3 для нового), і веб-запити обробляє не той, що в $PATH. Перевіряйте і CLI, і FPM-пули, і модулі Apache.

4.2 Що саме слухає мережу

ps aux | grep -E 'php-fpm|php-cgi|apache2|httpd|litespeed' | grep -v grep
ss -tlnp | grep -E ':80|:443|:9000'

4.3 Контейнери

docker ps --format '{{.Names}}\t{{.Image}}'
docker images --format '{{.Repository}}:{{.Tag}}' | grep -i php
docker exec <container> php -v

Не покладайтеся на назву образу: його теги не завжди відповідають вмісту. Надійна перевірка тільки одна: запустити php -v всередині контейнера. Образи, зібрані на основі інших образів (вкладені Dockerfile), можуть тягнути PHP, про який ніхто не пам'ятає.

4.4 Що записати

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

5. Крок 2: оновити PHP

5.1 Пакети дистрибутива

Найкращий шлях: взяти виправлений пакет з репозиторію вашого дистрибутива. Станом на 21 жовтня оновлення з'явились у Ubuntu, Debian 13, RHEL 9 (модуль php:8.2), CloudLinux та cPanel (бекпорти для 7.4, 8.0 і 8.1). Для інших систем перевіряйте трекер безпеки свого дистрибутива.

sudo apt update && sudo apt upgrade     # Debian / Ubuntu
sudo dnf upgrade 'php*'                  # RHEL-сумісні

5.2 Обов'язково перезапустити процеси

Оновлення пакета саме по собі не змінює вже запущений PHP: процеси, які працюють, тримають у пам'яті стару версію. Для застосування виправлення потрібен перезапуск:

sudo systemctl restart php8.3-fpm     # ім'я юніта залежить від версії та дистрибутива
sudo systemctl restart apache2        # якщо використовується mod_php

Це одна з найпоширеніших помилок під час аварійного патчингу: пакет оновлено, версія в php -v нова, а FPM-пул працює з пам'яті ще зі старим кодом.

5.3 Перевірка після оновлення

php -v
php-fpm8.3 -v                       # або відповідна версія вашого пулу
systemctl status php8.3-fpm

Звіряйте результат з таблицею з розділу 2.4: 8.5.12, 8.4.27, 8.3.36 або 8.2.35 (чи пакет вашого дистрибутива з виправленням під іншою нумерацією). Якщо ви використовуєте дистрибутивний пакет зі старим номером версії, перевірте changelog на згадку CVE-2026-109618 та CVE-2026-109619.

5.4 Контейнери: пересборка, а не оновлення всередині

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

docker compose build --pull --no-cache app
docker compose up -d --no-deps app
docker compose exec app php -v

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

6. Крок 3: якщо оновитись одразу не можна

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

6.1 Вимкнути upload_progress і знайти потрібний php.ini

Це перший і найшвидший крок. У потрібному файлі задайте:

session.upload_progress.enabled = Off

Розташування конфігурації залежить від дистрибутива й способу встановлення PHP, а ще від того, чим саме обробляються запити: у FPM, Apache і CLI часто різні php.ini.

Після зміни обов'язково перезапустіть php-fpm або Apache, інакше працюючі процеси лишаться зі старими налаштуваннями. Перевірити, що значення застосувалось саме у веб-процесі, можна так:

php-fpm8.3 -i | grep -i "upload_progress.enabled"

У виводі має бути Off. Пам'ятайте про обмеження: вимкнення upload_progress закриває лише один вектор. Для другої вади потрібні обмеження розміру запитів і пам'яті (дивіться наступні підрозділи), а повноцінне рішення лишається одне: оновлення PHP.

6.2 Приклад для FPM-пулу

; /etc/php/8.3/fpm/pool.d/www.conf
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M

Директива php_admin_value важлива тим, що застосунок не може перевизначити її власним кодом, на відміну від ini_set().

6.3 Приклад для Nginx

server {
    client_max_body_size 8m;
    # ...
}

6.4 Обмеження пам'яті на рівні контейнера

Для Docker обмеження пам'яті контейнера (deploy.resources.limits.memory у Compose, розібране в статті про production) діє як страховка від того, щоб один аварійний процес забрав усю пам'ять хоста. Так само працює cgroup-ліміт для systemd-юніта PHP-FPM. Бажано не користуватися RLIMIT_AS та RLIMIT_DATA: у рекомендаціях прямо радять обмежувати пам'ять через cgroup.

6.5 Чого ці заходи не гарантують

Жоден пункт таблиці не закриває обидві вади повністю. Це міст до вікна обслуговування, а не заміна оновленню. Заведіть конкретну дату, коли тимчасові обмеження буде знято, а PHP оновлено, інакше «тимчасово» легко перетворюється на постійний стан.

7. Крок 4: чи не було вже візиту

Експлуатацію зафіксовано ще до виходу виправлень: за даними дослідників, перші спроби було зафіксовано о 07:43 UTC 21 жовтня, а виправлення вийшли о 14:00 UTC. Тому оновити сервер недостатньо: потрібно ще переконатись, що за ці години нічого не потрапило всередину. Орієнтуйтесь на журнали з 20 жовтня.

7.1 Журнали веб-сервера

grep -i 'php2shell' /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null
grep ' POST ' /var/log/nginx/access.log* | awk '{print $1, $7}' | sort | uniq -c | sort -rn | head -30

Перший рядок шукає User-Agent php2shell, який, за повідомленнями, мають деякі публічні експлойти. Але ефективний зловмисник легко його змінює, тож порожній результат нічого не гарантує. Другий показує, з яких адрес і на які URL надходило найбільше POST-запитів: різкий сплеск запитів на нехарактерні адреси, особливо великих multipart-запитів, варто розглянути докладніше.

7.2 Нові або змінені файли

find /var/www -type f -name '*.php' -newermt '2026-10-20' -ls
find /var/www -type f -newermt '2026-10-20' ! -name '*.log' -ls | head -50

Нові PHP-файли в каталогах завантажень, кешу чи тимчасових директоріях (там, де їх бути не повинно) — стандартна ознака web-shell. Порівняйте з вашим останнім деплоєм: усе, що з'явилось поза ним, потребує пояснення.

7.3 Процеси й з'єднання

ps -eo user,pid,ppid,cmd | grep -E '^(www-data|nginx|apache|php)' | grep -vE 'php-fpm|nginx|apache2'
ss -tnp | grep -E 'ESTAB' | grep -E 'php|www-data'

Спостерігайте, чи не запускає процес веб-сервера оболонку або утиліти curl, wget, nc, і чи немає незрозумілих вихідних з'єднань від користувача веб-сервера. Звичайний PHP-FPM таких дій не виконує.

7.4 Що робити за підозри

1. Ізолювати систему від зовнішньої мережі (не вимикати, щоб зберегти пам'ять і стан для аналізу).
2. Зберегти копії журналів і підозрілих файлів до будь-яких змін.
3. Змінити паролі, токени та ключі, до яких мав доступ процес PHP: перша вада може витікати вміст пам'яті, зокрема паролі, токени та TLS-ключі.
4. Відновлювати зі збереженої резервної копії, що передує інциденту, а не «чистити» поверх.

8. Щоб наступного разу це зайняло годину, а не день

Саме в таких подіях видно різницю між інфраструктурою, якою керує код, і інфраструктурою, яку тримають у пам'яті. Якщо ви пройшли серії про Docker на VPS та CI/CD, у вас уже є більша частина того, що потрібно.

8.1 Образ збирається з тегу, а не з «latest»

Фіксуйте версію PHP у FROM (наприклад, php:8.3-fpm-alpine замість php:latest). Тоді для реакції достатньо змінити один рядок і запустити збірку, а не гадати, яка версія стоїть на кожному сервері. Це той самий принцип відтворюваності, про який ішлося ще в першій статті серії.

8.2 Пересборка за розкладом

Виправлення в базових образах не потрапляють у ваш образ автоматично. Налаштуйте регулярну (наприклад, щотижневу) пересборку з --pull --no-cache у CI та перевірку php -v як кроку пайплайну: збірка падає, якщо версія нижча за потрібну. Тоді «виправлений образ уже є, а ми про це не знали» стає неможливим.

8.3 Реєстр і швидкий деплой

Автоматичний деплой (стаття 4 серії) перетворює оновлення з ручної операції по SSH на один push. А SHA-теги образів дозволяють швидко відкотитись, якщо нова версія PHP зламала застосунок: не доведеться вибирати між вразливістю та простоєм.

8.4 Ліміти ресурсів як постійна гігієна

Обмеження пам'яті й CPU на контейнер (стаття 3) зараз виявились ще й заходом безпеки: саме нестача пам'яті є стартовою точкою однієї з вад. Постійні розумні ліміти — це не лише захист від витоків пам'яті, а й обмеження поверхні атаки.

8.5 Інвентаризація як процес

Реєстр з розділу 4.4 (сервер, застосунок, версія, публічність) має жити постійно: його оновлюють при кожному деплої. Коли виходитиме наступне критичне оновлення (а воно вийде), ви відповідатимете не «давайте пошукаємо», а «ось список, ось порядок».

9. PHP 8.1 і старіше: питання не лише про цей патч

Офіційного виправлення для гілок 8.1 і старіших немає, бо проєкт PHP їх не підтримує. Підтримка 8.2 теж закінчується 31 грудня 2026 року, тобто за два з половиною місяці. Це означає, що ситуація, коли доведеться вирішувати «чим латати», повторюватиметься, доки застосунок лишається на застарілій гілці.

9.1 Три варіанти для застарілих систем

• Дистрибутивний бекпорт чи LTS-підтримка. Деякі постачальники (Ubuntu ESM, CloudLinux, cPanel для PHP 7.4/8.0/8.1) випускають виправлення для старих гілок. Це розумний міст, якщо міграція застосунку потребує часу.
• Збірка з вихідного коду. Проєкт PHP опублікував мінімальні патчі для 7.4, 8.0 і 8.1. Підходить командам, які вміють підтримувати власну збірку, але це операційний борг.
• Міграція на підтримувану гілку. Єдиний варіант без накопичення ризику. Складіть план: 8.3 дає підтримку безпеки до кінця 2027 року, 8.5 — ще довше.

9.2 Старий сайт як ізольований проєкт

Якщо застосунок не можна швидко мігрувати, ізолюйте його: окремий VPS або контейнер із жорсткими лімітами, доступ лише через reverse proxy з обмеженнями, відсутність секретів інших систем на тій самій машині. Дешевий окремий сервер коштує менше, ніж інцидент на спільній інфраструктурі.

10. Підсумок

PHP2Shell — це не привід для паніки й не новина «для когось іншого». Це привід за одну годину відповісти на три запитання, які мав би вміти відповісти будь-який адміністратор: де в нас PHP, якої він версії та хто його перезапускав після оновлення.

Порядок дій зводиться до чотирьох кроків:

1. Знайти. Версії PHP на хості та в контейнерах, CLI і FPM окремо; публічні системи перші.
2. Оновити. До 8.5.12, 8.4.27, 8.3.36 чи 8.2.35 або до дистрибутивного пакета з виправленням. Перезапустити FPM/Apache, перевірити php -v. У контейнерах: пересборка з --pull --no-cache.
3. Якщо не можна одразу. Закрити застосунок від інтернету, вимкнути session.upload_progress.enabled, обмежити розмір запитів, поставити ліміти пам'яті. Це тимчасово, з датою завершення.
4. Перевірити. Журнали з 20 жовтня, нові PHP-файли, дивні процеси веб-сервера. Відсутність знахідок не є гарантією, але знахідки потребують негайної реакції.

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

Часті запитання