21 октября вышли патчи для двух критических уязвимостей в самом PHP, CVE-2026-109618 и CVE-2026-109619. Они дают удалённое выполнение кода без авторизации. Под угрозой любой PHP-проект, включая коробочный Битрикс24. Разбираем, что происходит, какие версии затронуты и как обновляться.
21 октября разработчики PHP выпустили срочные патчи для двух уязвимостей, которые уже называют PHP2Shell. Ошибки находятся в самом интерпретаторе, а не в коде сайта, поэтому не важно, на чём написан проект: Laravel, самописный код, WordPress или коробочный Битрикс24. Если на сервере крутится уязвимая сборка PHP, атаковать можно одним запросом и без авторизации.
Что нашли
Под названием PHP2Shell объединены две уязвимости с идентификаторами CVE-2026-109618 и CVE-2026-109619. Обе оценены в 9.2 балла по CVSS v4.0, а исследователи watchTowr поставили им максимальные 10.0. Обе позволяют выполнить произвольный код на сервере без логина и пароля.
Первая, CVE-2026-109618, связана с нехваткой памяти. Если PHP упирается в лимит памяти в момент, когда он только собирает внутренние структуры запроса, эти структуры остаются недособранными, а код очистки запроса потом считает их корректными и работает с мусором. Вторая, CVE-2026-109619, связана с устаревшим глобальным состоянием: внутренние данные запроса переживают память, на которую они указывают, и следующий запрос, попавший в тот же рабочий процесс, может воспользоваться этими остатками до того, как они будут сброшены.
Главная неприятность в том, что атака срабатывает на уровне рантайма, до выполнения кода приложения. Поэтому «у нас всё написано аккуратно» и «у нас нет загрузки файлов» здесь не аргумент. Уязвимы все способы запуска PHP для веба: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP, LiteSpeed. По описанию исследователей, сильнее всего рискуют установки с mod_php.
Ситуация с эксплуатацией описывается по-разному. watchTowr сообщает, что видит атаки с 21 октября, Amazon Threat Intelligence зафиксировал попытку на своей ловушке MadPot ещё 17 октября, за четыре дня до публичного раскрытия. PHP Foundation на раннем этапе говорила, что рабочих эксплойтов не видела, только неполные и нерабочие. Накануне релиза в сеть утёк ролик с демонстрацией цепочки атаки, и патчи выпустили на день раньше плана. Закладываться на то, что эксплойт сложно написать, не стоит.
Какие версии PHP под угрозой
Уязвимости затрагивают ветки от 5.4 до 8.5. Исправления вошли в четыре релиза:
- PHP 8.5.12;
- PHP 8.4.27;
- PHP 8.3.36;
- PHP 8.2.35.
Обратите внимание на формулировку: уязвима не только всё, что старше 8.2, но и сама ветка 8.2 (и 8.3, 8.4, 8.5), пока она не обновлена до указанной минорной версии. Сайт на 8.2.30 или 8.3.20 так же открыт, как сайт на 7.4.
Хуже всего тем, кто сидит на неподдерживаемых ветках. Для PHP 7.4, 8.0 и 8.1 официальных релизов с исправлением нет, есть только минимальные бэкпорты исходного кода и пакеты от поставщиков дистрибутивов и LTS-сборок. Для 7.3 и всего, что старше, включая 5.x и 5.6, исправления нет вообще, и единственный выход — переезд на поддерживаемую ветку. Разработчики PHP отдельно указывают, что никакая настройка конфигурации полностью проблему не закрывает.
Старый PHP, который годами стоял на проектах потому что «работает, не трогайте», теперь превращается в прямую дыру. Это касается и интернет-магазинов на устаревших CMS, и корпоративных порталов, и внутренних сервисов, до которых можно достучаться снаружи.
Почему это касается Битрикс24
Битрикс сам по себе не виноват: в «1С-Битрикс: Управление сайтом» и коробочном Битрикс24 уязвимости нет, она сидит в PHP. Но продукт работает на PHP и наследует его проблемы целиком. Вендор опубликовал официальное обращение и для облака, и для коробки.
В облачном Битрикс24 серверным PHP управляет команда сервиса, пользователям ничего обновлять не нужно. На время устранения угрозы в облаке ввели временные ограничения, которые могут затрагивать формы, файлы, сделки CRM, письма и бизнес-процессы. Восстановление функций идёт поэтапно.
В коробочном Битрикс24 и на сайтах на «1С-Битрикс: Управление сайтом» ответственность лежит на вас, точнее на вашем администраторе, интеграторе или хостинге. Две вещи, на которых чаще всего спотыкаются:
- обновление через SiteUpdate обновляет продукт, но не PHP, поэтому закрыть уязвимость им нельзя;
- успешное завершение команды обновления пакета не доказывает, что сайт теперь работает на новой сборке: нужно убедиться, какой именно PHP обслуживает веб-запросы.
Отдельный риск у коробок, которые лет пять назад развернули на PHP 7.x или 8.0 и больше не трогали. Портал с CRM, перепиской с клиентами, договорами и файлами сотрудников — одна из самых ценных целей для атакующего, и если он получит код на сервере, до базы и файлового хранилища ему останется один шаг.
Как обновляться
Общий порядок одинаков для любого окружения: сделать резервные копии, проверить версию, поставить исправленную сборку, перезапустить обработчики PHP и проверить, что сайт или портал работают.
Для виртуальной машины BitrixVM 9.x вендор описывает такую последовательность: сделать бэкап и проверить совместимость на тестовом стенде, обновить сведения о пакетах и убедиться, что исправленный PHP доступен, поставить его вместе с зависимостями, перезапустить Apache командой systemctl restart httpd.service, затем проверить авторизацию, CRM, загрузку файлов, почту и интеграции. Если серверов несколько, обновлять нужно каждый. Если исправленного пакета в вашем репозитории ещё нет, его ставят вручную. В репозитории remi сборки для поддерживаемых версий уже выходили, но в части обзоров отмечается, что на момент публикации там были задержки, так что смотрите, что реально лежит в репозитории, прежде чем рассчитывать на штатное обновление.
Для остальных окружений:
- обычный сервер: обновить PHP менеджером пакетов или собрать из исходников, затем перезапустить Apache (при mod_php) или службы PHP-FPM; перезапуска одного nginx недостаточно, потому что работающие процессы PHP остаются старыми;
- контейнеры: пересобрать образ с исправленным PHP и пересоздать контейнеры, сохранив конфигурацию и тома; перед удалением старых контейнеров проверить, что в их записываемом слое не осталось нужных данных;
- PHP 7.4, 8.0, 8.1: взять пакет у поставщика дистрибутива или LTS-сборки, либо переехать на 8.2+ с актуальной минорной версией.
Переезд с 7.4 или 8.0 на 8.2 и выше для проектов на Битрикс обычно требует проверки совместимости пользовательских модулей и шаблонов, поэтому его стоит делать сначала на тестовой копии. Но откладывать это до «когда будет время» теперь рискованно.
Если обновить нельзя прямо сейчас
Полноценной замены обновлению нет. Вендор Битрикса предлагает временную меру: отключить отслеживание прогресса загрузки файлов, добавив в /etc/php.d/z_bx_custom.ini строку session.upload_progress.enabled = Off и перезапустив процессы PHP. Эта мера не закрывает уязвимости полностью и лишь немного уменьшает поверхность атаки.
Дальше остаются организационные решения. Британский NCSC рекомендует отключать от интернета системы, которые нельзя исправить сразу. Для портала это значит закрыть доступ по IP или VPN для сотрудников, а публичные страницы на время вынести за прокси. Cloudflare выкатил первые WAF-правила под известные векторы этой атаки, они доступны на всех тарифах, включая бесплатный. Правила WAF ловят только известные способы запроса, поэтому считать их заменой патчу нельзя.
Для быстрой проверки, видна ли уязвимость снаружи, компания Searchlight Cyber выложила открытый сканер php2shell-scanner.
Что проверить после обновления
Первое, что нужно сделать, — убедиться, что новая версия действительно работает. Проверьте php -v для консоли и отдельно версию, с которой работает веб-процесс: через phpinfo() во временном файле, который сразу удалите, либо через админку Битрикса. Версии CLI и FPM часто расходятся.
Второе — посмотреть логи за последние дни. Часть источников советует искать запросы с User-Agent, содержащим «php2shell», но готового списка индикаторов компрометации у исследователей нет, а настоящий атакующий вряд ли подпишется. Поэтому полезнее искать общие признаки взлома: новые или изменённые PHP-файлы в каталогах загрузок и в /bitrix/, незнакомые задания cron, неожиданных пользователей в системе и админке, необычные исходящие соединения с сервера. Если сервер был доступен из интернета на уязвимой версии с 17 октября, имеет смысл считать проверку на компрометацию обязательной, а не желательной.
И последнее: заведите инвентаризацию PHP. Многие узнают на таких инцидентах, что у компании есть забытый тестовый стенд, старый поддомен или лендинг на отдельном хостинге, про которые никто не помнит. Вспоминать нужно обо всём, что отвечает на HTTP, потому что атакующему всё равно, как давно проект не трогали.
Источники: официальное обращение 1С-Битрикс по уязвимостям PHP, материалы watchTowr, Help Net Security, Recorded Future и Imperva, публикации на Хабре, vc.ru и в Т—Ж за 21–22 октября 2026 года. Данные по эксплуатации и затронутым продуктам продолжают обновляться, поэтому сверяйтесь с официальным анонсом PHP.