Критические уязвимости PHP: как проверить и обновить сервер Битрикс24 или 1С-Битрикс

24 октября, суббота. Чем заняться на выходных? Понятно чем: обновлять около сотни серверов - наших и клиентских.

Причина - не очередное обновление Битрикс24. В PHP нашли критические уязвимости, а 21 октября вышли исправления. Если коробочный Битрикс24 или сайт на «1С-Битрикс: Управление сайтом» работает на вашем сервере, обновить нужно именно серверный PHP. Кнопки обновления Битрикс для этого недостаточно.

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

Ниже - порядок действий для владельца системы и её администратора. Отдельно разберём серверы со старым PHP 7.4.

Что сделать прямо сейчас

Если у вас коробочный Битрикс24 или сайт на 1С-Битрикс, свяжитесь со специалистом, который обслуживает сервер. Не ограничивайтесь вопросом «Битрикс обновлён?». Запросите четыре конкретных ответа:

1. Какая версия и сборка PHP действительно обрабатывает запросы сайта или CRM?
2. Есть ли для неё исправления из надёжного источника и какие уязвимости они закрывают?
3. Как будут сделаны резервная копия, обновление и проверка совместимости? Что делать при сбое?
4. Чем подтверждено, что исправленный PHP уже работает, а основные функции системы не пострадали?

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

Главное различие: обновление модулей Битрикс и обновление PHP на сервере - две разные операции.

Быстрая проверка PHP через браузер

Чтобы быстро понять, какой PHP реально выполняет запросы сайта, мы сделали отдельный проверочный PHP-файл. Он пригодится для первичной диагностики коробочного Битрикс24 и сайта на 1С-Битрикс, когда нет времени сначала разбирать всю конфигурацию сервера.

Скачать ZIP с PHP-проверкой. В архиве один файл php-security-check.php и инструкция.

Как запустить:

1. Распакуйте ZIP и откройте php-security-check.php в текстовом редакторе.
2. Замените пароль по умолчанию в строке const CRM4_CHECK_SECRET = 'LOG-IN-OFF-PHP-2026-CHECK!'; на свой уникальный пароль длиной от 24 символов. Исходный пароль в архиве - LOG-IN-OFF-PHP-2026-CHECK!. Он общедоступен, поэтому не защищает файл от посторонних.
3. Поместите PHP-файл в веб-каталог проверяемого сайта, использующий тот же обработчик PHP, что и Битрикс24 или 1С-Битрикс.
4. Откройте в браузере адрес вида https://ваш-домен.ru/php-security-check.php, введите заданный пароль и посмотрите отчёт.
5. После проверки удалите PHP-файл с сервера. Для доступа к диагностике используйте HTTPS, а по возможности дополнительно ограничьте доступ по IP или VPN.

Проверка покажет фактическую версию веб-PHP и сопоставит её с официальными выпусками, исправленными 21 октября 2026 года. Отдельно она покажет значение session.upload_progress.enabled для предупреждения от 23 октября.

Важно: это быстрая проверка версии и настройки, а не сканер, доказывающий отсутствие уязвимостей. Скрипт не проверяет двоичный код PHP, backport-патчи поставщика, остальные PHP-пулы и возможный взлом. Для PHP 7.4 и сборок с backport нужен отдельный анализ версии пакета и уведомлений поставщика.

Что произошло с PHP 21 и 23 октября

21 октября 2026 года разработчики PHP выпустили исправления для двух критических уязвимостей:

• CVE-2026-109618 - ошибка при нехватке памяти, которая может повредить внутреннее состояние PHP.
• CVE-2026-109619 - ошибка обращения к данным запроса после освобождения памяти.

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

Для этих двух CVE первые исправленные официальные версии следующие:

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

23 октября PHP опубликовал отдельное уведомление - CVE-2026-115560. Оно связано с механизмом отслеживания загрузки файлов через сессии (session upload progress) при особом сочетании настроек и поведения приложения. По состоянию на 24 октября PHP рекомендует временно отключить session.upload_progress.enabled до выхода исправления.

Здесь важно не перепутать задачи: выпуски от 21 октября устраняют первые две CVE, но не следует считать их исправлением CVE-2026-115560. А отключение upload progress не заменяет установку исправлений от 21 октября.

Источники: официальный архив выпусков и уведомлений PHP и инструкция 1С-Битрикс. Рекомендации могут обновляться - проверяйте их перед работами.

Кого касается проблема

Ошибки нашли в PHP, а не в коде Битрикс24 или 1С-Битрикс. Но продукты, использующие уязвимую сборку PHP, тоже могут быть под угрозой.

Обычный SiteUpdate обновляет компоненты продукта Битрикс. Системный PHP обновляется отдельно - средствами операционной системы, поставщика серверного окружения или контейнерной инфраструктуры.

И ещё одна деталь для администратора: на одном сервере могут работать сразу несколько версий PHP. Сайт, административные скрипты и задания по расписанию иногда используют разные экземпляры. Проверить только один - недостаточно.

Как проверить PHP, на котором работает сайт

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

1. Определите способ запуска PHP.
Возможны модуль Apache (mod_php), отдельная служба PHP-FPM за nginx или Apache, другой обработчик, контейнер. От этого зависит и пакет для обновления, и нужный перезапуск.

2. Проверьте PHP в терминале, но не делайте вывод только по нему.

php -v

Команда показывает PHP для командной строки (CLI). Веб-сервер может использовать другую сборку или другой PHP-FPM-пул. Задания cron тоже нужно учитывать отдельно.

3. Установите фактическую веб-версию.
Сопоставьте диагностику приложения с конфигурацией веб-сервера, PHP-FPM и установленными пакетами. Если создаёте временную страницу с phpinfo(), ограничьте доступ к ней и удалите после проверки: такой файл раскрывает детали сервера.

4. Проверьте происхождение пакета и наличие исправления.
Поставщик Linux может перенести патч в старую ветку PHP, не меняя базовый номер версии. Это называется backport. Например, число 7.4.33 само по себе не доказывает ни наличие, ни отсутствие конкретного патча. Нужны сведения о ревизии пакета, журнале изменений или официальном уведомлении поставщика.

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

Как безопасно установить исправления

Одной команды для всех серверов не существует. Порядок зависит от операционной системы, репозиториев, версии BitrixVM и способа запуска PHP. Но безопасная последовательность общая.

Шаг 1. Зафиксировать исходное состояние и подготовить откат

Запишите используемые версии PHP и расширений, настройки веб-сервера, службы PHP-FPM, задания cron, интеграции и все узлы, принимающие запросы.

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

Шаг 2. Выбрать исправленный пакет

Для поддерживаемых веток ориентируйтесь на официальные исправленные выпуски либо документированный backport вашего поставщика. Проверьте источник пакета и совместимость с версией Битрикс, модулями, PHP-расширениями и собственным кодом.

Обновить PHP внутри текущей ветки и перейти с PHP 7.4 на новую основную ветку - задачи разной сложности. Их не стоит смешивать в одно срочное действие.

Шаг 3. Провести обновление под контролем

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

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

Шаг 4. Перезапустить работающий PHP

После установки пакета проверьте, что запросы больше не обслуживают старые PHP-процессы.

• Apache с mod_php: требуется перезапуск Apache. Для типовой BitrixVM 9.x в инструкции 1С-Битрикс приведена команда systemctl restart httpd.service, но сначала убедитесь, что ваша конфигурация соответствует этому случаю.

• PHP-FPM: перезапустите нужную службу PHP-FPM и проверьте её состояние. Перезапуск только nginx не заменяет перезапуск PHP-FPM.

• Контейнеры: обновите или пересоберите образ и пересоздайте рабочие контейнеры штатным способом. Перед заменой проверьте сохранность данных и конфигураций вне временного слоя контейнера.

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

Шаг 5. Проверить обновление и работу приложения

Повторно определите PHP, который действительно отвечает на веб-запросы. Подтвердите исправления для этой сборки, затем проверьте авторизацию, основные операции CRM или сайта, загрузки файлов и интеграции.

Установить пакет недостаточно. Результат - исправленный PHP в работе и исправно действующее приложение.

Если сервер до сих пор работает на PHP 7.4

У PHP 7.4 закончилась официальная поддержка. Но на такой версии ещё могут работать сайты и коробочные порталы с собственными модулями, интеграциями и кодом, который нельзя без проверки перенести на новую ветку.

Здесь две задачи.
Сейчас - устранить конкретные октябрьские уязвимости.
Проверьте, есть ли у дистрибутива, хостинга или поставщика расширенной поддержки подтверждённая исправленная сборка PHP 7.4. Если есть, подготовьте и установите её контролируемо. Если нет, требуется индивидуальный план снижения риска.

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

Затем - уйти с неподдерживаемой ветки.
Даже исправление октябрьских CVE не возвращает PHP 7.4 официальную поддержку и не устраняет другие возможные проблемы безопасности. Нужна проверка совместимости и план миграции окружения.

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

О более широкой задаче миграции инфраструктуры мы писали в статье «Обновление сервера коробочного Битрикс24». Здесь же речь о срочной реакции на уязвимости PHP.

Отдельная временная мера из уведомления 23 октября

До выхода следующего исправления PHP рекомендует отключить механизм отслеживания прогресса загрузки файлов через сессии:

session.upload_progress.enabled = Off

Речь о CVE-2026-115560. По сообщению PHP, этот сценарий требует необычного сочетания: приложение меняет обработчик сериализации сессий во время выполнения перед session_start(), а отслеживание прогресса загрузки остаётся включённым. Это не универсальная защита от всех RCE.

Настройка должна действовать до обработки веб-запроса. Для этой защитной меры не полагайтесь на ini_set() в коде или на .user.ini при использовании PHP-FPM: они могут применяться слишком поздно. Используйте конфигурацию php.ini, PHP-FPM-пула или веб-сервера, действующую до обработки запроса.

После изменения перезапустите нужные PHP-процессы и проверьте эффективное значение параметра для веб-сайта. Для типовой BitrixVM 9.x производитель указывает файл /etc/php.d/z_bx_custom.ini; в других окружениях путь может отличаться.

Затем протестируйте загрузку файлов и связанные функции приложения. Если механизм upload progress нужен вашему коду, оцените последствия его отключения вместе с разработчиком или администратором.

Важно: настройка Off не заменяет исправления CVE-2026-109618 и CVE-2026-109619 от 21 октября. Исправления от 21 октября, в свою очередь, нельзя автоматически считать решением для CVE-2026-115560. Следите за официальными уведомлениями PHP.

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

Просите не отчёт «PHP обновили», а проверяемый результат.
По серверу:

• Учтены все серверы, рабочие контейнеры, PHP-FPM-пулы и дополнительные веб-узлы.
• Для каждого затронутого веб-PHP подтверждена исправленная версия или документированный backport для уязвимостей от 21 октября.
• После установки перезапущены нужные процессы; веб-приложение действительно использует исправленную сборку.
• Отдельно оценено предупреждение от 23 октября; нужная временная настройка применена и проверена.
• Сохранены сведения об изменениях, резервная копия и план восстановления.

По работе Битрикс или сайта:

• Открываются сайт или портал, пользователи входят в систему.
• Для Битрикс24 работают используемые компанией лиды, сделки, задачи, бизнес-процессы и уведомления.
• Работают загрузка файлов, почта, задания по расписанию и критичные интеграции.
• Для интернет-магазина или сайта проверены формы, личный кабинет и, если применимо, оформление заказа и оплата.
• Если есть несколько веб-узлов, проверка охватывает их все.

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

Сохраните журналы и другие свидетельства, ограничьте дальнейший доступ и привлеките специалиста по реагированию. Обновление PHP само по себе не удаляет уже внедрённый вредоносный код.

Если нужна помощь с сервером - обращайтесь к нам в Лабораторию автоматизации «LOG [IN] OFF»

Мы обслуживаем серверы с коробочным Битрикс24 и сайтами на «1С-Битрикс: Управление сайтом», в том числе системы, которые пока зависят от PHP 7.4.

Можем проверить конфигурацию, выяснить, какой PHP действительно работает, подобрать путь исправления, подготовить резервную копию и план изменений, выполнить обновление и проверить систему после него. Если безопасное исправление упирается в устаревшее окружение, отдельно спланируем миграцию.

Не знаете, устранены ли уязвимости на вашем сервере? Свяжитесь с нами. Для начала достаточно указать продукт, способ размещения и кто обслуживает инфраструктуру. Пароли и другие секреты отправлять не нужно.

Хороший результат обновления - два конкретных ответа: уязвимости устранены? и система после изменений работает?

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