Amazon Web Services фиксировала попытки взлома за четыре дня до релиза исправлений, а теперь дыры в PHP атакуют по всему интернету.
Две дыры в самом PHP получили общее имя PHP2Shell, оценку 9.2 по CVSS и сомнительную славу самого горячего кошмара октября. Эксплойт утёк в сеть 20 октября 2026 года — за день до того, как команда PHP успела выкатить исправления. Заплатки вышли 21 октября: версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Проблема в том, что атаковать начали раньше, чем защищаться.
Речь не о баге в конкретном плагине или CMS. Дыры сидят в ядре PHP — языка, на котором работает примерно 70% сайтов с известным серверным языком. Уязвимости под номерами CVE-2026-109618 и CVE-2026-109619 позволяют неаутентифицированному атакующему выполнить код на сервере. Одна из них вдобавок сливает память процесса: пароли, токены, API-ключи и сертификаты соседних запросов. Ни логина, ни пароля не нужно.
Amazon Web Services залогировала попытки использовать эти дыры за четыре дня до патча. Сейчас, по данным источников, эксплойт применяют массово по всему интернету. И это тот случай, когда «массово» — не журналистское преувеличение: сканеры прошлись по сети ещё до того, как администраторы узнали, что им вообще нужно обновляться.
Что именно взломали в PHP
Внутри PHP2Shell прячутся два независимых бага с разной механикой. CVE-2026-109618, известная как rawkey, бьёт по реализации HashTable в движке Zend. Эксплойт отправляет POST-запрос с полем имени чудовищного размера, провоцирует переполнение при разборе $_POST и добивается исполнения кода. Запрос весит больше мегабайта, так что на уровне WAF его можно отсечь простым ограничением размера тела.
CVE-2026-109619, собственно php2shell, работает через session.upload_progress — колбэк, который срабатывает на любом POST-эндпоинте ещё до того, как до дела доберётся код приложения. Тело запроса здесь всего около 450 байт. Никакие лимиты по размеру не помогут: защищаться придётся другими методами. Обе уязвимости получили CVSS 9.2, и обе позволяют удалённое исполнение кода без авторизации.
Показательно, что уязвимы не только WordPress, Drupal и Joomla, на которых исследователи демонстрировали атаку. Дыры в самом движке, так что приложение с идеально чистым кодом всё равно уязвимо, если под ним крутится заражённая версия PHP. Простой «Hello World» на непропатченном рантайме — и тот под ударом.
Реакция AWS и масштаб проблемы
Amazon Web Services оказалась в роли того самого соседа, который первым заметил пожар. Инфраструктура AWS зафиксировала попытки эксплуатации за четыре дня до релиза патчей, то есть примерно тогда, когда эксплойт только начал гулять по сети. Облачные провайдеры видят трафик раньше всех, так что их логи — это фактически барометр надвигающейся бури.
Масштаб впечатляет. По данным W3Techs, PHP держится на 69,3% сайтов с известным серверным языком. Почти половина из них работает на версиях, которые официального патча не получат: поддержка PHP 8.1 и всего, что старше, давно прекращена. Речь о примерно трети всех сайтов в интернете. В эту категорию попадают заброшенные лендинги, сайты купленных дочек и прошивки сетевых устройств, куда администратор вообще не заглядывает.
Утечка ускорила всё. Изначально раскрытие планировали на 22 октября, но утечка информации и эксплойта, которую публично заметил исследователь Кевин Бомонт, сдвинула сроки. PHP выпустила экстренный релиз 21 октября в 14:00 по UTC. Репозиторий NCSC-NL на GitHub уже собрал оперативную сводку по уязвимостям, а исследователи из Wiz Research и OpenAI Codex Security подтвердили, что баги реальны.
Что делать администраторам
Полное решение только одно, и оно не из приятных: обновить PHP до 8.2.35, 8.3.36, 8.4.27 или 8.5.12. Не приложение, не CMS, не плагины — именно рантайм под ними. После установки нужно перезапустить Apache, PHP-FPM и все долгоживущие воркеры, иначе старый код продолжит висеть в памяти. Обновление CMS версию PHP под ней не меняет.
Тем, кто пока не может патчить, остаются полумеры. Отключить session.upload_progress.enabled — функция почти не используется, плохо тестируется и теперь стала удобной мишенью. Настроить WAF или обратный прокси с отдельными сигнатурами под каждое семейство эксплойтов. Ограничить размер тела запроса, чтобы отсечь rawkey. Для совсем старых веток — искать бэкпорты у дистрибутивов или хостинг-провайдеров. В крайнем случае сервис выводят из сети до установки патча. Несколько часов простоя дешевле скомпрометированного сервера.
PHP также рекомендует держать session.upload_progress.enabled=0 даже после обновления, если конкретно эта функция не нужна. Все ограничения ниже патча — это не замена исправлению, а способ дожить до него.
Редакция TechLoot напоминает: обновление PHP — это не та задача, которую можно отложить на понедельник. Если сервер смотрит в интернет и крутит непропатченную версию, считать его уже скомпрометированным — здоровая паранойя. А если после обновления админ впервые за год заглянул в логи и нашёл там что-то интересное, пусть напишет — тема для отдельного разбора.