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

У «1С-Битрикс» есть официальный центр информирования об уязвимостях — и если открыть его сегодня, картина не успокаивает: за последние полтора года там опубликованы записи о дырах с оценками 8 и выше по CVSS, включая критичную 9.8. Часть из них позволяет читать произвольные файлы на сервере, часть — получать root в виртуальной машине. Всё это уже исправлено в обновлениях, но исправлено — не значит установлено: уязвимость закрыта только на тех сайтах, где обновления реально накатили. Разбираем, какие уязвимости закрыть в первую очередь, как проверить свой сайт и как не возвращаться к этому вопросу в авральном режиме.

Откуда мы знаем об уязвимостях: центр информирования

С 2024 года «1С-Битрикс» публикует сведения об уязвимостях своих продуктов в открытом «Центре информирования о необходимых обновлениях». Сейчас в реестре 36 записей, и по каждой указаны дата выявления, дата исправления, ссылка на бюллетень БДУ ФСТЭК и оценка опасности по CVSS — от «косметических» 3.1 до критичных 9.8.

Важная деталь, которую видно по датам: между исправлением уязвимости и её публичным раскрытием проходит от нескольких недель до нескольких месяцев. Например, серия дыр в инфоблоках была выявлена и исправлена в апреле 2025 года, а опубликована только 15 июля 2025-го. Это стандартная практика ответственного раскрытия: вендор даёт клиентам время обновиться. Но у неё есть обратная сторона — в момент публикации уязвимость мгновенно становится инструкцией для атакующих. Скрипты, которые массово сканируют Рунет на конкретные версии Битрикса, появляются в течение дней после раскрытия. Если сайт к этому моменту не обновлён, он в зоне поражения.

Дальше — разбор самых опасных записей реестра за 2024–2026 годы: что это за уязвимости, чем они грозят бизнесу и что делать.

LFI в лендингах: 9.8 из 10 — самая опасная дыра за год

Самая тяжёлая запись последнего времени — Local File Inclusion при редактировании лендинга (БДУ 2026-05965). Оценка — 9.8 по CVSS, это уровень «критично»: выше в шкале почти ничего нет. Уязвимость выявлена 8 января 2026 года, исправление вышло 13 января 2026-го.

Что это значит на практике. LFI — класс атак, при котором злоумышленник заставляет приложение подключить и выполнить произвольный файл с сервера. В случае с модулем «Сайты 24» (лендинги) это открывает дорогу к чтению конфигурационных файлов — в том числе settings.php и dbconn.php с реквизитами доступа к базе данных, — а в худшем сценарии к выполнению кода и полному захвату сайта.

Отдельный неприятный момент: модуль лендингов установлен и включён на огромном числе сайтов «на всякий случай», даже если бизнес им не пользуется. Уязвимость в модуле, которым никто не пользуется, — всё ещё уязвимость.

Правило, которое экономит массу проблем: всё, что не используется, должно быть выключено. Каждый включённый модуль — это дополнительная поверхность атаки.

Доступ к настройкам почты: свежая уязвимость апреля 2026

Самая свежая запись реестра — несанкционированный доступ к информации о настройках почтовых отправлений (БДУ 2026-04276), опубликована 10 апреля 2026 года, оценка 8.5. Выявили её 7 апреля, исправили уже 8 апреля — реакция быстрая, но дальше всё зависит от владельцев сайтов.

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

Инфоблоки: чтение произвольных файлов на сервере

Июльская публикация 2025 года раскрыла сразу три родственные уязвимости в работе с инфоблоками — ключевым механизмом хранения контента в Битриксе:

• Local File Inclusion при изменении свойств инфоблока (БДУ 2025-08666) — оценка 8.0;
• чтение произвольных файлов при импорте инфоблока из XML (БДУ 2025-08665) — оценка 6.9;
• чтение произвольных файлов при импорте инфоблока (БДУ 2025-08664) — оценка 6.9.

Все три выявлены 21 апреля 2025 года и исправлены за два дня. Общий знаменатель — возможность добраться до файлов, к которым у пользователя не должно быть доступа: конфигурация, дампы, резервные копии, лежащие в пределах сайта. Эти уязвимости эксплуатируются из административного контекста, поэтому иногда их считают «неопасными» — мол, у злоумышленника и так должен быть доступ в админку. Это ошибка: в связке с фишингом, слабыми паролями или избыточными правами контент-менеджеров такие дыры превращаются в ступень эскалации — от учётки редактора до контроля над сервером.

Превышение привилегий: почтовые шаблоны и копирование файлов

Ещё две записи той же июльской серии 2025 года — превышение привилегий при редактировании почтовых шаблонов (БДУ 2025-08663) и при копировании файлов (БДУ 2025-08662), обе с оценкой 7.1.

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

Виртуальная машина Bitrix: путь до root

Отдельный блок реестра касается не самой CMS, а типового окружения — виртуальной машины VMBitrix, на которой работает значительная часть битрикс-хостинга в Рунете:

• повышение привилегий bitrix→root — две записи от 10 апреля 2025 года (БДУ 2025-04539 и 2025-04604), обе с оценкой 8.0: пользователь, от которого работает веб-сервер, может стать суперпользователем;
• захват установщика (CVE-2022-29268, опубликована 16 июля 2024 года): если злоумышленник доберётся до мастера установки виртуальной машины раньше администратора, он получает контроль над сервером.

Комбинация «дыра в CMS + повышение привилегий в VM» — это готовая цепочка полной компрометации: через уязвимость сайта атакующий получает выполнение кода от пользователя bitrix, а через уязвимость VM — root. После этого говорить о «лечении сайта» бессмысленно, сервер переустанавливают целиком.

Хранимая XSS в форуме и инъекции через CRM-формы

Две записи напоминают, что опасность приходит и через публичные формы:

• хранимая XSS в обход проактивной защиты в модуле форума (БДУ 2025-00765, январь 2025) — оценка 8.0. Вредоносный скрипт сохраняется в контенте и срабатывает в браузере каждого, кто открыл страницу, включая администратора — со всеми его cookie и сессией;
• инъекция контента через CRM-формы (БДУ 2025-15620, декабрь 2025) — оценка 3.1: заполняя форму, злоумышленник может добавить посторонний контент в связанные email-рассылки. Оценка невысокая, но для репутации рассылок и доставляемости писем — чувствительно.

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

Почему «мы обновлялись год назад» не защищает

Типовые возражения, которые мы слышим на аудитах, и что с ними не так:

• «У нас стоит проактивная защита» — см. выше: реестр содержит уязвимости, эксплуатируемые в её обход;
• «Сайт работает, значит всё в порядке» — компрометация не выглядит как поломка. Майнер, спам-рассылка или слив базы месяцами живут на работающем сайте;
• «Мы не можем обновляться — сломается кастомизация» — самая частая и самая опасная ситуация. Если разработчики правили ядро, сайт застревает на уязвимой версии навсегда. Это архитектурная ошибка, и её нужно исправлять, а не консервировать;
• «Лицензия истекла, обновления недоступны» — без активной лицензии сайт не получает патчи безопасности вообще. Продление лицензии в этом смысле — не абонентская плата, а страховка.

Чек-лист: что сделать прямо сейчас

Минимальная программа на ближайшую неделю:

• проверить версию главного модуля и установить все накопившиеся обновления — в первую очередь закрывающие LFI в лендингах и доступ к почтовым настройкам;
• если модули «Сайты 24», форум, блоги и другие не используются — отключить их;
• проверить актуальность лицензии: без неё нет патчей;
• обновить виртуальную машину VMBitrix до актуальной версии — уязвимости bitrix→root закрыты именно в ней;
• провести ревизию пользователей админки: удалить неактивных, сократить избыточные права, включить двухфакторную аутентификацию для администраторов;
• запустить встроенный сканер безопасности («Проактивная защита» → «Сканер безопасности») и разобрать все замечания;
• сменить пароли БД и админские пароли, если обновления не ставились больше года — исходить из презумпции, что сайт уже сканировали;
• проверить директории сайта на посторонние файлы (веб-шеллы чаще всего лежат в /upload/ и /bitrix/).

Как выстроить процесс: аудит и мониторинг

Разовое обновление решает сегодняшнюю проблему, но реестр пополняется постоянно: новые записи выходили в январе 2025-го, апреле, июле и декабре 2025-го, январе и апреле 2026-го. Устойчивый процесс выглядит так:

• подписка на центр информирования — у реестра есть RSS-лента, её стоит завести в рабочий мониторинг, чтобы узнавать о раскрытиях в день публикации;
• регламент обновлений — тестовая копия сайта, на которой обновления проверяются перед продом; окно обновлений не реже раза в месяц, для критичных уязвимостей — в течение 48 часов;
• периодический аудит безопасности — раз в полгода-год: проверка прав, конфигурации окружения, целостности ядра, следов компрометации;
• резервные копии вне сервера — с проверкой восстановления. Бэкап на том же сервере при захвате root не поможет.

Главное

В реестре «1С-Битрикс» 36 раскрытых уязвимостей, и среди свежих — критичный LFI в лендингах с оценкой 9.8, доступ к почтовым настройкам на 8.5 и повышение привилегий до root в виртуальной машине. Все они закрыты обновлениями — но только для тех, кто эти обновления ставит. Публичное раскрытие превращает каждую запись реестра в инструкцию для массовых сканов, поэтому вопрос не «атакуют ли нас», а «успели ли мы обновиться до того, как нас просканировали». Минимум на эту неделю: обновить платформу и виртуальную машину, отключить неиспользуемые модули, навести порядок в правах и запустить сканер безопасности. Максимум — выстроить регулярный процесс с мониторингом реестра, тестовым контуром и периодическим аудитом.