21 октября 2026 года разработчики PHP выпустили экстренные обновления, устраняющие две критические уязвимости — CVE-2026-109618 и CVE-2026-109619. Они могут привести к удалённому выполнению кода без авторизации. Владельцам сайтов, интернет-магазинов и корпоративных порталов нужно проверить серверную версию PHP и установить исправленную сборку.
Что произошло и кого это касается
В уведомлении PHP от 21 октября перечислены веб-окружения PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Речь идёт об интерпретаторе, поэтому название CMS само по себе не определяет защищённость сайта. Обновление приложения не подменяет исправление серверного компонента.
Обе ошибки получили критическую оценку CVSS 4.0 — 9,2. CVE-2026-109618 связана с некорректным состоянием данных при нехватке памяти. CVE-2026-109619 — с внутренним состоянием запроса, которое может сохраниться в рабочем процессе после освобождения соответствующей памяти.
Для mod_php подтверждено выполнение кода по HTTP без входа в приложение. Условия для разных способов запуска PHP различаются: наличие PHP-FPM не означает автоматическую защищённость. При этом демонстрация одной цепочки атаки не доказывает, что одинаковый запрос сработает на любом сервере.
Какие версии содержат исправления
Исправления включены в следующие выпуски поддерживаемых веток:
Выбирайте исправленный выпуск своей ветки или более новый совместимый пакет. Переход между ветками — отдельная задача: он требует проверки приложения и расширений. Если PHP поставляется дистрибутивом или LTS-вендором, исправление может быть перенесено в пакет с другим номером версии. Подтверждение ищите в бюллетене и журнале изменений поставщика.
PHP 8.1 и старше: регулярная поддержка этих веток проектом PHP завершена. Однако команда безопасности предоставила минимальные исправления исходного кода для 7.4, 8.0 и 8.1. Это не возобновление поддержки и не гарантия наличия готового пакета у вашего хостинга. Уточните доступность исправленной сборки и запланируйте переход на поддерживаемую ветку.
Что делать владельцам «1С-Битрикс» и Битрикс24
«1С-Битрикс» подтвердил, что проблема находится в PHP, а не в коде его продуктов. Для сайта на «1С-Битрикс: Управление сайтом» и коробочного Битрикс24 обновление устанавливает администратор сервера или хостинг. SiteUpdate эту задачу не решает.
В BitrixVM порядок действий зависит от конфигурации. При Apache с mod_php после обновления необходимо перезапустить Apache; при PHP-FPM — соответствующие службы FPM. Перезапуск одного nginx не обновляет код уже работающих процессов PHP.
Для облачного Битрикс24 серверными обновлениями занимается поставщик сервиса. Пользователю не требуется искать доступ к PHP или менять настройки портала. Статус временных ограничений нужно проверять в актуальных сообщениях поддержки: факт выхода патча сам по себе не подтверждает восстановление всех облачных функций.
Как проверить результат обновления
Ниже — рекомендуемый нами порядок работы для администратора. Он помогает проверить не только установку пакета, но и состояние приложения после обслуживания.
- Составить список окружений. Учесть все узлы, контейнеры, пулы PHP и сайты. Обновление одного сервера не закрывает остальные экземпляры.
- Подготовить восстановление. Проверить резервную копию файлов, базы и конфигурации, а также совместимость обновления на тестовом окружении.
- Установить подтверждённое исправление. Использовать пакеты доверенного поставщика. В контейнерной среде обновить или пересобрать образ и пересоздать контейнеры, сохранив данные и тома.
- Заменить старые рабочие процессы. Выполнить предусмотренный для окружения перезапуск и убедиться, что старые воркеры больше не обслуживают запросы.
- Проверить веб-приложение. Подтвердить сборку, которая исполняет запросы сайта, затем проверить вход, формы, загрузки, обмены и журналы ошибок.
Команда php -v полезна для проверки консольного интерпретатора, но не доказывает, что сайт использует ту же сборку. Например, командная строка и отдельный пул PHP-FPM могут работать на разных версиях. Проверку веб-окружения проводите через защищённую диагностику; не оставляйте публичный phpinfo() с конфигурацией сервера.
Если обновление нельзя установить немедленно
Для сценария с состоянием сессии отключите отслеживание загрузки файлов в конфигурации, которая применяется до разбора запроса:
session.upload_progress.enabled = 0Используйте php.ini, настройки пула FPM или серверную конфигурацию и перезапустите все воркеры. Вызов ini_set() и FPM .user.ini не подходят для этого раннего этапа. Как объясняет документация PHP, обработка upload progress происходит до запуска скриптов приложения. Отключение этой функции не равнозначно запрету загрузки файлов.
В PHP 8.5 дополнительно предусмотрена мера fatal_error_backtraces = 0. Она блокирует подтверждённый путь через состояние обратной трассировки, но не все варианты ошибки. Также проверьте устаревшие и ошибочные настройки, вызывающие диагностику при ранней инициализации: скрытие сообщений об ошибках проблему не устраняет.
Для ошибки, связанной с памятью, PHP рекомендует ограничивать размер и сложность входящих запросов. В уведомлении приведены ориентиры post_max_size = 8M без необходимости загрузок и 32M при загрузках; значение upload_max_filesize должно быть меньше. Эти числа не являются универсальными безопасными порогами: ограничения нужно согласовать с формами, импортом и обменами вашего проекта.
В официальном техническом разборе есть и временное административное снятие лимита memory_limit. Оно требует отдельного контроля ресурсов контейнера или cgroup и не даёт полной защиты. Мы не предлагаем применять его как массовую настройку по одной строке: решение должен принимать администратор с учётом доступности сервиса. Если исправление недоступно, рассмотрите временное ограничение внешнего доступа.
Что поручить обслуживающей организации
Запросите подтверждение по каждому окружению: установленная сборка или бюллетень с перенесённым исправлением, время перезапуска, результат проверки веб-запросов и основных функций. Если остаются уязвимые экземпляры, зафиксируйте временные ограничения и срок установки патча.
Не откладывайте обращение из-за того, что сайт продолжает открываться. Работоспособность и наличие исправления — разные проверки. При обнаружении признаков взлома потребуется отдельное расследование: установка обновления сама по себе не удаляет уже внедрённый код.