Сайт открывается, заказы приходят, обновления Битрикс установлены. Это ещё не говорит, что сервер защищён: приложение и исполняющий его PHP обновляются разными механизмами. В октябрьском инциденте ошибка находится именно в PHP. Поэтому привычная кнопка обновления CMS не закрывает задачу.
21 октября 2026 года команда PHP объявила о выпуске исправлений двух критических уязвимостей — CVE-2026-109618 и CVE-2026-109619. Они могут привести к выполнению кода на сервере без авторизации. На 23 октября исправления уже доступны; ждать обозначенных в первоначальной рассылке «17:00» больше не нужно. Ниже — порядок действий для владельца проекта и администратора, с отдельными примерами для PHP-FPM, Apache и контейнеров.
Что произошло: две уязвимости PHP и выполнение кода до приложения #
Первую ошибку удобнее понимать через незавершённую инициализацию. PHP начал готовить данные запроса, столкнулся с нехваткой памяти и прервал работу. На этапе очистки внутренние структуры могут быть обработаны так, будто они уже корректно заполнены. Это повреждение памяти, а не обычная ошибка валидации формы. Подробности опубликованы в уведомлении PHP о CVE-2026-109618 .
У второй ошибки другой жизненный цикл: один запрос оставляет во внутренних полях процесса ссылку на уже освобождённую память. Следующий запрос попадает в тот же процесс и обращается к этому состоянию раньше, чем обычная инициализация успеет его сбросить. Условия зависят от конфигурации и затронутого внутреннего состояния — это разобрано в уведомлении PHP о CVE-2026-109619 .
Два разных механизма — одна обязательная задача обновления
Уязвимость
Где возникает проблема
Практический вывод
CVE-2026-109618
Обработка нехватки памяти и очистка частично подготовленных данных запроса
Проверка входных данных внутри CMS не исправляет ошибку интерпретатора
CVE-2026-109619
Состояние предыдущего запроса остаётся доступным после освобождения его памяти
Настройки сессий закрывают лишь часть известных путей, а не всю ошибку
В сообщении команды PHP отдельно выделен высокий риск для Apache с mod_php: подтверждён сценарий до исполнения прикладного кода. PHP-FPM и другие способы обработки веб-запросов тоже требуют проверки и обновления. Нельзя сделать вывод «у нас nginx, значит проблема не касается»: nginx может передавать запросы уязвимому PHP-FPM.
Пароль администратора и фильтр внутри приложения остаются нужными механизмами, но не служат доказательством защиты от ошибки, срабатывающей до приложения. По той же причине отсутствие открытой регистрации или отдельной формы загрузки не даёт оснований оставить сервер без патча.
Первые исправленные выпуски поддерживаемых веток PHP
Ветка
Первый исправленный выпуск
Как применять
PHP 8.2
8.2.35
Исправленный выпуск этой ветки либо более новый совместимый выпуск
PHP 8.3
8.3.36
Обновление в текущей ветке с проверкой расширений и приложения
PHP 8.4
8.4.27
Исправленный выпуск, совместимый с установленной редакцией продукта
PHP 8.5
8.5.12
Не выбирать ветку только потому, что номер выше: сначала совместимость
Версии исправлений подтверждены журналом изменений PHP . Для пакетов Linux важен ещё и выпуск сборки: поставщик может перенести патч в свою поддерживаемую версию, не меняя её номер до upstream-значения из таблицы. Поэтому сравнение строки 8.3.x с таблицей — полезная проверка, но не окончательное заключение. Нужны номер пакета и бюллетень поставщика с подтверждением исправления обеих CVE.
Для PHP 7.4, 8.0 и 8.1 команда PHP предоставила минимальные исправления исходного кода, хотя эти ветки уже не получают обычную поддержку проекта. Это не означает, что установленный старый пакет автоматически стал безопасным. Нужна подтверждённая исправленная сборка от вашего поставщика либо согласованный переход на поддерживаемую ветку. Сам факт существования патча в репозитории исходников ничего не говорит о сервере магазина.
Битрикс24 в облаке, коробка и сайт: кто обновляет PHP #
Распределение ответственности
Окружение
Кто управляет PHP
Что попросить или проверить
Облачный Битрикс24
Команда облачного сервиса
Официальные сообщения о работах и доступности функций; свою CRM на чужом сервере обновлять не требуется
Коробочный Битрикс24
Владелец инфраструктуры или обслуживающий подрядчик
Сборку PHP, все веб-узлы, перезапуск процессов и ключевые операции CRM
Сайт на 1С-Битрикс у хостинга
Хостинг управляет пакетами, клиент — выбором окружения в пределах панели
Какую сборку использует конкретный домен и включены ли оба исправления
BitrixVM или собственный VPS
Администратор сервера
ОС, источник пакетов, способ подключения PHP и совместимость модулей
Приложение в контейнерах
Команда, собирающая и развёртывающая образ
Исправленный образ, пересозданные экземпляры и проверку каждого работающего узла
Разъяснение Битрикс24 разделяет облако и собственные серверы: для коробки PHP обновляется отдельно от продукта. Не следует переносить временные ограничения облака из сообщения от 21 октября на текущий момент без нового подтверждения. Для своей инфраструктуры задача конкретнее: установить патч и подтвердить, что запросы выполняет уже исправленная сборка.
Как узнать версию PHP на сайте: CLI и веб-процесс — разные проверки #
Начать удобно с консоли. Команда покажет доступный в текущем окружении CLI-интерпретатор, перечень ini-файлов и расширений. Это инвентаризация, а не итог проверки сайта: у заданий cron, одного домена и соседнего домена могут быть разные бинарные файлы и конфигурации.
inventory-cli.shShell
# Только чтение: CLI-версия, конфигурация и модулиcommand-vphpphp-vphp--iniphp-m# Службы PHP-FPM на системе с systemdsystemctllist-units--type=service--all'php*fpm*'
Затем проверяют именно тот PHP, которому веб-сервер передаёт запросы этого сайта. Для FPM находят сокет или адрес в конфигурации виртуального хоста, затем соответствующий пул. При mod_php смотрят загруженный модуль Apache. При нескольких сайтах одной команды php -v на сервере недостаточно.
Для контролируемой проверки можно временно использовать небольшой диагностический обработчик. Его размещают только за уже настроенным ограничением доступа — например, в служебном location с допуском администратора по IP. Имя файла не является защитой. После проверки обработчик удаляют; публиковать открытый phpinfo() не требуется.
runtime-check.phpPHP
<?php// Только для закрытого служебного URL. Удалить после проверки.header('Content-Type: application/json; charset=utf-8');header('Cache-Control: no-store');$runtime=['php_version'=>PHP_VERSION,'sapi'=>PHP_SAPI,'loaded_ini'=>php_ini_loaded_file(),'scanned_ini'=>php_ini_scanned_files(),'upload_progress'=>ini_get('session.upload_progress.enabled'),];if(PHP_VERSION_ID>=80500){$runtime['fatal_error_backtraces']=ini_get('fatal_error_backtraces');}echojson_encode($runtime,JSON_PRETTY_PRINT|JSON_UNESCAPED_SLASHES);
PHP_VERSION и PHP_SAPI описывают процесс, исполнивший этот запрос. Функции ini показывают, откуда он прочитал настройки. Это помогает найти распространённое расхождение: в консоли уже новая версия, но домен продолжает работать через другой FPM-пул. Смысл SAPI и списка дополнительных ini-файлов описан в документации PHP.
Обновление PHP в Битрикс: сначала пакет и совместимость, затем перезапуск #
Экстренное исправление в используемой ветке и переход на другую ветку — разные объёмы работ. Во время инцидента сначала ищут совместимую исправленную сборку текущего окружения. Если проект работает только на неподдерживаемой ветке, отдельно решают задачу поставщика патча или миграции. Автоматически переключать репозиторий на PHP 8.5 из-за большего номера — плохой способ чинить безопасность.
До изменения сохраняют конфигурацию, перечень пакетов и резервную копию данных, проверяют возможность восстановления. На тестовой копии проходят хотя бы авторизацию, работу с файлами и основной бизнес-сценарий. Важно заранее определить, кто принимает решение при сбое. Возврат старого уязвимого образа может восстановить работу, но одновременно вернуть угрозу; это не приемлемый постоянный итог.
RHEL-подобная система и BitrixVM: проверьте источник сборки #
Для окружения с DNF сначала смотрят установленное и доступное. Команды ниже ничего не устанавливают: последняя показывает предполагаемую транзакцию и отказывается от выполнения. В окружениях с параллельными ветками названия пакетов могут отличаться, например иметь префикс; подставлять обычные имена без инвентаризации нельзя.
DNF может не показать отдельный бюллетень, даже когда нужный пакет есть: это зависит от метаданных репозитория. Документация Red Hat по security advisories объясняет работу updateinfo. Отсутствие записи не заменяет проверку поставщика, а сообщение «обновлений нет» не доказывает безопасность.
Установку выполняют после проверки состава транзакции и подтверждения наличия патча. Все используемые расширения должны остаться совместимыми. В BitrixVM учитывают её версию и принятую схему сопровождения, а не смешивают инструкции для разных поколений окружения. Здесь намеренно нет универсальной команды смены репозитория: она зависит от установленной системы.
Debian или Ubuntu: выберите пакеты той ветки, которая обслуживает сайт #
В примере используется ветка 8.3. Для другой ветки меняются имена пакетов, расширений и службы. Сначала проверяют доступный выпуск и симуляцию, затем администратор устанавливает подтверждённую исправленную сборку из согласованного источника. Эти команды не добавляют новые репозитории.
Список из трёх пакетов — пример проверки, а не полный состав вашего сервера. Нужно учесть все установленные расширения и выбранный режим Apache или FPM. Пакет поставщика с backport проверяют по его полному выпуску и бюллетеню. Требовать только буквального номера из upstream-таблицы в таком окружении неправильно.
После установки пакетов новые файлы на диске ещё не равны новым процессам в памяти. При FPM заменить нужно его воркеры; при mod_php — процессы Apache. Проверку конфигурации выполняют до перезапуска, имя службы берут из реального окружения. Пример ниже относится только к PHP-FPM 8.3 в системе, где существуют указанные бинарный файл и unit.
restart-selected-fpm.shShell
# После установки исправленной сборки, в согласованное окно работsudophp-fpm8.3-t# Продолжать только после успешной проверки конфигурацииsudosystemctlrestartphp8.3-fpmsudosystemctlstatusphp8.3-fpm--no-pager
В RHEL-подобном окружении имена могут быть php-fpm и httpd , а при параллельных установках — другими. Статус active подтверждает запуск службы, но не версию обработчика каждого домена. Поэтому после перезапуска возвращаются к проверке веб-процесса, а не заканчивают на зелёной строке systemd.
PHP в Docker: обновить образ и заменить контейнер #
Установка исправлений на хосте не обновляет PHP внутри контейнера. Нужно получить или собрать исправленный образ приложения, сохранить необходимые расширения, проверить конфигурацию и развернуть новые экземпляры. Если образ собирается из Dockerfile, пересобирают именно приложение с исправленной базой; скачивание произвольного чистого PHP-образа не заменяет эту сборку.
Ниже — пример для сервиса с условным именем php , которому уже назначен проверенный исправленный образ. Его имя и конфигурацию берут из своего Compose-проекта. Перед пересозданием убеждаются, что загруженные файлы и другие постоянные данные вынесены в тома либо внешнее хранилище, и резервная копия пригодна к восстановлению.
deploy-fixed-image.shShell
# Для сервиса php с уже выбранным исправленным образомdockercomposepullphpdockercomposeup-d--no-depsphpdockercomposepsphpdockercomposeexecphpphp-v
Compose pull только скачивает образ. Compose up заменяет контейнер, когда образ или конфигурация изменились. Если тег и образ остались прежними, одна команда pull не подтверждает установку патча. Контроль версии через exec полезен для инвентаризации, но веб-процесс всё равно проверяют отдельно.
Для кластера запишите соответствие «экземпляр → image digest → сборка PHP». Оставшийся старый узел продолжит принимать часть запросов, даже если остальные уже обновлены. Это типичная причина, почему «мы обновили Docker» не даёт однозначного ответа о защищённости приложения.
Временные меры: что даёт session.upload_progress.enabled #
Если исправление пока невозможно установить, можно уменьшить доступность отдельных путей эксплуатации. Для CVE-2026-109619 PHP рекомендует отключить upload progress на уровне конфигурации, применяемой до разбора запроса, и перезапустить все соответствующие воркеры. Вызов ini_set() внутри сайта для этой задачи слишком поздний. .user.ini в FPM тоже не заменяет нужный ранний уровень настройки.
temporary-php-setting.iniINI
; Временная мера для части путей CVE-2026-109619.; Добавить в фактически загружаемый серверный ini-файл.session.upload_progress.enabled= Off; Только для PHP 8.5: ещё один подтверждённый путь.; Для остальных веток эту строку не добавлять.; fatal_error_backtraces = Off
Эта настройка не устраняет CVE-2026-109618 и не закрывает все варианты CVE-2026-109619. Не следует оформлять её как «готовое решение без обновления». Отключение показа ошибок тоже не исправляет обращение к устаревшему состоянию. Если нельзя быстро получить патч, с администратором рассматривают ограничение внешнего доступа на время работ.
У рекомендаций для нехватки памяти есть отдельная цена по доступности. Например, снятие PHP memory_limit без границ ресурсов на уровне контейнера или cgroup может лишить сервер памяти. Не переносите такую настройку из заметки в production автоматически: нужен разбор полного набора мер, доступной памяти и поведения воркеров. Цель временных ограничений — выиграть время до патча, а не заменить его.
Обновление считается завершённым после проверки каждого узла, а не одного ответа за балансировщиком.
Как проверить сайт и Битрикс24 после обновления PHP #
Приёмка: что должно быть подтверждено
Проверка
Что считаем подтверждением
Что подтверждением не является
Исправление обеих CVE
Исправленный upstream-выпуск либо бюллетень поставщика для точной сборки
Команда обновления завершилась без ошибки
Рабочий PHP
Версия и конфигурация из веб-процесса нужного домена
Только вывод php -v в SSH
Все экземпляры
Проверен каждый веб-узел или контейнер по инвентаризации
Один удачный запрос через балансировщик
Основные операции
Пройдены вход, файлы, заказы или сделки, фоновые задания и обмены
Открывается главная страница
Наблюдение после релиза
Проверены ошибки PHP, ответы 5xx, очереди и состояние служб
Никто пока не пожаловался
Для магазина проверяют авторизацию, корзину, оформление заказа, загрузку файлов и обмен с 1С. Платёжный сценарий проходят в тестовом режиме платёжной системы, без случайного списания с клиента. Для коробочного портала — вход, создание и изменение сделки, документы, почту, роботов и используемые интеграции. В фоновых заданиях отдельно смотрят интерпретатор cron: он может отличаться от веб-версии.
Полезно сохранить короткий протокол: какие узлы проверены, какие пакеты или образы установлены, когда заменены процессы, кто выполнил функциональную проверку и какие проблемы остались. Пример структуры ниже условный — это форма отчёта, а не данные о реально проверенном сервере.
verification-record.jsonJSON
{"node":"web-01","runtime":"php-fpm","php_version":"8.3.36","package_or_image":"<полный выпуск пакета или digest образа>","both_cves_fixed":"<ссылка на подтверждение поставщика>","workers_restarted":true,"web_runtime_checked":true,"business_checks":["login","file_upload","order","exchange_1c"]}
Сам патч не доказывает, что до обновления сервер не был скомпрометирован. Если есть посторонние файлы, неизвестные учётные записи или подозрительные исходящие подключения, сохраните журналы и артефакты и подключите специалистов по реагированию. Удалить заметный файл и назвать инцидент закрытым — значит потерять возможность понять, что ещё изменилось.
Обновление модулей продукта не заменяет исправление серверного PHP. Это две разные части сопровождения. Нужно проверить и CMS, и фактически используемую сборку интерпретатора; выполненный SiteUpdate сам по себе не является подтверждением патча PHP.
Нет. Для ветки 8.2 выпущен исправленный PHP 8.2.35. Выбор другой ветки зависит от совместимости продукта, модулей и кода. Экстренное исправление и плановую миграцию стоит разделить, если поставщик текущей ветки даёт подходящий патч.
Попросите подтвердить исправление обеих CVE для PHP конкретного домена: полный выпуск сборки, применённый обработчик и замену рабочих процессов. Если доменов несколько и у них разные версии PHP, подтверждение нужно по каждому окружению, а не только по серверу в целом.
Можно закрыть только загрузку файлов и продолжить работу? #
Ограничение загрузок может снизить доступность отдельных сценариев, но не является полным исправлением этих ошибок. Решение о временном режиме работы принимают с администратором по рекомендациям поставщика; установленную задачу обновления при этом не отменяют.
Если вы не уверены, какая сборка обслуживает сайт и установлены ли оба исправления, NetLab поможет провести технический аудит сайта или приложения : проверить окружение, конфигурацию, журналы и зависимости, определить риски и приоритет работ. Для коробочного портала можно начать с технического аудита Битрикс24 .
Если требуется установка исправлений или переход на совместимую ветку, поможем с обновлением платформы и версии PHP : подготовим тестовую копию, проверим расширения и доработки, согласуем окно работ и проверим основные операции после запуска. Оставьте заявку — укажите CMS, тип размещения и известную версию PHP; пароли и ключи в форму отправлять не нужно.
