PHP выпустил патч 21 октября: дыры PHP2Shell 9,2 взламывают сайт без логина

Команда PHP 21 октября 2026 в 14:00 UTC выпустила четыре срочных релиза: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Они закрывают две дыры CVE-2026-109618 и CVE-2026-109619, которые публично прозвали PHP2Shell. Оценка по шкале CVSS v4.0 - 9,2 из 10: злоумышленник без логина может выполнить свой код на веб-сервере. Это касается почти любого сайта на PHP, от блога на WordPress до Magento-магазина. Если вы админите хостинг или просто покупаете в сети, дыра уже в вашей зоне.

Что сломалось в движке, а не в плагине

PHP - язык, на котором собрана большая часть интернета: блоги, интернет-магазины, панели хостинга, форумы. Дыры сидят не в WordPress и не в теме, а в самом интерпретаторе, который обрабатывает любой запрос. Первая, CVE-2026-109618, связана с тем, как PHP реагирует на нехватку памяти: запрос обрывается в неудачный момент, внутренние данные остаются «полусобранными», и при уборке сервер принимает мусор за нормальный код. Вторая, CVE-2026-109619, оставляет в памяти рабочего процесса следы прошлого запроса. Следующий посетитель может наткнуться на уже освобождённую память.

По заявлению проекта PHP, риск выше всего на Apache с модулем mod_php: атаку можно запустить ещё до того, как сработает код сайта. PHP-FPM, php-cgi, FrankenPHP и LiteSpeed тоже затронуты. Исследователи из Calif и Wiz показали, что один неаутентифицированный запрос достаточен. Sansec пишет, что демонстрация проходила на Magento 2.4.9, WordPress, Drupal, Joomla, MediaWiki, Nextcloud, Laravel и phpMyAdmin. Плагин «от безопасности» тут не поможет: чинить надо сам PHP.

Почему патч вышел в панике, а не по плану

20 октября на Hacker News и в соцсетях всплыли детали до официального эмбарго. Появилось видео с эксплойтом под именем PHP2Shell. Команда PHP сдвинула релиз на 21 октября и заранее предупредила админов готовить окна. Cloudflare, по своим данным, видела попытки ещё до 14:00 UTC и включила временные правила на файрволе. watchTowr сообщила о срабатываниях на ловушках в тот же день; американская CISA на тот момент массовой эксплуатации не подтверждала.

Такой сценарий хуже «тихой» дыры. Пока дистрибутивы раскатывают пакеты, боты уже стучатся. Исследователь Кевин Бомонт назвал это одной из самых крупных уязвимостей за годы именно из-за доли PHP в вебе. Половина сайтов на старых ветках 8.1 и ниже официальных бинарников не получит: проект выложил только исходники-бэкпорты для 7.4, 8.0 и 8.1 тем, кто собирает сам.

Кого это бьёт в России, СНГ и Европе

Типичный читатель не пишет на PHP, но живёт на нём. Интернет-магазин на OpenCart или WooCommerce, лендинг на Tilda с PHP-формами, корпоративный Bitrix, форум, личный блог на Beget или Timeweb - всё это кандидаты. Хостеры FirstVDS и аналоги уже на этой неделе отчитывались о других дырах в панелях; PHP2Shell ложится сверху. Если магазин не обновился, карточные данные и сессии могут уехать вместе с шеллом.

Для покупателя практический смысл простой: крупные сети с нормальным DevOps патчат быстрее. Маленький магазин «у знакомого админа» - нет. Если сайт тормозит, странно редиректит на «оплату» или просит повторно ввести карту после вчерашнего спокойного визита, лучше не платить. Владельцу сайта это ещё больнее: шелл равен полной компрометации базы, почты и SSL-ключа.

Что сделать сегодня, если сайт ваш

Единственное полное решение - обновить PHP до 8.5.12, 8.4.27, 8.3.36 или 8.2.35. Скачать исходники и виндовые сборки можно с страницы загрузок php.net. На Ubuntu, Debian, RHEL пакеты должны прийти от дистрибутива: они получили патч заранее. Laravel Forge прямо пишет: автообновления PHP не ставят, админ жмёт кнопку сам.

Если обновить прямо сейчас нельзя, PHP советует частичные костыли, не делающие систему безопасной: session.upload_progress.enabled=0 и перезапуск всех воркеров; на 8.5 ещё fatal_error_backtraces=0; memory_limit=-1 административно, чтобы приложение не вернуло лимит. pm.max_requests=1 ломает требование «тот же воркер». Это не щит, а тормоз для части путей. PHP 8.1 и старше без апгрейда ветки остаются дырявыми. Напишите хостеру тикет с номерами CVE и потребуйте скрин версии php -v.

1. Спросить у хостинга текущую версию PHP и дату пакета.
2. Если ниже 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 - требовать апдейт или смену ветки.
3. После обновления перезапустить php-fpm или Apache и проверить phpinfo().
4. Посмотреть логи на странные POST без нормального User-Agent за 20-21 октября.
5. Сменить пароли БД, админки и ключи API, если есть подозрение.

Что делать, если вы только покупаете

Вы не патчите чужой сервер. Смотрите на привычки магазина: есть ли нормальный https, не прыгает ли домен, не просит ли «подтвердить карту» вне корзины. Крупные площадки с PCI-аудитом обычно быстрее. Самописный магазин на дешёвом shared-хостинге - хуже. Если уже платили на мелком сайте в последние дни, имеет смысл глянуть выписку и при сомнении перевыпустить карту: это дешевле, чем разбор с банком через месяц.

Почта и аккаунты, привязанные к тому же магазину, тоже в зоне. Смена пароля на уникальный и включение двухфакторки не лечат взломанный сервер, но отсекают повторное использование слитой пары. Не открывайте «счета» и «накладные» из писем, которые пришли сразу после новости: фишинг на фоне паники всегда ускоряется.

Почему «у нас Cloudflare» не равно «мы в безопасности»

WAF режет известные сигнатуры. Как только эксплойт чуть меняет форму запроса, правило отстаёт. Cloudflare сама говорила о временных правилах, не о вакцине. Shared-хостинг с десятком сайтов на одном PHP-FPM ещё веселее: соседний заброшенный блог может стать точкой входа в ваш магазин, если воркеры общие.

Старые ветки 7.x до сих пор живут на «не трогай, работает». Для них нет нормальных бинарников от php.net. Либо апгрейд до 8.2+, либо жизнь с дырой. Это не мораль, это арифметика поддержки. PHP 8.2 сам умрёт 31 декабря 2026 и перестанет получать даже такие патчи.

Как понять, что вас уже задели

Классика: новый файл в корне сайта с коротким именем, внезапный редирект, спам с вашего домена, неизвестный админ в WordPress, пик CPU без трафика. Sansec и другие форензики ждут волну шеллов в магазинах, как после прошлых дыр Magento. Если бэкапы старше 20 октября, имеет смысл сравнить файлы с чистым образом CMS.

Не ставьте «сканеры с GitHub», которые обещают «проверить PHP2Shell одним кликом»: часть из них и есть эксплойт. Официальные advisory - на архиве новостей PHP и в GitHub Security Advisories проекта php-src. Если хостер молчит сутки, это тоже сигнал: либо очередь, либо они сами на старой ветке.

Источники

Официальный текст и номера версий - у PHP. Технические разборы - у JFrog, Sophos, Sansec и PHP Foundation. Цифры эксплуатации на утро 21 октября расходятся: кто-то видит сканы, CISA массовых взломов не фиксировала. Имеет смысл исходить из худшего и патчить, а не ждать сводку.