PHP2Shell (CVE-2026-109618/109619) и 1С-Битрикс: как обновить PHP и BitrixVM

На 21 октября 2026 для двух критических уязвимостей PHP (CVE-2026-109618 и CVE-2026-109619) есть исправления в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35; для 8.1 и старше официального патча нет. Сайту на 1С-Битрикс это угрожает так же, как любому PHP-приложению: проактивная защита и обновление модулей ошибку интерпретатора не закрывают. Заявления самой 1С-Битрикс по этим CVE мы не нашли — статус вендора проверяйте заново, а PHP обновляйте средствами системы или окружения.

Что известно на 21 октября 2026 и почему это касается Битрикса

21 октября 2026 года опубликованы две критические уязвимости в ядре PHP — CVE-2026-109618 и CVE-2026-109619 (вместе их называют PHP2Shell), у обеих оценка CVSS v4.0 равна 9.2. Исправления вышли в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Для PHP 8.1 и старше официального исправления нет: эти ветки закончили поддержку. Уязвимость находится в интерпретаторе, поэтому ей всё равно, на чём написан сайт: Sansec подтвердил выполнение кода без авторизации на целом ряде популярных систем, а NCSC Великобритании пишет, что затронуты любые версии PHP. Сайт на 1С-Битрикс здесь не исключение: у него тот же интерпретатор под капотом.

Что именно происходит, если коротко. Тело запроса multipart/form-data PHP разбирает до того, как начнёт выполняться код приложения. Если во время запроса случается фатальная ошибка — чаще всего исчерпание memory_limit, — состояние запроса может остаться наполовину очищенным, и следующий запрос на том же воркере читает уже освобождённую память. Последствия — утечка содержимого памяти воркера (пароли, токены сессий, ключи) и выполнение кода. Конфигурация по умолчанию уязвима, аутентификация не нужна. Подробный обзор и план на первый час — в статье PHP2Shell: что делать за первый час.

Теперь про то, чего мы на 21 октября не знаем. Заявление самой 1С-Битрикс по этим CVE мы не нашли, как и сообщений о том, что вышел отдельный апдейт продукта, перенастроенный образ виртуальной машины или обновлённое окружение BitrixEnv. Это не значит, что их нет и не будет: статья горячая, статус вендора нужно проверять заново на официальных страницах dev.1c-bitrix.ru и в разделе поддержки перед каждым шагом. Но обновление PHP не зависит от решения вендора CMS: оно делается средствами операционной системы или окружения, а вендор CMS лишь определяет, какие версии PHP его продукт поддерживает.

Как узнать, что ваш Битрикс под ударом

Под ударом любой сайт на Битриксе, у которого PHP не получил исправление: и «Управление сайтом», и Битрикс24 в коробочной версии, и тестовые копии, и забытые поддомены. Начинаем с инвентаризации — ровно так советует и NCSC: найти весь PHP, включая тот, что встроен в продукты и окружения. На практике у компании с несколькими десятками рабочих мест их обычно больше, чем помнит администратор: боевой сайт, копия для разработчика, старая виртуальная машина с интранетом, портал сотрудников. Если у вас нет реестра систем, начните с него — для этого подойдёт наша статья про инвентаризацию ИТ-активов.

Первое, что проверяем на каждом сервере, — какая версия PHP реально обслуживает сайт. Версия в командной строке и версия веб-сервера могут отличаться: на одной машине бывают PHP из пакетов системы, PHP из окружения Битрикса и собранный вручную. Узнать версию веб-части надёжнее всего через административный раздел продукта (страница проверки системы показывает версию PHP и параметры) либо через временный скрипт, который сразу удаляем после проверки. Командная строка даёт только версию CLI.

php -v
php -i | grep -E 'memory_limit|post_max_size|upload_max_filesize|session.upload_progress.enabled|opcache.enable'
# версии пакетов (Debian/Ubuntu)
apt list '?installed ?name(^php[0-9.]+$)'
# версии пакетов (RHEL-семейство)
rpm -qa | grep -i '^php' | sort

Дальше сверяем версию с таблицей исправлений. Если у вас 8.2.35, 8.3.36, 8.4.27 или 8.5.12 либо пакет дистрибутива с бэкпортом (для Ubuntu 22.04 это php8.1 версии 8.1.2-1ubuntu2.28, для 24.04 — php8.3 версии 8.3.6-0ubuntu0.24.04.13), вопрос закрыт, останется перезапустить сервисы. Если на сайте PHP 7.x или 8.0 — исправления из upstream нет, и вам нужен либо коммерческий бэкпорт (Ubuntu Pro для 20.04 и старше), либо переезд на поддерживаемую ветку. Для окружения BitrixVM/BitrixEnv поставляемую версию PHP и порядок её смены на 21 октября нужно сверять с документацией вендора: подтверждённого заявления о выходе исправленной сборки окружения мы не нашли.

Признаки возможной эксплуатации по Patchstack — это не доказательство, а повод посмотреть журналы: необычные multipart-запросы, после которых в логе PHP появляется ошибка memory_limit; повторяющиеся ответы HTTP 500; аномально большие или битые куки PHPSESSID; необъяснимые перезапуски воркеров. На Битриксе дополнительно смотрим раздел журнала событий и каталог загрузок: появление новых PHP-файлов в /upload/ или /bitrix/tmp/ — отдельный тревожный сигнал. Как разбирать журналы nginx и Apache, мы описали в статье про признаки взлома в логах.

Почему проактивная защита Битрикса не заменяет обновление PHP

Частая реакция владельцев сайтов на Битриксе: у нас включена проактивная защита, модуль обновлён, значит, мы в безопасности. Это неверный вывод, и объяснить его нужно спокойно. Проактивная защита, как и любой WAF уровня приложения, — это код на PHP, который работает внутри запроса: проверяет входные данные, фильтрует опасные конструкции, следит за сессиями. Она эффективна против ошибок самого сайта: инъекций, XSS, подмены данных. Но уязвимость PHP2Shell находится глубже: тело multipart-запроса разбирает интерпретатор ещё до того, как управление дойдёт до prolog_before.php и любых модулей Битрикса. Код защиты просто не успевает вызваться.

Вторая половина мифа — обновление модулей и «чистота» кода. Чистый код приложения тут ничего не меняет: ошибка не в нём. Sansec подтвердил эксплуатацию на нескольких CMS с актуальными версиями, и логика та же: обновили плагины или ядро продукта — защитились от ошибок продукта, но не от ошибки интерпретатора. Patchstack отдельно предупреждает: не ставить «плагины-заплатки» и сниппеты с форумов. Для Битрикса это значит: не добавляйте в init.php чужие фильтры «от PHP2Shell» — они выполнятся уже после того, как PHP разобрал запрос.

Поэтому порядок такой. Первое — обновить PHP до исправленной версии и перезапустить сервисы. Второе — если это невозможно сегодня, поставить временные меры на уровне PHP и веб-сервера (ниже). Третье — оставить проактивную защиту включённой: она по-прежнему нужна, но как слой против других атак, а не как замена патча интерпретатора. Если вы используете внешний WAF или Cloudflare, помните: это тоже лишь временная мера, и она работает, только если сервер принимает трафик исключительно от этого сервиса.

Как обновляем PHP на BitrixVM, BitrixEnv и на обычном Linux

Сначала определяем, какая у клиента схема. Вариантов три: виртуальная машина или окружение 1С-Битрикс (BitrixVM/BitrixEnv), обычный сервер Linux с пакетами PHP из дистрибутива или репозитория, либо хостинг с панелью. Для первых двух мы действуем по-разному, а для хостинга обращаемся в поддержку провайдера и просим подтвердить версию PHP в письменном виде. Для панелей с несколькими версиями PHP у нас есть отдельный разбор: панели с несколькими версиями PHP.

В BitrixVM/BitrixEnv управление идёт через текстовое меню на сервере; запускается оно командой /root/menu.sh, если не открылось само при входе под root. Там есть разделы для работы с хостами пула и сайтами, а также для настройки PHP — точные номера пунктов отличаются между версиями окружения, поэтому ориентируйтесь на названия на экране, а не на цифры из чужих инструкций. Перед сменой версии PHP окружение нужно обновить до актуальной версии: в публичных руководствах хостеров прямо указано, что старый BitrixEnv сначала обновляют, и лишь потом переключают PHP. Какие версии PHP и когда будут доступны в вашем окружении, и вышла ли сборка с исправлением, — проверяйте в документации вендора и в самом меню: на 21 октября этого подтверждения мы не нашли.

# запуск меню окружения (если не открылось автоматически)
/root/menu.sh
# перед любыми изменениями — резервная копия сайта и базы
# (способ зависит от вашей схемы: средства меню окружения или mysqldump + архив каталога сайта)

Для обычного Linux команды такие же, как и в остальных статьях серии. На Debian и Ubuntu: apt update, затем установка обновления только для пакетов PHP. На RHEL-семействе проверяем, что вышло в security-рассылке дистрибутива, и при необходимости переключаем модуль PHP на поддерживаемую ветку. Подробности и ограничения по Sury, Remi и EOL мы разобрали в статьях про Debian и Ubuntu и CentOS, RHEL и Alma.

# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade '?name(^php[0-9.]+$)'
# если PHP работает как модуль Apache (mod_php) — нужен именно restart
sudo systemctl restart apache2
# если PHP-FPM
sudo systemctl restart php8.3-fpm

# RHEL/Alma/Rocky
dnf updateinfo list --security | grep php
sudo systemctl restart httpd    # mod_php
sudo systemctl restart php-fpm  # FPM

Важная деталь для Битрикса: классическая схема окружения — nginx спереди и Apache с PHP за ним, но у конкретной установки может быть иначе (например, PHP-FPM). Поэтому перед перезапуском проверьте, как именно запускается PHP на этом сервере. После обновления убедитесь, что старый интерпретатор не остался в памяти: команда из памяти процессов покажет «живые» воркеры со старыми библиотеками.

sudo grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps
sudo needrestart -b -r l

Старые Битрикс и сложности обновления PHP

Самое трудное — не команда обновления, а сайт, который четыре-пять лет работал на PHP 7.x и никто к его коду не прикасался. Официальные материалы 1С-Битрикс указывают на устаревание ветки PHP 7: в административной части на странице обновлений появляется сообщение о том, что для PHP 7.x исправления ошибок и уязвимостей вендор больше не выпускает. Минимальную и рекомендуемую версию PHP для вашей редакции и версии ядра берите в разделе системных требований на dev.1c-bitrix.ru: они меняются с релизами продукта, и цифры из чужих статей быстро устаревают.

Что ломается при переходе на новую ветку PHP, по нашему опыту и по публичным разборам. Во-первых, собственный код в /local/ или /bitrix/php_interface/: обработчики событий с синтаксическими ошибками, нестатические методы, которые вызывали как статические. Во-вторых, строгая типизация стандартных функций: count() от null или строки теперь вызывает ошибку, и проблема может проявляться «плавающе» только на определённых данных. В-третьих, обращение к строке как к массиву. В-четвёртых, устаревшие записи обработчиков событий в таблице b_module_to_module, которые ссылаются на классы, которых давно нет. В-пятых, обмен с 1С: в товары могут попасть неверно объявленные свойства, например массив вместо строки. И отдельно — древние сторонние модули из маркетплейса, чьи авторы перестали их поддерживать.

Расширения. Типичный набор для Битрикса — mbstring, gd, curl, mysqli, zip, opcache и другие; точный перечень смотрите в системных требованиях вашей версии. Отдельная известная ловушка — параметр mbstring.func_overload: в документации Битрикса есть отдельный урок про ошибку, которую вызывает эта настройка, и на современных версиях PHP её нужно убирать. Opcache после обновления PHP обязательно сбрасывается вместе с перезапуском, но если вы вручную правили opcache.validate_timestamps, проверьте, что новый код действительно подхватился.

Агенты и cron. Агенты Битрикса можно выполнять на хитах (по обращениям посетителей) или отдельно через cron. Если у клиента настроен cron, то у него есть команда запуска PHP в командной строке: после смены версии CLI-интерпретатор может измениться, а может и остаться старым, — это нужно проверить отдельно. Когда агенты остановились, на сайте это выглядит как «не уходят письма», «не обновляется индекс», «зависла очередь обмена». Проверьте crontab пользователя сайта и абсолютный путь к php в нём.

# какой php запускается из cron пользователя сайта
sudo crontab -u <пользователь_сайта> -l
# и какая у него версия
sudo -u <пользователь_сайта> php -v

Что мы делаем у клиентов. Не обновляем боевой сайт «в лоб». Делаем копию сайта и базы на отдельном хосте, поднимаем на ней новую ветку PHP, проходим сценарии: вход в админку, создание элемента инфоблока с фото, корзина и оформление заказа, обмен с 1С, отправка почты, запуск агентов. Журнал ошибок PHP читаем после каждого сценария. Если копию собрать нельзя, обновление откладываем до окна обслуживания и ставим временные меры. Ставить новую ветку нужно по поддерживаемому PHP, а не по самому свежему: совместимость конкретной версии ядра с PHP сверяем в документации продукта.

Временные меры и что сломается при блокировке multipart

Если обновить PHP сегодня нельзя, ставим частичные меры. Они не заменяют исправление, Gina Peter Banyard из команды PHP прямо говорит, что надёжных обходных мер нет и единственное решение — патч. Но снизить риск можно. На уровне PHP: session.upload_progress.enabled=0 в php.ini, пуле FPM или конфигурации сервера (не через ini_set и не в .user.ini) с перезапуском всех воркеров; для PHP 8.5 дополнительно fatal_error_backtraces=0. Sansec предлагает memory_limit=-1, но предупреждает о риске: один запрос сможет занять всю память сервера, так что следите за RAM. Patchstack советует задавать значения через php_admin_value, чтобы приложение не могло их переопределить, и ограничивать post_max_size и upload_max_filesize на веб-сервере или прокси.

Самая жёсткая мера — запретить multipart/form-data на веб-сервере. Для nginx это условие по заголовку Content-Type с ответом 403, для Apache — RewriteCond по HTTP:Content-Type с флагом F. Работает, но цена высока: ломается всё, что отправляет данные в этом формате. На Битриксе таких мест много. В таблице — что именно мы проверяем после включения блокировки.

Поэтому порядок такой: включаем блокировку в нерабочее время, сразу прогоняем таблицу, а на сайте интернет-магазина первым делом оформляем тестовый заказ. Если заказ не проходит, откатываем правило и ищем другую меру. Для обмена с 1С в ряде схем передача идёт не через multipart, но надёжнее убедиться тестом, а не предположением. Дальше выбираем: ограничить блокировку только публичными адресами (админку при этом открывать только с доверенных IP) либо оставить только GET/HEAD на время простоя. Режим обслуживания в Битриксе и закрытие сайта настройкой продукта не помогают: PHP разбирает запрос раньше. Подробнее о мерах — в обзорной статье серии.

Проверка после обновления, типичные ошибки и мини-кейс

После обновления проходим короткий чек-лист. Версия PHP веб-части — исправленная, а не только CLI. Сервисы перезапущены, старые воркеры не остались в памяти. Страница проверки системы в админке Битрикса не показывает критичных предупреждений. Журнал ошибок PHP чистый после тестовых сценариев. Агенты и cron работают. Временные меры, которые мешают работе (например, блокировка multipart), сняты, как только исправление применено. Если были временные меры на уровне PHP, их можно оставить как дополнительный слой, но не как оправдание отложенного патча.

Типичные ошибки у владельцев сайтов на Битриксе. Обновили пакет, но не перезапустили mod_php. Поправили php.ini не того интерпретатора (CLI вместо веб). Положились на проактивную защиту. Включили блокировку multipart и забыли про загрузку фото и заказы. Поставили новую ветку PHP на старое ядро без копии сайта. Оставили забытую копию сайта на поддомене. Поставили сниппет с форума в init.php. Все эти варианты мы видели в похожих задачах, и каждый приводит либо к остановке сайта, либо к ложному чувству безопасности.

Мини-кейс (условный, без цифр результатов). Сеть салонов «Мебельный Квартал», 22 рабочих места: интернет-магазин на 1С-Битрикс «Управление сайтом» и закрытый портал сотрудников на отдельной машине. Исходная ситуация: магазин работает на одном окружении, портал забыт и работает на PHP 7.x. Наш подход: инвентаризация обоих PHP, затем копия магазина на тестовом хосте с новой веткой PHP и прогоном сценариев — админка с фото, заказ, обмен с 1С, агенты. Портал, который нельзя быстро обновить, закрываем от интернета до обновления: доступ только по VPN и с доверенных адресов. Проверяем журналы за последние дни, и если есть подозрения на компрометацию, передаём владельцу список ключей и паролей на ротацию: пароли живых учётных записей сами не меняем.

Если на сервере хранились ключи или пароли (подключение к базе в настройках, ключи платёжных интеграций, токены обмена), а подозрение на эксплуатацию есть, считайте сервер возможно скомпрометированным: готовим перечень секретов к ротации и отдаём владельцу; решение о смене принимает он. Если систему обновить нельзя и меры не помогают, рассмотрите отключение сайта от интернета до решения — это тоже рекомендация NCSC. Нужна помощь с миграцией Битрикса на поддерживаемую ветку PHP или с чисткой окружения — смотрите нашу услугу внедрение и сопровождение open source и веб-систем.

Частые вопросы