PHP готовит исправление двух критических уязвимостей: что проверить пользователям Битрикс

Команда PHP 20 октября предупредила о подготовке обновления безопасности. Релиз запланирован на 21 октября в 17:00 по московскому времени. Оно должно устранить две критические уязвимости, каждой присвоена оценка CVSS v4.0 9.2.

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

Что известно о возможной атаке

CERT-EU связывает предварительные сведения с CVE-2026-109618 и CVE-2026-109619 и упоминает возможное удаленное выполнение кода. Однако сам бюллетень отмечает, что технические детали пока не опубликованы, а информация об удаленном выполнении кода и широком диапазоне затронутых версий основана на утечках.

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

Что это означает для Битрикс

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

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

В облачном Битрикс24 серверное окружение обслуживает сам Битрикс24. Пользователю не нужно самостоятельно менять php.ini или устанавливать серверные пакеты. При этом собственные PHP-серверы клиента, на которых работают внешние сайты, приложения и интеграции, необходимо проверять отдельно.

Что сделать до публикации патча

• Провести инвентаризацию PHP на всех серверах, контейнерах, PHP-FPM-пулах и балансировочных узлах. Версия командной строки может отличаться от той, которую использует веб-приложение.
• Проверить резервное копирование, порядок установки пакетов и возможность отката.
• Уточнить у хостинг-провайдера, когда исправленный пакет появится в его репозитории.
• Оценить внешнюю доступность приложения. Если риск для организации неприемлем, до выхода исправления можно рассмотреть временное ограничение доступа через VPN, список разрешенных адресов или другие сетевые средства.
• Не полагаться только на пароли, двухфакторную аутентификацию, проактивный фильтр и другие механизмы приложения: они не устраняют уязвимость PHP.
• Не устанавливать неофициальные исправления и не считать предварительные номера сборок окончательными.

Полностью запрещать запросы multipart/form-data без предварительного тестирования не рекомендуется: это может нарушить загрузку документов, изображений и работу форм.

Настройка session.upload_progress.enabled

В предварительных публикациях советуют отключить параметр session.upload_progress.enabled, который записывает в сессию сведения о ходе загрузки файлов. Он включен по умолчанию и имеет режим INI_PERDIR, поэтому вызов ini_set() в коде приложения не является корректной заменой серверной настройке.

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

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

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

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

Исходный релиз PHP может появиться раньше, чем пакет станет доступен в репозитории операционной системы или у хостинг-провайдера. Старые ветки PHP 5.x, 7.x, 8.0 и 8.1 находятся вне обычной поддержки. Для них потребуется переход на поддерживаемую версию либо документированное исправление от поставщика, который продолжает сопровождать устаревшую ветку.

После обновления нужно убедиться, что все работающие веб-процессы на каждом узле используют исправленную сборку. Затем следует проверить вход в систему, загрузку файлов, Диск, задачи, CRM, формы, заказы, интеграции и нестандартные компоненты. Это относится и к окружению BitrixVM: обновление продукта через SiteUpdate само по себе не подтверждает обновление серверного PHP.