Дві критичні вразливості в ядрі PHP — CVE-2026-109618 і CVE-2026-109619 (CVSS v4.0 9.2) — спричинили хвилю сканування та спроб експлуатації вже за кілька годин після розкриття 21 жовтня 2026 року. Вразливості дають змогу неавтентифіковане віддалене виконання коду через спеціально сформовані HTTP-запити та зачіпають усі версії PHP до 8.2.35, 8.3.36, 8.4.27 і 8.5.12. За даними кількох незалежних дослідницьких груп — Sophos, Arctic Wolf і Hunt.io — жодна зі спостережуваних спроб не призвела до підтвердженої компрометації. Ми вже писали про технічні деталі цих вразливостей і заходи захисту; цей матеріал зосереджений на аналізі реальної активності зловмисників і причинах, з яких експлуатація виявилася складнішою, ніж очікувалося.
Природа вразливостей і масштаб поверхні атаки
Згідно з бюлетенем CERT/CC (VU#763488), CVE-2026-109618 є вразливістю пошкодження пам’яті в механізмі обробки нестачі пам’яті (OOM) PHP: за певних умов частково ініціалізовані дані запиту можуть бути доступні під час очищення. CVE-2026-109619 — це вразливість типу «використання після звільнення» (use-after-free), за якої застарілий глобальний стан, що належить одному запиту, повторно використовується наступним запитом того самого робочого процесу.
Вразливий код присутній у PHP починаючи з версії 5.4 (2012 рік), що означає: проблема зачіпає не конкретний застосунок, а сам рушій PHP. Будь-який сайт на WordPress, Drupal або Joomla з чистим прикладним кодом лишається вразливим, якщо PHP не оновлено. У зоні ризику конфігурації PHP-FPM, Apache mod_php, php-cgi, FrankenPHP і LiteSpeed. За даними CERT/CC, Apache mod_php становить найбільший ризик, оскільки експлуатація може відбутися до виконання коду застосунку.
За оцінками Censys, станом на 23 жовтня 2026 року понад 34,4 мільйона PHP-сервісів лишалися потенційно вразливими із загальної кількості понад 56,6 мільйона веб-ресурсів, що використовують PHP. Організації на PHP 7.4, 8.0 або 8.1 не отримують офіційних оновлень безпеки від PHP Project і потребують бекпортів від дистрибутивів або міграції на підтримувану гілку.
Активність зловмисників: багато шуму, нуль результатів
Масштабне сканування та спроби експлуатації почалися протягом 45 хвилин після публічного розкриття вразливостей. За даними Arctic Wolf, спостережувана активність варіювалася від базових перевірок вразливої поведінки механізму відстеження прогресу завантаження сеансів PHP до спроб підтвердити виконання команд ОС.
Принципово важливий факт: Sophos спочатку повідомила про успішну експлуатацію PHP2Shell у своїх клієнтів, але згодом скоригувала цю оцінку, зазначивши, що телеметрія показала лише сканування та невдалі спроби без доказів успішної компрометації. Hunt.io незалежно підтвердила цей висновок: єдиний виявлений оператор масової експлуатації здійснив десять проходів по 123 серверах і не отримав жодного шелу. Таку саму картину фіксують Wordfence, Previdian, Beelzebub і Dataminr.
Основна причина невдач зловмисників — необхідність обходу ASLR (Address Space Layout Randomization), механізму рандомізації адресного простору, який робить непередбачуваним розташування коду в пам’яті. VulnCheck розробила метод, що поєднує обидві вразливості для обходу ASLR на x86-64 системах із рекомендованими виробничими налаштуваннями PHP, однак підкреслила, що створення такого експлойту «далеке від тривіального». Це пояснює розрив між масовим скануванням і відсутністю успішних атак.
Ботнет Potassium і інфраструктура атак
Спостережуваний експлуатаційний трафік пов’язаний з Potassium — варіантом ботнета Mirai, уперше зафіксованим платформою Synthient у березні 2026 року. Зв’язок установлено на рівні інфраструктури та зразків шкідливого ПЗ трьома незалежними дослідницькими групами (Sophos, Arctic Wolf, Hunt.io), однак конкретний відповідальний зловмисник не ідентифікований. Важливо наголосити: докази пов’язують PHP2Shell-запити з інфраструктурою Potassium, але не підтверджують, що пов’язані зразки були завантажені й виконані через ці вразливості.
За даними Sophos, зразок Potassium встановлює TCP-з’єднання з C2-сервером 134.199.154[.]64, надсилає HTTP-запит і очікує у відповідь Linux ELF-бінарний файл. Ботнет підтримує 24 команди для проведення DDoS-атак за протоколами ICMP, TCP, UDP та OpenVPN. Серед технічних особливостей — використання ChaCha20 для шифрування статичної таблиці конфігурації (уперше для варіантів Mirai), DNS-схема перенаправлення з перестановкою 16-бітних половин кожного A-запису, а також неактивна, але вбудована підтримка розв’язування C2-інфраструктури через Ethereum Name Service (ENS).
Окремо SOCRadar виявила на відкритому сервері зловмисника (206.188.197[.]105:9999) набір інструментів для експлуатації PHP2Shell, включно зі скриптом aslr_exploit.py — експлойтом для PHP 8.4.26 під Apache mod_php, що працює у три етапи: перезапуск PHP-воркера, витік адрес пам’яті через cookie сеансу для обходу ASLR та зловживання механізмом відстеження прогресу завантаження сеансів для виконання команди.
Індикатори компрометації
Ключові IOC із досліджень:
- IP-адреси джерел атак: 85.11.167[.]243, 217.60.242[.]76, 45.198.224[.]169
- Інфраструктура завантаження: 92.118.112[.]100, 206.188.197[.]105
- C2-сервер: 134.199.154[.]64 (TCP-порт 50792)
- Домени: thunder[.]godofthunder[.]st, hackattackkaboom[.]botlesscucks[.]st
- Хеші зразків: 0c5486f06620e26e316f4b33f318b0d646d5e1133789331aa2fed012360d1486, e2529d4afa39ae4db2eb05d5176317c906289abf09660c75bdeec43e54c55aa3
Практичне виявлення спроб експлуатації
За даними Hunt.io та Arctic Wolf, для розмежування спроб сканування і реальної компрометації слід корелювати кілька сигналів:
- User-Agent, що містить рядки на кшталт
php2shell-scan/109618абоphp2shell-109618 - Multipart POST-запити з полем
PHP_SESSION_UPLOAD_PROGRESSта аномально великим тілом - Сплески помилок «Allowed memory size exhausted» у логах PHP-FPM
- Подальша активність: створення процесів, зміни в кореневому каталозі веб-сервера, вихідні мережеві з’єднання до перелічених C2-адрес
Наявність перших трьох ознак указує на спробу експлуатації; четверта — на можливу компрометацію, що потребує негайного розслідування.
Рекомендації
- Негайно оновіть PHP до версій 8.2.35, 8.3.36, 8.4.27 або 8.5.12, як рекомендує CERT/CC
- Організації на PHP 8.1 і нижче не отримують оновлень від PHP Project — потрібна міграція на підтримувану гілку або застосування бекпорту від дистрибутива
- Перевірте логи веб-серверів на наявність перелічених IOC та патернів експлуатації
- Заблокуйте мережеві з’єднання до зазначених C2-адрес і доменів на рівні периметра
- Для конфігурацій Apache mod_php розгляньте тимчасовий перехід на PHP-FPM, який забезпечує додаткову ізоляцію процесів
Поточна ситуація з PHP2Shell нагадує перші дні Log4Shell: вразливий код існує понад десять років, стосується рушія, а не застосунку, і не має патчів для застарілих гілок. Відсутність підтверджених компрометацій наразі — наслідок технічної складності обходу ASLR, а не безпеки вразливих систем. VulnCheck уже продемонструвала, що цей бар’єр можна подолати. Пріоритет для кожної організації, що використовує PHP, — оновитися до виправленої версії до того, як надійні експлойти стануть доступними ширшому колу зловмисників.
