Как закрыть критические уязвимости PHP на сайте с 1С‑Битрикс

21 октября вышли PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35 с исправлением 2 критических уязвимостей, через которые сервер взламывают без пароля. Пишу, как узнать версию PHP вашего сайта, почему SiteUpdate тут не поможет, что делать на PHP 7.4–8.1 и как проверить сайт на следы взлома.

21 октября 2026 года разработчики PHP выпустили внеплановые версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Они закрывают 2 критические уязвимости, CVE-2026-109618 и CVE-2026-109619, через которые можно выполнить код на сервере без авторизации. Уязвимы все версии PHP с 5.4, а значит, почти каждый сайт на 1С-Битрикс, который еще не обновил PHP.

Коротко, что делать владельцу сайта: в ближайшие дни обновить PHP на сервере до исправленной версии своей ветки, перезапустить PHP и проверить, что сайт работает. Обновление 1С-Битрикс через SiteUpdate здесь не поможет: уязвимость не в коде платформы, а в самом PHP. Если сайт работает на PHP 7.4, 8.0 или 8.1, задача сложнее, и ниже я расписал, как с ней быть.

Что случилось и почему это касается вашего сайта

Обе уязвимости находятся в ядре PHP, в обработке загрузок с отслеживанием прогресса (session.upload_progress). Эта функция включена по умолчанию и срабатывает на любой POST-запрос с загрузкой формы еще до того, как запустится код сайта. Поэтому не важно, на какой CMS сайт и есть ли на нем формы загрузки файлов.

Обе уязвимости оценены в 9,2 балла по шкале CVSS 4.0 — это критический уровень. В уведомлении на php.net разработчики пишут, что под угрозой все установки PHP, которые обслуживают веб-запросы: PHP-FPM, Apache с mod_php, php-cgi и другие. Самым опасным они называют mod_php: для него продемонстрирован эксплойт, который срабатывает от запроса без авторизации.

Для сайтов на 1С-Битрикс это особенно неприятно. Стандартное окружение BitrixVM работает на Apache с mod_php — как раз в группе максимального риска. Центр кибермониторинга 1С-Битрикс 21.10.2026 отдельно предупредил клиентов: обновлять нужно PHP на сервере, обновление продукта эту процедуру не заменяет.

Атаки уже идут. По данным SecPost на 21.10.2026, исследователи фиксируют первые попытки эксплуатации, а в открытом доступе появились рабочие эксплойты. Сколько сайтов уже взломано, на момент написания статьи неизвестно.

Как узнать, какая версия PHP у вашего сайта

Начать нужно с версии, которая реально обслуживает сайт. Тут легко ошибиться: на сервере часто стоит несколько версий PHP, и команда в консоли показывает одну, а сайт работает на другой.

Самый надежный способ — спросить у самого сайта. Положите в корень временный файл, откройте его в браузере и сразу удалите:

<?php
// Временный файл: показать версию PHP и режим работы, затем удалить
echo PHP_VERSION, ' ', PHP_SAPI;

Ответ вида 8.3.35 apache2handler значит: PHP 8.3, работает как модуль Apache, версия еще не исправлена. Ответ 8.3.36 fpm-fcgi — исправленная версия под PHP-FPM. Файл после проверки удалите, оставлять его на сайте нельзя.

Если сайт на виртуальном хостинге, версию видно в панели хостинга, а обновлением занимается хостер. Тогда ваша задача — написать в поддержку и получить ответ, когда исправленная сборка будет установлена. Если сайт на своем VPS или выделенном сервере, обновлять будет ваш администратор или подрядчик по поддержке.

Для веток 8.2–8.5 вопрос решается за один рабочий день. Для старых веток это отдельный проект, о нем ниже.

Как обновить PHP на сервере с 1С‑Битрикс

Обновление внутри своей ветки, например с 8.3.35 на 8.3.36, обычно не ломает сайт: меняются исправления, а не поведение языка. Но делать его вслепую не стоит. Порядок такой.

1. Резервная копия. Полная копия файлов и базы, лучше на другом сервере. Если обновление пойдет не так, откат займет минуты.
2. Проверка на тестовой копии. Для сайтов со своим кодом и интеграциями сначала обновите PHP на копии и пройдите главные сценарии. Для простого сайта внутри одной ветки этот шаг можно сократить.
3. Обновление пакета PHP. Исправленные пакеты появляются в репозиториях дистрибутивов не одновременно: где-то в день выхода, где-то позже. Если пакета еще нет, администратор собирает PHP из исходников или берет сборку из другого проверенного репозитория.
4. Перезапуск PHP. Без него сервер продолжит работать на старой версии из памяти. При mod_php перезапускается Apache, при PHP-FPM — все пулы. Перезапуска одного nginx недостаточно.
5. Проверка сайта. Авторизация, формы, корзина и оплата, загрузка файлов, отправка почты, обмен с 1С, связь с CRM. 1С-Битрикс в своих рекомендациях перечисляет те же пункты.

Для BitrixVM 9.x команда перезапуска после обновления пакетов выглядит так (на нескольких серверах — на каждом):

# проверить версию в консоли после обновления пакетов
php -v
# перезапустить Apache, который обслуживает PHP в BitrixVM
systemctl restart httpd.service

После перезапуска еще раз откройте временный файл с версией из предыдущего раздела. Успешная команда обновления сама по себе ничего не доказывает: 1С-Битрикс прямо предупреждает, что нужно проверить, какая сборка PHP реально обслуживает сайт.

Если сайт работает в Docker, обновлять пакет внутри контейнера бессмысленно. Нужно пересобрать образ на исправленной версии PHP и пересоздать контейнеры, сохранив тома с данными.

Если обновить прямо сейчас нельзя

Бывает, что администратор будет только завтра, а хостер обещает пакет через неделю. Для этого случая разработчики PHP дают временные меры. Главная из них — отключить отслеживание прогресса загрузки:

; временная мера до обновления PHP, затем перезапуск PHP
session.upload_progress.enabled = Off

Настройка задается в php.ini или в конфигурации пула PHP-FPM, после чего перезапускаются все процессы PHP. Через ini_set() в коде сайта или через .user.ini она не работает. В BitrixVM 9.x 1С-Битрикс рекомендует файл /etc/php.d/z_bx_custom.ini.

Это закрывает путь атаки через CVE-2026-109619, но не полностью закрывает CVE-2026-109618. Для нее на php.net перечислены свои меры, связанные с лимитами памяти, и они требуют аккуратной настройки под конкретный сервер. Сами разработчики PHP пишут прямо: временные меры снижают риск, но не делают установку безопасной. 1С-Битрикс тоже предупреждает, что отключение session.upload_progress обновление PHP не заменяет.

Функция нужна, чтобы сервер отдавал прогресс загрузки больших файлов. На многих сайтах она не используется, но после изменения все равно проверьте загрузку файлов в админке и формах.

Если сайт обрабатывает платежи или персональные данные, а обновление откладывается на дни, есть смысл временно ограничить доступ к нему из интернета. Это тяжелое решение для бизнеса, но взлом обходится дороже.

Что делать, если сайт на PHP 7.4, 8.0 или 8.1

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

Вариантов 2. Первый — сборка с исправлением от поставщика ОС или LTS-поставщика, если ваш дистрибутив еще поддерживает эту версию PHP. Второй — переход на PHP 8.2 и новее.

Я считаю, что первый вариант — только способ выиграть время. Старая ветка все равно не получает другие исправления безопасности, и следующая уязвимость снова поставит вас в ту же ситуацию. К тому же ветка 8.2 по объявлению php.net перестанет получать исправления 31 декабря 2026 года, так что переходить разумнее сразу на 8.3 или 8.4.

Переход между основными версиями — уже не обновление пакета, а работа с кодом. Ядро 1С-Битрикс поддерживает современные версии PHP, если сайт регулярно обновлялся. Ломаются обычно свой код, старые модули сторонних разработчиков и шаблоны, которые давно не трогали. Если ядро тоже не обновлялось годами, сначала придется обновить его, и это отдельный этап. Порядок и типичные ошибки описаны в статьях о том, как обновить 1С-Битрикс без простоя и какие бывают ошибки при обновлении.

Сроки здесь сильно зависят от сайта. Моя оценка: корпоративный сайт на свежем ядре с небольшим количеством своего кода переходит на новую ветку за 1–3 рабочих дня с проверкой. Магазин с интеграциями и модулями, которые не обновлялись несколько лет, может потребовать 1–2 недели. Точнее можно сказать только после проверки кода.

Как проверить, не взломали ли сайт до обновления

Между выходом эксплойтов и вашим обновлением прошло какое-то время, поэтому после обновления стоит убедиться, что сайт не успели взломать. Обновление закрывает дыру, но не удаляет то, что уже могли оставить на сервере.

• Администраторы. Список пользователей с правами администратора в 1С-Битрикс: нет ли новых или незнакомых.
• Измененные файлы. Файлы PHP, измененные с 20–21 октября, особенно в папках загрузок и кеша, где PHP-файлов быть не должно.
• Задания по расписанию. Новые задания cron на сервере и агенты в 1С-Битрикс.
• Поведение сайта. Странные редиректы, чужие страницы в поиске, спам-рассылки с вашего домена, рост нагрузки на сервер без видимой причины.

Для поиска измененных файлов в 1С-Битрикс есть встроенный сканер безопасности и контроль целостности. Как действовать, если что-то нашлось, подробно описано в статье о том, как проверить сайт на вирусы и убрать заражение. Главное правило: если следы взлома есть, не ограничивайтесь удалением вредоносных файлов, а смените все пароли и ключи доступа.

Что сделать сегодня

Узнайте версию PHP вашего сайта и спросите у администратора или хостера, когда будет установлено исправление. Если ответа нет до конца недели, включите временную меру и готовьтесь обновляться сами. Мы в Design Lab после таких уведомлений начинаем с инвентаризации: какая версия PHP и в каком режиме работает на каждом сервере, где хватит обновления пакета, а где нужен переход на новую ветку. Если хотите, начнем этот разговор с вашего сайта: так устроена наша поддержка сайтов на 1С-Битрикс.