Что делать тем, у кого сайт на Битрикс?
Когда информация об уязвимостях появилась, часть пользователей ошибочно связала проблему с самой CMS „1С-Битрикс“. Причина — компания „1С-Битрикс“ одной из первых начала массово рассылать предупреждения клиентам, и некоторые восприняли это как сигнал об уязвимости в коде Битрикс. На самом деле ошибка находится во внешнем серверном компоненте — PHP, а не в коде продуктов „1С-Битрикс“. Это прямо указано в официальном уведомлении вендора.
Причина - одни из первых в русскоязычном интернете команда Битрикс с целью заботы о своих клиентах стало массово рассылать предупреждения, некоторые пользователи увидели новости и и автоматически связали проблему с самой CMS.
Ошибка не в коде Битрикс, а в серверной технологии, но риск высокий
Если у вас облачный Битрикс24 (Cloud), делать ничего не нужно. Безопасность облачной инфраструктуры, включая обновление PHP, операционной системы и закрытие критических уязвимостей, полностью лежит на инженерах и службе безопасности „1С-Битрикс“. Облачный сервис уже работает в штатном режиме: файлы загружаются, функции доступны, обновления на серверы вендора установлены и проверены.
Облачный Битрикс24 уже работает в обычном режиме: файлы загружаются, все функции на месте. Уже установлены обновления на собственные сервера и проверено, что всё работает безопасно. Команда Битрикс уже позаботилась о том, чтобы ваши данные оставались в безопасности, пока закрывала угрозу.
Если у вас коробочный Битрикс24 или сайт на „1С-Битрикс: Управление сайтом“, PHP на сервере нужно обновить отдельно. Обновление через SiteUpdate эту задачу не решает. Исправления вошли в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Это официальные целевые версии, рекомендованные командой PHP.
Как действовать?
Готовые пакеты появляются в репозиториях не одновременно. Обычная проверка обновлений может ещё не показать исправленную версию. При этом сторонние репозитории (например, remi) уже выпустили сборки поддерживаемых версий. Если исправленного пакета в вашем репозитории нет, установите совместимые пакеты вручную.
При этом репозиторий remi уже выпустил сборки всех поддерживаемых версий.
Если исправленного пакета нет в вашем репозитории, нужно установить совместимые исправленные пакеты вручную.
Важно: успешное выполнение команды обновления не гарантирует, что уязвимость устранена. Нужно проверить, какая сборка PHP фактически обслуживает сайт. Это можно сделать через phpinfo() или командой php -v в окружении веб-сервера.
Порядок обновления BitrixVM 9.x
Шаг 1. Подготовка
- Проверьте наличие резервной копии сайта, базы данных и конфигурации сервера.
- По возможности сначала выполните проверку совместимости обновления в тестовом окружении.
Шаг 2. Проверка репозиториев
- Обновите сведения о пакетах.
- Проверьте, доступна ли исправленная версия PHP в подключённых репозиториях.
Шаг 3. Установка обновления
- Установите обновление PHP вместе с необходимыми зависимостями.
- Если исправленных пакетов в репозитории ещё нет, используйте ручную установку совместимых пакетов.
Шаг 4. Перезапуск веб-сервера
Если у вас конфигурация с Apache и модулем PHP, перезапустите Apache:
systemctl restart httpd.service
Шаг 5. Проверка после обновления
Убедитесь, что сайт действительно использует исправленную сборку PHP.
Проверьте:
- авторизацию;
- работу CRM;
- загрузку файлов;
- почту;
- интеграции.
Не запутаться поможет короткий чек-лист
- Есть резервная копия сайта, базы данных и конфигурации сервера.
- Совместимость обновления проверена в тестовом окружении.
- Обновлены сведения о пакетах.
- В репозитории доступна исправленная версия PHP.
- PHP обновлён до целевой версии.
- При необходимости выполнена ручная установка совместимых пакетов.
- Службы, исполняющие PHP, перезапущены (Apache при mod_php, PHP-FPM при Nginx + PHP-FPM).
- Проверено, что сайт фактически работает на исправленной сборке PHP.
А что делать владельцам других платформ?
Уязвимости затрагивают все установки PHP, обрабатывающие веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Наибольший риск представляет mod_php: подтверждённый эксплойт срабатывает до того, как выполнится какой-либо код приложения, — то есть защитные механизмы самого сайта не успевают включиться.
Под угрозой оказались миллионы сайтов по всему миру, использующие PHP (WordPress, Drupal, Joomla).
Общие рекомендации
1. Обновите PHP. Это можно сделать пакетным менеджером дистрибутива или пересборкой Docker-образа. Убедитесь, что устанавливаете следующие или более новые релизы: 8.5.x → 8.5.12; 8.4.x → 8.4.27; 8.3.x → 8.3.36; 8.2.x → 8.2.35. Для контейнеров обновите или пересоберите образ с исправленной версией PHP и пересоздайте контейнеры, сохранив конфигурацию и тома. Перед удалением старых контейнеров проверьте сохранность данных: файлы в записываемом слое удаляются вместе с контейнером.
Для устаревших веток (7.4, 8.0, 8.1) команда PHP предоставила исправления на уровне исходного кода, однако наличие готовых пакетов в репозиториях полностью зависит от конкретного вендора.
2. Перезапустите воркеры. После обновления пакетов уязвимость остаётся активной, пока старые процессы находятся в памяти. Для Apache с mod_php: systemctl restart httpd.service. Для Nginx + PHP-FPM: systemctl restart php-fpm.service. Перезапуска одного Nginx недостаточно — это самая частая ошибка администраторов.
3. Если используется PHP 8.1 или старше. Эти ветки больше не получают обновлений от команды PHP. Для 7.4, 8.0 и 8.1 опубликованы только минимальные патчи исходного кода, а не готовые пакеты. Если ваш дистрибутив или LTS-вендор не предоставляет исправленную сборку, рекомендуется перейти на поддерживаемую ветку (8.2+).
4. Пока сервер не пропатчен, снимите его с публичного доступа и примените частичные меры. Важно: обновление — единственное полное решение; перечисленные меры только сокращают поверхность атаки, но не делают установку безопасной.
Для CVE-2026-109619: отключите session.upload_progress.enabled = 0. Если используется PHP-FPM, продублируйте настройку через php_admin_flag, чтобы приложение не могло её переопределить.
Для CVE-2026-109618: установите memory_limit = -1 (предпочтительно через php_admin_value) и низкий post_max_size: 8M, если загрузка файлов не нужна, или 32M, если нужна. Убедитесь, что upload_max_filesize меньше post_max_size.
Почему правим: Убрана опечатка «целессобразно». Главное — добавлено критическое уточнение, что это не полная защита, а частичная мера. PHP прямо предупреждает об этом, и SANS называет настройку session.upload_progress именно «partial mitigation». Без этого уточнения читатель может решить, что отключения одной опции достаточно. Также добавлены рекомендации по memory_limit и post_max_size для второй уязвимости — в исходном тексте их не было, хотя PHP их официально рекомендует.
5. После обновления проверьте логи. В фокусе — подозрительно большие куки PHPSESSID (PoC использовал filename размером около 5 МБ) и падения воркеров. Если сервер был доступен из интернета без патча, проведите проверку на признаки компрометации. При обнаружении любых признаков ротируйте хранимые учётные данные: пароли к базам данных, API-ключи, токены интеграций.
Для устаревших веток 7.4, 8.0 и 8.1 команда PHP опубликовала минимальные патчи исходного кода, а не готовые релизы. Наличие пакетов в репозиториях зависит от дистрибутива или LTS-вендора. Уточните у поставщика, выпустил ли он исправленную сборку. Если нет — обновляйтесь на поддерживаемую ветку или собирайте PHP из исходников с патчем.
Важно! Не допустите ошибки при перезапуске служб. Перезапуска одного Nginx, к сожалению, недостаточно! Это самая частая ошибка администраторов. Если вы обновили бинарные файлы пакетом, но не перезапустили службы, старые уязвимые процессы в памяти продолжат обслуживать запросы сайта.
Проверенные решения:
Для связки с Apache (mod_php): systemctl restart httpd.service
Для связки Nginx + PHP-FPM: systemctl restart php-fpm.service
Что делать, если некому обновить сервер прямо сейчас?
Ошибка в одной команде, пропущенный процесс в памяти или отсутствие свежего бэкапа могут полностью «уронить» сайт, парализовать продажи и привести к потере данных.
Если у вас в штате нет опытного системного администратора или ваш подрядчик занят - не рискуйте безопасностью бизнеса и доверьте заботу о безопасности своего сайта нам.
Мы возьмем всю техническую часть на себя:
- Сделаем безопасные бэкапы сайта, базы данных и конфигурации.
- Проверим репозитории и обновим PHP до безопасной версии (включая ручную установку, если пакетов еще нет в вашей системе).
- Правильно перезапустим все скрытые службы и воркеры.
- Проверим работу критически важных функций сайта (авторизация, CRM, оплаты, интеграции).
Свяжитесь с нами, чтобы закрыть уязвимость до того, как её начнут массово эксплуатировать. PoC-эксплойты уже опубликованы, и Cloudflare сообщал об атаках до выхода патча.
