«Как удостовериться, что наш разработчик сделал все необходимое, чтобы защитить сайт на Битриксе, в связи с обнаруженными на днях уязвимостями PHP? »

Начну с главного: в этот раз дыра не в Битриксе, а в самом PHP. Поэтому ответ подрядчика «мы обновили Битрикс» вас не защищает. Хорошая новость — проверить, что всё сделано, можно за 10 минут, даже если вы не технарь.

Попросите у разработчика три вещи:

• Скриншот команд php -v и php-fpm -v с сервера. Нормальная версия — не ниже 8.2.35, 8.3.36, 8.4.27 или 8.5.12. Если сайт на 7.4 или 8.1, новых официальных версий для них нет, и подрядчик должен назвать, какой исправленный пакет поставил.
• Подтверждение, что после обновления перезапустили PHP-FPM, Apache и обработчики очередей. Без этого в памяти остаётся старый код, и сайт уязвим, хотя «всё обновили».
• Короткий отчёт о проверке на взлом: нет ли лишних .php в /upload/, новых администраторов, странных агентов и файлов, изменённых за последние недели. И сменили ли пароли и ключи.

Ещё одна проверка — в админке Битрикса, в разделе «Проверка системы». Там видно, на какой версии PHP работает сам сайт. Мы не раз видели, как консольный PHP обновили, а сайт продолжает крутиться на старом.

Теперь о том, что пригодится не только сейчас. Уязвимости будут появляться и дальше, и спасает не скорость реакции в моменте, а порядок заранее:

• Пропишите в договоре срок реакции на критические уязвимости — 24-72 часа.
• Держите список, что где работает: серверы, версии PHP, базы, админки.
• Если обновиться быстро нельзя, закройте админку паролем или доступом по IP.
• И обязательно бэкапы по правилу 3-2-1: три копии данных, на двух разных носителях, одна из них — вне основного сервера. Раз в квартал проверяйте, что из бэкапа реально можно восстановиться.

Хороший подрядчик пишет клиенту об угрозе первым, а не ждёт вопроса. Если вам пришлось спрашивать самим — это тоже повод задуматься.

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

Важно понимать «обновить все сайты в интернете» невозможно мгновенно, например: через 36 часов после выхода патча в Корее обновились лишь 3,8% серверов, около 1,57 млн PHP-хостов оставались уязвимыми. И апокалипсиса не случилось. Это вопрос охвата инфраструктуры и времени, а не качества работы вашего разработчика.

От разработчика требуйте всего три момента: фактическую версию PHP (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12), подтверждение перезапуска PHP-FPM или Apache и скриншот проверки, а не устное «всё в порядке». Если это выполнено — ваш участок закрыт.

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

Откройте администраторский интерфейс по ссылке /bitrix/admin/phpinfo.php. Там указано PHP Version. Она должна быть версия из тех, что официально получили обновление, а именно:

• 8.5.12
• 8.4.27
• 8.3.36
• 8.2.35

Есть неофициальные патчи, в частности от Ondřej Surý. Он перенес правки в собственные репозитории php (ppa:ondrej/php) вплоть до 7.4, но рекомендуем придерживаться официальных обновлений.

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

В первую очередь вам нужно получить от разработчика ответ на вопрос: «Есть ли у нас сейчас незакрытые уязвимости на наших ресурсах, и если есть, сколько времени нужно на их устранение?»

Уязвимости часто годами живут внутри ресурса, и никто о них не подозревает. Случай с PHP2Shell был публичным: всех оповестили, и все начали активно искать, как временно закрыть брешь, пока патча еще нет. Но такие объявления будут не всегда. Поэтому после «громких анонсов» важно задуматься и начать на постоянной основе внедрять комплекс мер для защиты своих ресурсов и данных:

• Плановые обновления. Не игнорируйте предупреждения в CMS и замечания разработчика или администратора о том, что «нужно что-то обновить». Плановые обновления снижают риск атаки.
• Мониторинг со стороны IT-службы. Он позволяет заранее узнавать о найденных «дырах» и принимать меры в зависимости от степени риска.
• Аудит безопасности. Раньше эта услуга не пользовалась большим спросом, а при нынешнем темпе развития становится необходимым минимумом. Раз в месяц с помощью специализированного ПО проводится проверка: «А защищены ли мы в данную минуту и готовы ли к быстрым обновлениям?»

Уязвимость вчерашнего дня нашли с помощью ИИ. А какова вероятность, что уязвимость завтрашнего дня найдет злоумышленник?

Чтобы убедиться, что разработчик принял необходимые меры, нужно проверить, какая версия PHP используется на сервере и установлены ли для неё исправления безопасности.

Недавно обнаруженные уязвимости CVE-2026-109618 и CVE-2026-109619 относятся к PHP, а не непосредственно к «1С-Битрикс». Поэтому обновление самой CMS не заменяет устранение уязвимостей PHP.

Важно: эта инструкция применима в только для тех, чей веб-ресурс размещен на VDS-хостинге. Если вы используете Shared hosting (Виртуальный хостинг), а это большинство сайтов, уточните у службы поддержки хостинг-провайдера совершены ли ими следующие действия.

1. Уточнить версию PHP, на которой фактически работает сайт. Важно проверить именно версию, используемую веб-сервером, а не только указанную в настройках или командной строке.
2. Убедиться, что для вашей версии PHP имеется обновленная версия с исправлениями. Проверить можно на официальном сайте https://www.php.net. Получить подтверждение от разработчика, что версия PHP совпадает с исправленной, а работающие процессы перезапущены.
3. Проверить работоспособность сайта после обновления: основные страницы, формы, авторизацию, оформление заказов (если предусмотрено) и интеграции.

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

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

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

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

1. Попросите объяснить простыми словами, что сделано. Хороший специалист ответит примерно так: «Сервер обновил хостинг такого-то числа, я после этого проверил сайт, вот что смотрел». Если в ответ звучит «всё нормально, не переживайте» без конкретики, это тревожный знак.
2. Задайте прямой вопрос: «Нашу версию вообще ещё обновляют?» Бывает, что сайт работает на устаревшей версии, для которой исправлений уже не выпускают. Тогда честный ответ — «нет, нужен переход», и разработчик должен сам об этом сказать и предложить план.
3. Попросите письменный отчёт в пару строк: что обновлено, когда и что проверено после этого. Это дисциплинирует и пригодится, если потом что-то всплывёт.
4. Проверьте сайт сами глазами клиента. Найдите товар, положите в корзину, оформите тестовый заказ, отправьте форму, зайдите в личный кабинет. Если всё работает, значит, обновление ничего не сломало.
5. Если сомнения остаются, позовите второе мнение. Разовый аудит безопасности от стороннего специалиста стоит недорого по сравнению с последствиями взлома.

Главный критерий простой: хороший разработчик отвечает конкретно и сам поднимает неудобные темы. Если приходится вытягивать ответы по одному, работа скорее всего не сделана.

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

1. Проверяем версию PHP.

Зайдите в административную панель сайта по адресу ваш-домен/bitrix/admin/. Откройте «Настройки → Инструменты → Диагностика → Настройки PHP». Найдите строку PHP Version.

После обновлений от 21 октября 2026 года исправленными считаются версии 8.2.35, 8.3.36, 8.4.27 и 8.5.12 или более новые в соответствующих ветках.

Если версия ниже, обратитесь к разработчику или хостингу. Иногда исправления устанавливаются без изменения основного номера версии. Попросите документальное подтверждение.

2. Проверяем дополнительную защиту.

На той же странице нажмите Ctrl+F и найдите session.upload_progress.enabled.

После сообщения о третьей уязвимости 23 октября разработчики PHP рекомендовали временно установить значение Off (0). Если указано On, попросите специалиста проверить настройку и необходимость её изменения.

3. Проверяем безопасность Битрикс.

Откройте «Настройки → Проактивная защита → Сканер безопасности» и запустите проверку, если инструмент доступен в вашей редакции. Обнаруженные ошибки передайте разработчику. Сам сканер не подтверждает исправление PHP.

4. Запрашиваем подтверждение работ.

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

Важно понимать: обновление самого «1С-Битрикс» через Marketplace не обновляет PHP на сервере. Поэтому сообщение «мы обновили Битрикс» ещё не означает, что уязвимости PHP устранены.

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