Вы ведь тоже обновляете «Битрикс» по графику и спите спокойно? А я вот сейчас покажу три дыры, через которые ваш сайт утечёт вместе с базой клиентов — и обновления здесь почти бессильны.
Знаете, что меня реально раздражает? Когда в инциденте разбираешь очередной взломанный корпоративный портал на Bitrix, а администратор клянётся, что «всё было обновлено». И знаете, что удивляет? В 9 из 10 случаев патчи стоят, но эти три критических условия, о которых почти не говорят в мануалах, — они как раз и оставались открытыми. Сегодня, в 2025-м, злоумышленникам даже не нужен нулевой день. Им нужна ваша уверенность в защите.
Давайте без паники. Просто представьте: в Рунете висит около 2 миллионов инстансов 1С-Bitrix. По нашим данным в CyberOK, даже после декабрьской истории с CVE-2025-67886 и CVE-2025-67887, примерно 10% из них — это всё ещё низко висящие плоды. И патч, честно говоря, не стал бы панацеей. Потому что корень проблемы — не в коде, а в конфигурации, которую годами не пересматривали. Если вы CISO или ответственный за цифровые активы, приготовьтесь. Это не страшилка, а разбор полётов с реальными кейсами.
Условие первое: когда права «SOURCE» и «WRITE» — это не привилегия, а привычка
Эти две уязвимости в модуле Translate — они как раз об этом. Если коротко: система позволяет загружать архивы с локализациями, но не проверяет, что внутри. А внутри может быть PHP-файл и хитрно сформированный .htaccess. Результат? Выполнение произвольного кода на сервере (RCE). Звучит страшно? Теперь ключевой момент.
Для успешной атаки злоумышленнику уже нужны права SOURCE и WRITE на этот модуль. И вот здесь большинство администраторов машут рукой: «Ну, если у него такие права, то он и так всё может». Это самое опасное заблуждение. На практике в больших компаниях эти права часто раздаются по инерции — например, контент-менеджерам, внешним подрядчикам по локализации, стажёрам. Потому что «им же нужно обновлять тексты на сайте». А потом учётка этого подрядчика утекает в результате фишинга, и… вы понимаете.
По моему опыту, в одном крупном банке именно так и произошло. У внешнего лингвиста, работавшего над переводом интернет-банка, был полноценный доступ к модулю Translate. Его почту взломали через банальный фишинг в Telegram. И через неделю на одном из аплоад-серверов крутился криптомайнер. Хорошо, что сработала система мониторинга нестандартных исходящих соединений. А могло быть и хуже.
Поэтому первое правило 2026 года: пересматривайте матрицу доступов к админке Bitrix так же часто, как пароли. Если у пользователя есть SOURCE/WRITE, спросите себя: а не проще ли ему прислать архив локализаций админу для загрузки раз в квартал? Снижение поверхности атаки — это всегда рутина, а не разовая акция.
Условие второе: слепая зона вашего веб-сервера (Apache vs Nginx)
Теперь техническая деталь, которую многие упускают. Успех эксплуатации этих CVE сильно зависит от того, что у вас работает под капотом. Если у вас Apache с дефолтными настройками обработки .htaccess в директориях загрузки — вы в зоне максимального риска. Потому что этот самый .htaccess из архива злоумышленника может диктовать серверу: «исполняй все файлы с расширением .php в этой папке».
А вот если у вас Nginx, и он настроен грамотно, то атака усложняется. Nginx, если очень грубо, не читает .htaccess. Ему нужно явно указать в конфигурации, где и как исполнять PHP. И если ваши временные директории (те самые upload_tmp_dir или BXTEMP) вынесены за пределы location’ов с обработчиком PHP, то загруженный скрипт просто не выполнится — его отдадут как текстовый файл. Это как дать вору муляж ключей от сейфа.
Но знаете, что интересно? В реальности я часто вижу гибридные связки. Стоит Nginx как frontend, а за ним — Apache для обработки скриптов. И вот в настройках этого Apache забывают выставить AllowOverride None для writable-директорий. Получается эдакий франкенштейн, уязвимый со всех сторон.
Однажды на аудите для ритейлера мы нашли именно такую схему. Разработчики сделали «для производительности», а безопасность стала заложником этой оптимизации. Пришлось буквально по полочкам разбирать конфиги и выносить все пользовательские загрузки на отдельный поддомен с максимально ограниченными правилами. Это небыстро, но необходимо.
По правде говоря, каждая такая настройка — это пазл в общей картине безопасности. И если вы до сих пор не уверены, как у вас обрабатываются файлы в /upload/ или /bitrix/tmp/ — считайте, что у вас уже есть слепая зона. Проверить это можно за полчаса. Жаль, что этим полчасам всегда находится «более важное» дело.
Условие третье: сетевой доступ без контекста — прямая дорога к инциденту
Представьте, что вы поставили суперсовременный сейф (WAF, фаервол), но оставили окно в подсобке открытым. Примерно так работает ситуация, когда контроллеры модуля Translate (что-то вроде /bitrix/admin/translate_controller.php) доступны для вызова из интернета без каких-либо дополнительных проверок.
Да, для эксплуатации нужны права. Но атака редко выглядит как прямое вбрасывание кода. Чаще это цепочка: нашли уязвимый инстанс (сканирование), купили на теневом форуме доступ к учётке (утечка), а потом уже из-за границы, с чистого IP, запустили эксплуатацию. И если ваш WAF настроен только на отражение SQL-инъекций или XSS, он пропустит этот легитимный, на первый взгляд, запрос к админке.
Поэтому одна из наших ключевых рекомендаций — закрыть сетевой доступ к этим контроллерам на уровне сети. Оставить возможность работы только с административных IP-адресов офиса или, что ещё лучше, только через VPN. Это не панацея, но серьёзный барьер. Замечу, что в свете 187-ФЗ и требований ФСТЭК к сегментации сетей, такие меры становятся не просто рекомендацией, а необходимостью.
На практике, в одном из наших проектов для объекта КИИ, мы внедрили как раз такую модель: доступ ко всем административным интерфейсам, включая Bitrix, только через выделенный прыжковый хост (jump server) с обязательной двухфакторной аутентификацией. И знаете, что показал первый же месяц мониторинга? Сотни попыток доступа к этим самым /translate_controller.php из диапазонов IP, связанных с известными хостинг-провайдерами, которые используют злоумышленники. Все они были заблокированы на подходе. Это как поставить камеру на ту самую тёмную аллею, куда вы раньше боялись заглянуть.
А теперь — самое важное. Эти три условия создают идеальный шторм. По отдельности каждый фактор может и не привести к катастрофе. Но вместе они — почти гарантированный инцидент. И оценка CVSS в 7.2 балла, на мой взгляд, здесь не совсем отражает реальную опасность для бизнеса. Потому что ущерб — это не только downtime сайта. Это потеря данных клиентов по 152-ФЗ, это репутационные потери, это, в конце концов, штрафы регуляторов.
🔐 10 Правил 2026 года, чтобы ваш Bitrix не стал трофеем
- Жёсткий пересмотр прав. Уберите SOURCE/WRITE на модуле Translate у всех, кроме 2-3 ключевых администраторов. Проверяйте это ежеквартально.
- Сегментация доступа. Закройте сетевой доступ к /bitrix/admin/translate_controller.php через ACL или WAF. Разрешите только с IP админ-сегмента или через корпоративный VPN.
- Дрессировка Apache. Если используете Apache, для всех директорий загрузок (upload, tmp, cache) пропишите AllowOverride None. Это запретит чтение .htaccess в этих папках.
- Контроль исполнения. Явно запретите выполнение PHP в директориях для загрузки файлов. Для Apache это директива php_admin_flag engine off. Для Nginx — убедитесь, что в location для этих путей не подключён обработчик PHP-FPM.
- Охота за артефактами. Еженедельно ищите подозрительные PHP-файлы во временных директориях (BXTEMP, /upload/tmp). Напишите простой скрипт или используйте сигнатуру в SIEM.
- Минимальные привилегии для PHP-FPM. Запускайте рабочие процессы PHP под отдельными пользователями с минимальными правами, без доступа к критичным конфигам.
- Журналирование всего. Включите детальное логирование всех операций модуля Translate и доступа к административным контроллерам. Пишите логи не на тот же сервер, а на защищённый лог-сервер (syslog).
- WAF с поведенческим анализом. Настройте WAF не только на сигнатурные атаки, но и на аномальную активность: частые вызовы админ-контроллеров, загрузки архивов необычного размера.
- План, а не реакция. Имейте готовый playbook на случай обнаружения подозрительной активности, связанной с Translate. Кого оповещать, как изолировать сервер, где брать бекапы.
- Регулярный аудит силами третьей стороны. Свои ошибки глазами не увидишь. Раз в полгода заказывайте внешний пентест, уделяя особое внимание CMS и веб-приложениям.
Это не просто список. Это выжимка из десятков расследованных нами инцидентов. Каждый пункт — это чья-то боль.
И последнее.
Самое странное, с чем я сталкиваюсь: компании готовы платить миллионы за крутые EDR и DLP, но экономят на базовой гигиене веб-приложений. Это как купить бронированную дверь, но оставить ключи под ковриком. Bitrix — это мощный, сложный инструмент. И управлять его безопасностью нужно так же комплексно, как и любой другой критичной бизнес-системой. Не как обновляемым сайтом-визиткой.
══════
Нужна помощь?
Оставьте заявку на Бесплатную консультацию на сайте: https://securedefence.ru/
Пришлём чек-лист + дорожную карту + КП
Первые 5 заказов каждый месяц — расширенный аудит на 12 страниц в подарок!
══════
FAQ — 10 острых вопросов, которые мне задают чаще всего
- Мы уже поставили патч от декабря. Мы в безопасности?
Если вы только поставили патч, но не выполнили правила 1-3 из списка выше — нет. Патч закрывает конкретные CVE, но не меняет рискованную конфигурацию, которая позволила бы их использовать. - Как быстро могут эксплуатировать эти уязвимости?
PoC (proof-of-concept) уже в открытом доступе. Автоматические сканеры ищут уязвимые инстансы постоянно. У вас есть дни, максимум недели, если вы в зоне риска. Не месяцы. - У нас Bitrix24 в облаке от «1С-Битрикс». Нас это касается?
Касается, если у вас коробочная версия Bitrix24 (on-premise) до версии 25.100.300. Облачный SaaS от самого вендора теоретически защищён им. Но если вы развернули свою коробку — вы ответственны за её настройку. - А если у нас только Nginx?
Ваш риск снижен, но не нулевой. Внимательно проверьте конфигурацию (nginx.conf), нет ли там обработки PHP в папках загрузки. И помните про условие №1 — права пользователей. - Мы маленькая компания, кому мы нужны?
Вам нужны. Атаки часто автоматические. Ваш сервер могут взять для хранения фишинговых страниц, майнинга криптовалюты или как точку для атаки на ваших более крупных партнёров. Вы — звено в цепочке. - Какой самый простой способ проверить, уязвимы ли мы?
Самый быстрый — провести аудит прав пользователей в админке Bitrix и проверить конфигурацию веб-сервера на предмет исполнения PHP в upload-директориях. Это можно сделать за пару часов. - Обнаружили подозрительный файл в /bitrix/tmp/. Что делать?
Не удалять сразу. Изолируйте сервер от сети, сделайте образ диска для расследования, проверьте логи доступа и действий пользователей. Потом уже чистите. Удаление — это уничтожение улик. - WAF от хостинга нас защитит?
Базовый WAF защитит от шаблонных атак. Но он, скорее всего, не знает про логику вашего приложения и специфичные для Bitrix векторы. Нужна тонкая настройка под вашу инфраструктуру. - Это нарушает требования 152-ФЗ?
Прямо или косвенно — да. Если через эту уязвимость произойдёт утечка персональных данных, это будет считаться нарушением требований к безопасности ПДн. Могут быть штрафы. - Стоит ли временно отключить модуль Translate?
Если вы им не пользуетесь для загрузки локализаций — абсолютно да. Это самый быстрый и радикальный способ обезопаситься до полного приведения конфигурации в порядок.
══════
Работая с десятками компаний, от среднего бизнеса до госкорпораций, я понял одну простую вещь: безопасность — это процесс, а не состояние. И начинается он с понимания, где находятся эти самые «три условия» в вашей системе. Проверьте их прямо сейчас. Пока не стало поздно.
══════
Нужна помощь?
Оставьте заявку на Бесплатную консультацию на сайте: https://securedefence.ru/
Пришлём чек-лист + дорожную карту + КП
Первые 5 заказов каждый месяц — расширенный аудит на 12 страниц в подарок!
══════
Больше материалов: Центр знаний SecureDefence.