Уязвимости PHP на старом Битриксе: что проверить перед обновлением

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

Что произошло в октябре 2026 года

21 октября команда PHP сообщила о двух критических уязвимостях: CVE-2026-109618 и CVE-2026-109619. Они могут позволить человеку без учётной записи выполнить посторонний код на сервере с правами рабочего процесса PHP. Для магазина это риск доступа к данным и файлам, которые доступны этому процессу.

• →CVE-2026-109618. При нехватке памяти PHP мог прервать обработку запроса с частично подготовленными внутренними данными, а затем обратиться к ним при завершении запроса. Для Apache с mod_php разработчики подтвердили выполнение постороннего кода до запуска кода сайта. Подробности - в официальном описании уязвимости.
• →CVE-2026-109619. Рабочий процесс мог сохранить ссылку на память прошлого запроса и обратиться к ней при следующем. Условия зависят от версии, настроек и операций PHP. Это не означает, что любой запрос взломает любой сайт. Подтверждённые варианты и ограничения перечислены во втором уведомлении PHP.

Команда PHP относит к группе риска установки, которые обслуживают веб-запросы: в том числе PHP-FPM и Apache с mod_php. Для mod_php риск выделен как наиболее высокий. Обновить только Битрикс или поставить фильтр внутри сайта недостаточно: подтверждённый путь через mod_php срабатывает ещё до кода приложения.

Почему у старого магазина обновление сложнее одной команды

22 октября мы обновляли PHP у действующего магазина на 1С-Битрикс. На одном сервере работали несколько сайтов. Основной и ещё один сайт использовали системный PHP 8.1 как модуль Apache. Другой сайт работал через PHP-FPM 7.4 в отдельном контейнере - изолированном окружении со своими пакетами и настройками.

Ответ команды php -v в терминале показывает только запущенный ею PHP. Для каждого сайта мы установили, какой обработчик принимает запрос, где лежат его настройки и какие расширения загружены. После установки повторили проверку через веб-запрос: наличие нового пакета на диске ещё не доказывает, что сайт уже работает на нём.

Срочное исправление и переход на новую ветку решают разные задачи

В этом обновлении сохранили ветки 8.1 и 7.4 ради совместимости старого кода. Выбрали подписанные пакеты Remi с перенесёнными исправлениями. В журнале обеих сборок перечислены CVE-2026-109618 и CVE-2026-109619 с пометкой "Mitigation fix Avoid state corruption via bailout". Версии пакетов сверили с репозиторием Remi и журналами установки.

В строке версии PHP 7.4 осталось 7.4.33, хотя сборка пакета изменилась. Поэтому по одному номеру PHP нельзя решить, установлен ли перенос исправлений: нужны полный номер пакета, его источник и журнал изменений.

Как подготовили копию при нехватке места

На диске оставалось 19 ГБ, а две папки загрузок занимали около 43 и 6 ГБ. Полная дополнительная копия сервера на этот же диск не помещалась. Состав резервирования определили под операцию: меняли PHP и его зависимости, код Битрикса и фотографии товаров обновление не затрагивало.

• →Сохранили рабочие базы данных, код сайтов без папок загрузок и кэша, конфигурацию служб.
• →Сохранили прежние файлы PHP, сведения об установленных пакетах и образ контейнера для возврата.
• →Проверили целостность архивов и контрольные суммы. Копию получили на отдельный компьютер и сверили: суммы четырёх основных архивов совпали с сервером.

Это была копия для отката обновления PHP. Восстановить весь магазин после потери диска только из неё нельзя: фотографий и других загрузок в ней нет. Для защиты от потери сервера нужна отдельная копия всех данных. Как разделить копирование базы, кода и загрузок, объясняем в статье о частоте резервного копирования.

Что проверили до переключения служб

Новую сборку PHP 8.1 запустили в отдельном Apache, доступном только с самого сервера. На текущем коде сайта открылись главная, каталог, корзина и страница входа. Новых критических ошибок при этих проверках не обнаружили. Такая проверка находит часть проблем совместимости; общая база и файлы всё равно требуют осторожности, поэтому заказы и заявки из этого окружения не отправляли.

Для PHP 7.4 создали копию контейнера без сети и доступа к рабочим каталогам. В ней установили пакеты, проверили загрузку расширений и настройки PHP-FPM, затем вернули прежнюю сборку. Возврат прошёл проверку до изменения работающего контейнера. Полную работу магазина в этой изолированной копии не проверяли.

Отдельная трудность: прежних исходных пакетов уже не было в проверенных каталогах поставщика. Поэтому для возврата сохранили установленные файлы и согласованный снимок служебной базы пакетов Linux. Это решение зависело от состояния конкретного сервера. Его нельзя переносить на другой хостинг как готовый набор команд.

Что подтвердили после установки

Обновили пакеты PHP и необходимые зависимости, затем перезапустили Apache и отдельно PHP-FPM в контейнере. Битрикс и сервер базы данных в этой операции не обновляли. Через временную защищённую проверку подтвердили версии PHP, которые исполняли веб-запросы; после проверки служебные файлы удалили.

• →Списки загруженных расширений совпали с исходными: по 46 на двух сайтах и 53 на третьем.
• →11 проверенных страниц трёх сайтов и главные двух региональных поддоменов ответили HTTP 200.
• →В браузере открыли карточку товара, добавили товар в тестовую корзину и удалили его. Формы трёх сайтов открылись; на двух проверили отображение капчи.
• →В заключительной проверке не обнаружили новых критических ошибок PHP. Исправленный контейнер сохранили отдельным образом для последующего запуска.

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

Что поручить специалисту, если у вас похожий магазин

• 01Составить список обработчиков. Для каждого сайта, поддомена и задания по расписанию указать PHP, способ запуска, источник пакетов и настройки. Контейнеры проверить отдельно.
• 02Подтвердить исправления. Назвать обе CVE, полные версии исправленных пакетов и источник. Для старой ветки пояснить, какие исправления поставщик перенёс и что остаётся за границами поддержки. Сверить дополнение PHP от 23 октября.
• 03Описать состав копии и способ возврата. Что сохраняется, что исключено, где лежит отдельная копия и как проверена её целостность. Отдельно - как сохранить заказы, которые поступят после начала работ.
• 04Проверить новое окружение заранее. Согласовать изоляцию, доступ к рабочим данным и запрет случайных отправок. Если возврат удалось проверить только для части системы, это указать в плане.
• 05Согласовать проверку продаж. После установки проверить работающий веб-PHP и действия покупателя. Тестовый заказ, оплату, письмо и запись в CRM проводить по согласованному сценарию, с отметкой теста и уборкой его следов.

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