Уязвимость PHP на сайтах 1С-Битрикс: как проверить и защитить сайт

01

Что произошло и почему это важно владельцу сайта

На 26 октября 2026 года в PHP опубликованы две связанные с PHP2Shell уязвимости: CVE-2026-109618 и CVE-2026-109619. Они не относятся к ядру 1С-Битрикс, его модулям или шаблону сайта. Поэтому штатное обновление платформы полезно как часть общей гигиены, но не заменяет обновление среды исполнения PHP.

CVE-2026-109618 связана с обработкой ситуации нехватки памяти. CVE-2026-109619 — с устаревшим состоянием памяти, которое может сохраняться между запросами. В неблагоприятной конфигурации последствия могут включать удалённое выполнение кода или отказ в обслуживании. Это не означает, что каждый сервер уже скомпрометирован: реальный риск зависит от версии, способа запуска PHP, настроек процессов, входных сценариев и состава публичных функций сайта.

Для бизнеса риск измеряется не названием CVE, а цепочкой последствий: недоступная витрина или личный кабинет, остановка приёма заявок и оплат, изменение файлов сайта, доступ к служебным данным, затраты на восстановление. Маркетологу и руководителю проекта не нужно исследовать эксплуатацию уязвимости. Нужно быстро получить от администратора понятный ответ: где работает PHP для сайта, установлен ли исправленный пакет, что будет обновлено и как проверят работу после релиза.

Первичные сведения опубликованы в бюллетенях PHP: GHSA-w8hw-w9fx-j79w и GHSA-6wmf-4rv5-p3rp. Материал BXMax можно использовать как дополнительный источник контекста: публикация BXMax. Решение по конкретному серверу должно опираться на его пакеты и бюллетени поставщика.

03

С чего начать проверку: не путать CLI, веб и пакет ОС

Самая частая ошибка — выполнить проверку версии PHP в терминале и на этом закончить. Команда CLI может обращаться к отдельному бинарному файлу, тогда как сайт работает через другой пул PHP-FPM, модуль Apache или контейнер. Кроме того, поставщик операционной системы может перенести исправление в свой пакет без изменения upstream-номера PHP. Поэтому совпадение или несовпадение цифр в одном выводе не является окончательным вердиктом.

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

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

04

Какие версии PHP требуют решения

Официально исправленные релизы проекта PHP: 8.2.35, 8.3.36, 8.4.27, 8.5.12 и последующие исправленные версии соответствующих веток. Если веб-среда использует поддерживаемую ветку, администратор должен сверить конкретный пакет с рекомендацией поставщика ОС или образа и выбрать поддерживаемый способ обновления.

PHP 8.1 и более ранние ветки не получают исправления от проекта PHP. Это не означает автоматически, что пакет беззащитен: некоторые производители ОС и поставщики коммерческой поддержки выпускают backport. Но такой факт нельзя предполагать. Его подтверждают номером пакета и ссылкой на бюллетень вендора, где прямо указаны закрытые CVE.

Не стоит подменять обновление временными правилами WAF, ограничением multipart-запросов или фильтрацией на сетевом уровне. Такие меры способны сломать загрузку файлов, формы и интеграции, а также не устраняют причину в PHP. Если исправление нельзя провести оперативно, с ответственным специалистом оценивают временное ограничение публичного доступа к уязвимому сервису и последствия для бизнеса.

05

BitrixVM, CentOS 7 и Docker: три разных сценария

BitrixVM 9 не следует считать автоматически защищённой или уязвимой только по названию виртуальной машины. Сначала определяют реально работающую ОС, репозитории, способ запуска PHP и версию пакета для веб-запросов. Затем сверяют рекомендации поставщика, доступность исправленного пакета и совместимость с используемыми модулями сайта. После обновления перезапускают именно обслуживающие сайт сервисы и проводят проверку приложения.

BitrixVM 7 и CentOS 7 относятся к устаревшему окружению. Здесь риск состоит не только в конкретных CVE: ограниченная поддержка ОС и старых веток PHP усложняет получение исправлений и совместимость обновлений. Нельзя решать это заменой репозиториев или сборкой PHP на боевом сервере без проверенного плана. Нужны подтверждённая поддержка поставщика либо отдельный проект миграции на актуальную платформу.

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

Рекомендации по обновлению контейнерных образов и источники исправлений приведены в уведомлении Docker Security.

06

Порядок безопасного обновления без остановки контроля

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

Проверка должна идти от инфраструктуры к пользовательскому сценарию. Администратор подтверждает исправленную веб-среду и состояние сервисов. Менеджер сайта проверяет, что посетитель по-прежнему может отправить форму, получить письмо, авторизоваться и оформить заказ. Если форма передаёт лид в CRM, контролируют не только сообщение об успешной отправке, но и появление обращения с корректными полями и источником.

Для резервного копирования и восстановления используйте штатные средства и регламент проекта; базовые сведения по администрированию доступны в документации 1С-Битрикс для администраторов. В Docker дополнительно проверяют тег и digest нового образа, конфигурацию переменных окружения, тома и маршрутизацию трафика.

1. 1

   Зафиксируйте контур. Составьте список доменов, серверов, контейнеров, пулов PHP и ответственных, чтобы не обновить только часть инфраструктуры.

2. 2

   Подтвердите исправление. Сверьте пакет или образ с бюллетенем поставщика, а не только с номером версии, показанным в CLI.

3. 3

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

4. 4

   Проведите обновление. Используйте согласованный штатный механизм поставщика; в Docker пересоберите и разверните новые контейнеры.

5. 5

   Перезапустите нужное. Убедитесь, что веб-сервер и PHP-FPM либо контейнеры используют новый пакет или образ, а не старые процессы.

6. 6

   Примите результат. Проверьте HTTP-сценарии, логи ошибок, заявки и интеграции, затем зафиксируйте доказательства в задаче.

07

Что проверить после обновления на стороне маркетинга

Технический статус «сервис запущен» недостаточен для владельца сайта. После релиза стоит пройти короткий пользовательский маршрут в браузере без административной сессии. Это выявит ошибки кэша, сессий, обработчиков форм и интеграций, которые не всегда заметны в системном мониторинге. Проверку лучше делать на основных устройствах и в период, когда ответственный администратор ещё доступен для отката.

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

Попросите подрядчика приложить не только отчёт о версии, но и список пройденных сценариев. Это даёт маркетингу основание закрыть задачу, а не гадать, не затронуло ли обновление конверсионные точки. При необходимости примеры реальных интерфейсов и процессов можно смотреть в портфолио ICONICA, а не заменять проверку вымышленными скриншотами.

08

Ошибки, которые создают ложное чувство безопасности

Не делайте вывод «нас это не касается», если сайт работает на PHP-FPM. Для CVE-2026-109618 условия эксплуатации у mod_php и PHP-FPM различаются, но из этого не следует, что PHP-FPM полностью защищает. Способ запуска — один из факторов оценки, а не замена исправлению. Аналогично нельзя утверждать, что наличие публичной формы автоматически означает компрометацию: это повод провести оценку и обновление в приоритетном порядке.

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

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

09

Какое решение принять сейчас

Начните не с массовой установки обновлений, а с инвентаризации: какой PHP фактически отвечает на веб-запросы сайта, кто поставляет пакет или образ и есть ли подтверждённое исправление для CVE-2026-109618 и CVE-2026-109619. Для поддерживаемых веток ориентиром служат PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 и последующие исправленные релизы, но окончательный статус определяется также backport в пакете конкретного поставщика.

Если используется BitrixVM 9, проверьте реальную конфигурацию, а не название окружения. Если это BitrixVM 7, CentOS 7 или PHP 8.1 и старее, включите в решение миграцию либо поддержку вендора: точечный патч не отменяет общий риск устаревшей платформы. Для Docker планируйте пересборку образа и замену контейнеров.

Подключайте подрядчика, когда нет полной карты серверов и контейнеров, неизвестен статус пакетов, нужна проверка совместимости или отсутствует безопасное окно работ. Хороший результат — не формальное обновление, а зафиксированная защищённая веб-среда, работающие заявки и CRM-сценарии, проверенный откат и понятная ответственность за дальнейшие обновления.