Реальный patch level 1С-Битрикс: проверяем каждый модуль

Вижу знакомую картину: в панели зелёная галка, main выглядит свежим, а отвечающий за сайт администратор всё равно не может сказать, закрыта ли конкретная дыра в fileman, iblock или партнёрском импортере. Я, Семёнов Евгений Сергеевич, директор ООО «АйТи-Фреш», в такой ситуации не принимаю скриншот админки как доказательство. Ниже покажу, как снимаю фактический состав кода, сопоставляю каждую версию с security floor и отделяю реальную угрозу RCE или чтения файлов от общего тревожного шума.

Версия продукта есть, но общего security patch level — нет

Версия main — это версия Главного модуля, а не контрольная сумма всей установки. fileman, iblock, landing, sale, vote и десятки других модулей имеют собственные номера и собственные цепочки обновлений. Партнёрские решения живут ещё в одном контуре. Поэтому мой patch level выглядит не как «26.700.0», а как вектор: main=26.700.0; fileman=26.0.0; iblock=26.0.0; landing=26.1100.0; vendor.module=1.2.3. К этому вектору обязательно добавляются путь к реально загружаемому коду и результат проверки целостности.

Зелёный результат свежей проверки SiteUpdate полезен, но его область надо читать буквально: сервер обновлений не предложил платформенные обновления для текущего ключа, канала, редакции, зависимостей и, если включён, экспертного ограничения. Это хороший сигнал. Это не аттестация всех файлов сайта и не заключение по стороннему коду. Страница «Marketplace → Обновление решений» отдельная; срок поддержки платного решения тоже может закончиться отдельно, а само решение продолжит работать без права получить новый патч.

На 5 сентября 2026 года верхними записями официальной истории указаны main 26.700.0 и fileman 26.0.0. Я привожу их только как снимок даты статьи, не как вечные константы: завтра target может измениться, а конкретной редакции обновление может приходить другой цепочкой. Для безопасности важнее два числа по каждому модулю: установленная версия и минимальная исправленная версия из бюллетеня. Последнюю стабильную версию всё равно ставлю, но решение об аварийности принимаю по security floor и условиям эксплуатации уязвимости.

• версия продукта на экране — ориентир, а не полный patch level;
• версия модуля — заявление о сборке, но ещё не доказательство целостности файлов;
• security floor — первая версия, которую вендор называет исправленной;
• exposure — доступен ли уязвимый обработчик из интернета, cron, агента или только доверенному администратору.

Снимаем версии из рантайма и с диска

Первый слой — то, что считает установленным сам Bitrix Framework. Начать можно со страницы /bitrix/admin/module_admin.php, но для воспроизводимого отчёта я беру API. В таблице b_module хранится реестр ID, но не надёжный каталог версий: ModuleManager получает список установленных модулей, а getVersion() читает версию с диска. Для main это константа SM_VERSION из /bitrix/modules/main/classes/general/version.php; для остальных — массив VERSION в modules/<id>/install/version.php, причём стандартный поиск учитывает /local. Поэтому SQL вида SELECT ID FROM b_module нужен для флага installed, но искать там patch level бессмысленно.

На штатно работающем узле я запускаю короткую PHP-инвентаризацию от пользователя PHP-FPM. Она загружает пролог сайта, перебирает ModuleManager::getInstalledModules() и для каждого ID печатает ModuleManager::getVersion($id). DOCUMENT_ROOT подставляйте свой. Скрипт не оставляю в webroot: либо php -r, либо закрытый каталог администрирования. На хосте с признаками компрометации пролог не запускаю вообще — неизвестный init.php или автозагрузчик может выполнить чужой код; сначала делаю образ и разбираю файлы офлайн.

Второй слой — всё, что лежит в /bitrix/modules и /local/modules, включая незарегистрированные и забытые каталоги. Это принципиально. /local имеет приоритет при поиске файлов, поэтому старая копия с тем же ID способна затенить обновлённую. Кроме того, решение могло скопировать компоненты, ajax-обработчики или публичные файлы за пределы своего каталога. Я отдельно сравниваю оба дерева, список b_module и фактические HTTP-маршруты; слово «удалён» в интерфейсе без проверки диска меня не успокаивает.

• Инвентаризация рантайма: sudo -u www-data php -r '$_SERVER["DOCUMENT_ROOT"]=$argv[1]; $DOCUMENT_ROOT=$argv[1]; define("NO_KEEP_STATISTIC", true); define("NO_AGENT_CHECK", true); define("NOT_CHECK_PERMISSIONS", true); require $argv[1]."/bitrix/modules/main/include/prolog_before.php"; $ids=array_keys(\Bitrix\Main\ModuleManager::getInstalledModules()); sort($ids, SORT_STRING); foreach ($ids as $id) { $v=\Bitrix\Main\ModuleManager::getVersion($id); printf("%s\t%s\n",$id,$v===false?"NO_VERSION":$v); }' /var/www/site
• Все декларации версий на диске: find /var/www/site/bitrix/modules /var/www/site/local/modules -type f -path '*/install/version.php' -print; main проверяем отдельно в /bitrix/modules/main/classes/general/version.php.
• Дубли ID в двух деревьях: cd /var/www/site && comm -12 <(find bitrix/modules -mindepth 1 -maxdepth 1 -type d -printf '%f\n' | sort) <(find local/modules -mindepth 1 -maxdepth 1 -type d -printf '%f\n' | sort). Команда рассчитана на Bash и GNU find.
• В отчёт пишем: hostname, document root, module_id, installed, все пути, эффективный путь, версия и дата, security floor, latest stable, срок поддержки, целостность, exposure и принятое действие.

Сверяем не с ощущением свежести, а с бюллетенями

Для модулей платформы мой первичный источник — Центр информирования 1С-Битрикс, затем карточка уязвимости и история конкретного модуля. Примеры хорошо показывают, почему main нельзя использовать как прокси для всего сайта. В апреле 2026 года доступ к сведениям о почтовых настройках был исправлен в main 26.150.100. LFI при редактировании лендинга исправили в landing 25.1100.100. Три проблемы импорта и свойств инфоблока, включая чтение произвольных файлов, закрыты в iblock 24.300.100. А возможность пользователя с ограниченными правами копировать произвольные файлы через менеджер файлов исправлена в fileman 24.500.100. Это четыре независимые строки матрицы.

Исторический пример с понятным ущербом — CVE-2022-27228 в vote: 1С-Битрикс указывает исправление 21.0.100 и оценку 9.8. Произвольная запись файла при подходящей конфигурации могла стать выполнением PHP-кода. Но я не переношу этот ярлык на любую LFI и не обещаю, что версия сама отвечает на вопрос об эксплуатации. Иногда нужны права редактора или администратора, иногда опасный маршрут доступен без авторизации; это берётся только из карточки и модели доступа конкретного проекта.

Для Marketplace есть отдельный официальный реестр сторонних решений. На дату статьи в нём 42 записи. Например, «Универсальный импорт» АКРИТ отмечен как уязвимый до 1.79.0, INTEC core — до 1.2.30. Разработчик первого решения поясняет, что 1.79.0 добавляет проверку прав и sessid, защищает HTTP-воркеры токеном, ограничивает загрузку URL от SSRF и убирает выполнение пользовательской PHP-формулы; возможные последствия включали загрузку файлов, доступ к данным и несанкционированное выполнение кода. Вот это уже основание для срочного действия, а не догадка по цвету панели.

• Порог сравниваю штатно: $v=\Bitrix\Main\ModuleManager::getVersion('fileman'); $ok=$v!==false && CheckVersion($v, '24.500.100'); строковое сравнение версий для этого не годится.
• P0: опубликованная RCE, запись исполняемого файла, обход авторизации или чтение секретов на интернет-доступном маршруте — изоляция сразу, патч в ближайшее окно;
• P1: версия ниже security floor, но эксплуатация требует привилегированной роли, отключённой функции или внутренней сети — закрываю быстро, одновременно проверяя предпосылки;
• P2: обычные исправления интерфейса и функции без security-эффекта — плановый релиз после теста;
• не классифицировано: партнёр исчез, changelog пишет лишь «усилена безопасность», а границы нет — запрашиваю подтверждение у автора или убираю решение из эксплуатации.

Стенд «ООО Вектор»: зелёный main и пять разных рисков

Покажу составной стенд, который я собирал руками по мотивам нескольких однотипных аудитов. «ООО Вектор» — условное название, это не раскрытый клиент и не заявление об инциденте конкретной компании. Конфигурация: интернет-магазин с примерно 80 тысячами сессий в сутки, 8 vCPU, 16 ГБ RAM, 120 ГБ SSD, Debian 12, nginx 1.22 перед Apache 2.4, PHP 8.2, MariaDB 10.11 и Redis 7. На диске было 67 каталогов модулей, в b_module — 58 ID, партнёрских решений — 14. Предыдущий подрядчик обновлял выборочно через экспертный режим, потому что боялся сломать шаблон.

На главной панели всё выглядело прилично: main 26.700.0, высокий уровень проактивной защиты, зелёный виджет. Полная таблица показала другое: fileman 22.200.100, landing 25.1100.0, iblock 24.200.0 и acrit.import 1.74.650. Все четыре были ниже опубликованных границ: fileman 24.500.100, landing 25.1100.100, iblock 24.300.100 и acrit.import 1.79.0. Ещё девять каталогов не числились установленными; три содержали PHP-обработчики, а один и тот же ID лежал и в /bitrix/modules, и в /local/modules. Сам этот факт не доказывал RCE, но доказал, что прежний отчёт о patch level был неполным.

Я заморозил изменения каталога на время согласованного снимка, восстановил БД и webroot на изолированном клоне и сначала обновил систему обновлений и весь согласованный набор платформенных зависимостей. После этого довёл fileman до 26.0.0, landing до 26.1100.0, iblock до 26.0.0, а acrit.import — до доступной тогда 1.80.300. Каждый переход прогнали на 27 проверках: вход администратора, поиск, карточка товара, корзина, заказ, оплата в тестовом контуре, обмен с 1С, импорт CSV/XML, агенты и cron. Дубликат из /local оказался старой ручной копией; после diff и проверки зависимостей мы вывели его из пути загрузки, а три неиспользуемых обработчика удалили из развёртывания с сохранением архива вне webroot.

Тестовый прогон занял 2 часа 18 минут, производственное окно — 34 минуты, режим обслуживания понадобился на 11 минут. Затем я сравнил файлы с чистыми пакетами, запустил штатные проверки, проверил новые и изменённые PHP-файлы и просмотрел 90 дней access/error-логов, задания cron, активные агенты и административные входы. Признаков компрометации не нашли — и это важный честный итог: старая версия означает риск, но не автоматически взлом. На выходе у «Вектора» появился подписанный JSON-снимок из 67 строк, ноль версий ниже известных security floor и еженедельная отдельная проверка Marketplace.

• main: 26.700.0 → 26.700.0, уже выше исправления 26.150.100;
• fileman: 22.200.100 → 26.0.0;
• landing: 25.1100.0 → 26.1100.0, выше исправления 25.1100.100;
• iblock: 24.200.0 → 26.0.0, выше исправления 24.300.100;
• acrit.import: 1.74.650 → 1.80.300, выше исправления 1.79.0.

Версия совпала — теперь докажите, что совпадает код

Файл install/version.php — метка, а не криптографическое доказательство. Обновление партнёрского модуля копирует его ядро, но изменения БД, компонентов и публичных файлов зависят от updater.php разработчика. Официальная документация прямо предупреждает: прочие части сайта автоматически не обновляются, их должен привести в соответствие апдейтер. Из практики здесь ломается чаще всего: когда-то компонент скопировали в шаблон, потом исправили модуль, а рабочий ajax.php остался старым.

После патча я запускаю проверку модификаций ядра, а для всего дерева делаю собственный хеш-манифест и diff с заведомо чистой сборкой. Штатный «Контроль целостности» полезен только при хорошем исходном снимке: если эталон создан после заражения, он честно подтвердит неизменность уже заражённых файлов. Сканер безопасности и поиск троянов тоже нужны, но у них бывают ложные срабатывания и пропуски. Это датчики, не нотариус. Для партнёрского кода прошу пакет у разработчика или сверяю с чистой установкой той же версии на изолированном стенде.

Если нашлись неизвестные PHP-файлы, подозрительные агенты или обращения к опасным маршрутам, обычное обновление прекращает быть задачей сопровождения и становится реагированием на инцидент. Я изолирую узел, сохраняю образ и логи, определяю первое проникновение, восстанавливаю из доверенной точки, меняю пароли и ключи, проверяю cron, systemd, SSH authorized_keys, БД и соседние хосты. Патч закрывает вход, но не выселяет уже созданный web-shell.

• проверьте «Настройки → Проактивная защита → Контроль целостности» и поиск троянов;
• проверьте корень сайта и удалите оставшийся bitrixsetup.php: официальный бюллетень требует именно удаления, и этот риск вообще не выражается версией модуля;
• найдите PHP в upload, tmp, cache и иных записываемых каталогах, где выполнение скриптов должно быть запрещено;
• сопоставьте mtime и хеши с логами, но не считайте mtime надёжным доказательством времени атаки;
• проверьте обработчики событий, b_agent, cron, systemd timers, учётные записи админов и новые ключи SSH;
• после обновления очистите кеш штатно и повторите функциональные и security-проверки.

Регламент, который я оставляю администратору

Мой рабочий вариант простой: ежедневный read-only снимок ID, путей, версий и хешей исполняемого кода и конфигурации; еженедельная онлайн-проверка двух разделов обновлений и двух реестров уязвимостей; ежемесячное окно установки стабильных обновлений через staging. Для main 24.400.0 и новее при настроенном Composer доступна официальная CLI-команда из каталога /bitrix: php bitrix.php update:modules, в том числе с -m для списка платформенных модулей. Сначала смотрю php bitrix.php help update:modules: универсальный --dry-run документация не обещает. Команда показывает изменения и запрашивает подтверждение. Я не подаю ей yes вслепую и не обещаю через неё обновление партнёрских решений: для Marketplace документирован отдельный интерфейс «Обновление решений».

В первую очередь оплачивайте доступ к security-обновлениям, убирайте заброшенные интернет-доступные решения и закрывайте версии ниже опубликованных границ. На что можно временно забить: косметический changelog, beta-функции и модуль, которого нет ни в b_module, ни на диске, ни в скопированных компонентах, маршрутах, агентах и cron. Но это должно быть проверенное отсутствие, а не «кажется, мы им не пользуемся». WAF, запрет PHP в upload и IP-фильтр админки снижают риск на время окна, однако не заменяют исправленный код.

Наконец, храните снимок как артефакт, а не как таблицу в голове: дата проверки сервера обновлений, канал stable/beta, режим expert, срок лицензии, ссылка на бюллетень, версия до и после, хеш отчёта, номер резервной копии и результат восстановления. Тогда на вопрос руководителя «мы закрыли вот эту RCE?» вы отвечаете строкой с доказательствами. Если остаётся unknown, так и пишите unknown. Это профессиональнее зелёной галки и намного полезнее при реальном инциденте.

• сегодня: выгрузить установленные ID, просканировать оба каталога modules и открыть оба реестра уязвимостей;
• за сутки: изолировать P0, продлить просроченные лицензии/поддержку, подготовить согласованный бэкап и стенд;
• в ближайшее окно: обновить полную цепочку зависимостей, затем партнёрские решения, проверить миграции и целостность;
• после окна: повторить инвентаризацию, сохранить JSON/CSV и поставить контроль изменений на расписание.

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