Критические уязвимости PHP и безопасное обновление сайта

Разработчики PHP выпустили экстренные обновления безопасности, которые устраняют две критические уязвимости — CVE-2026-109618 и CVE-2026-109619. Обе получили оценку 9,2 из 10 по CVSS 4.0 (международная шкала оценки опасности уязвимостей) и могут позволить выполнить код на сервере без авторизации. Владельцам сайтов и интернет-магазинов необходимо проверить серверное окружение и установить исправления.

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

Как работают уязвимости PHP2Shell

Общее название PHP2Shell объединяет две ошибки управления памятью при обработке HTTP-запросов. Они возникают в разных ситуациях, поэтому одна настройка PHP не перекрывает все способы эксплуатации.

CVE-2026-109618 связана с нехваткой памяти, или OOM. PHP может прервать обработку, когда внутренние данные запроса ещё не полностью подготовлены. При завершении запроса интерпретатор обращается к ним как к корректным. Опасен не только большой размер тела запроса: значение имеет и то, сколько памяти потребуется для его разбора. Исправление меняет обработку OOM, сохраняя возможность ограничивать расход памяти.

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

Для Apache с mod_php подтверждена атака, которая срабатывает до выполнения кода сайта. В случае PHP-FPM условия отличаются: для CVE-2026-109619 подтверждён сценарий, зависящий от операций приложения. Это не основание считать FPM защищённым. PHP относит к группе риска все установки, обслуживающие веб-запросы, включая php-cgi, FrankenPHP и LiteSpeed.

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

Чем это угрожает сайту и интернет-магазину

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

Например, если приложению разрешено читать настройки подключения к базе данных, атакующий потенциально получает доступ к тем же секретам. Возможность изменять файлы сайта создаёт риск подмены страниц, внедрения вредоносного JavaScript, фишинга или скрытого перенаправления посетителей. Для интернет-магазина это может затронуть заказы, клиентские данные и путь покупателя к оплате. Конкретный объём доступа зависит от прав, изоляции и настроек инфраструктуры.

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

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

Какие версии PHP содержат исправления

21 октября 2026 года исправления двух CVE вышли в следующих стабильных релизах. Для стандартных сборок PHP ориентир — исправленный релиз своей ветки либо более новый релиз с этими исправлениями.

У поставщика Linux-дистрибутива или LTS-поддержки исправление может быть перенесено в прежнюю версию пакета — это называется backport. Поэтому одной строки с номером PHP недостаточно: нужны номер сборки и подтверждение поставщика, что закрыты обе CVE. И обратная ситуация возможна: установленный новый пакет ещё не означает, что старые рабочие процессы остановлены.

PHP 8.1 и более старые ветки не получают обычных обновлений от проекта PHP. Для 7.4, 8.0 и 8.1 команда опубликовала минимальные исправления в исходном коде. Это не возобновление полноценной поддержки: готовую сборку нужно получать у поставщика либо сопровождать самостоятельно. Если подтверждённого исправления нет, требуется переход на поддерживаемую ветку с проверкой совместимости.

Не обязательно одновременно с экстренным исправлением переходить, например, с PHP 8.2 на 8.5. Если текущая ветка поддерживается, обновление внутри неё обычно позволяет отделить срочное устранение уязвимости от более крупной миграции. Совместимость всё равно нужно проверить. Однако для PHP 8.2 также следует запланировать переход: поддержка этой ветки проектом PHP заканчивается 31 декабря 2026 года.

Уточнение PHP от 23 октября о работе с сессиями

После релиза PHP сообщил об отдельном редком сценарии RCE, для которого готовится advisory CVE-2026-115560. Он требует сочетания условий: в конфигурации выбран session.serialize_handler=php_binary или php_serialize, приложение меняет его на php через ini_set() до session_start(), а отслеживание загрузок в сессии остаётся включённым.

До следующего регулярного исправления PHP рекомендует session.upload_progress.enabled=0. Если настройку уже отключили, её следует сохранить. Приложения, которые не меняют обработчик сериализации во время выполнения, могут оставлять эту функцию включённой. Это уточнение нужно учитывать отдельно от установки обновлений, закрывающих две уязвимости от 21 октября.

Чек-лист безопасного обновления PHP

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

1. Составьте список окружений. Проверьте основной сайт, поддомены, тестовые копии, API, панели управления и контейнеры. Для каждого зафиксируйте обработчик PHP, поставщика пакетов и ответственного. На виртуальном хостинге запросите подтверждение исправления обеих CVE для конкретного домена и выбранной версии PHP.
2. Проверьте PHP, который обслуживает веб-запросы. Результат php -v в консоли может относиться к другому интерпретатору. Сопоставьте настройки сайта в панели или веб-сервере с нужным FPM-пулом либо обработчиком Apache. Не оставляйте публично доступный phpinfo(): диагностическую информацию проверяйте через защищённый доступ и затем удаляйте.
3. Подготовьте восстановление и проверку совместимости. Сохраните файлы, базу данных, конфигурацию и список пакетов, убедитесь, что копию можно восстановить. На изолированной копии проверьте CMS, расширения PHP, сторонние модули, собственные доработки и обмен с 1С. Сохраните действующие настройки и версии для сравнения.
4. Установите исправление из доверенного источника. Используйте обновление своего поставщика или проверенную сборку. В контейнерной инфраструктуре обновите образ и пересоздайте работающие экземпляры; замены тега в конфигурации недостаточно. Проверьте все узлы за балансировщиком и шаблоны, из которых создаются новые серверы.
5. Завершите старые процессы и подтвердите результат. Перезапустите соответствующие PHP-процессы; для mod_php потребуется обновить работающие процессы Apache. Убедитесь, что запросы обслуживает исправленная сборка, а нужные настройки применились. Отдельно проверьте фоновые задания и долгоживущие обработчики, использующие PHP.
6. Пройдите путь реального пользователя. Проверьте вход, поиск, каталог, корзину, оформление заказа, формы и загрузку файлов. Для оплаты используйте тестовый сценарий провайдера. Проверьте обмен с 1С, уведомления, вебхуки и задания по расписанию, затем сравните ошибки и задержки с обычным уровнем.
7. Зафиксируйте состояние после работ. Сохраните номера сборок, время перезапуска, результаты проверки и оставшиеся ограничения. Если требуется откат, возвращайте совместимую исправленную сборку. Откат на уязвимую версию допустим только с изоляцией от внешних запросов до повторного устранения проблемы.

Что проверить в логах и при подозрении на взлом

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

Сохраните доступные журналы веб-сервера, прокси, PHP-FPM или Apache, WAF и системных служб, отметьте часовой пояс и время обновления. Затем сопоставьте события между источниками. Не ограничивайтесь поиском номера CVE: он не обязан присутствовать в запросе.

Повод для разбора — необычные серии multipart-запросов, всплески HTTP 5xx, нехватка памяти, аварийные завершения PHP и повторяющиеся ошибки на отдельных маршрутах. Advisory PHP отдельно предлагает искать фатальные ошибки, тайм-ауты и предупреждения при инициализации или завершении запроса. Такие события сами по себе не доказывают взлом; отсутствие ошибок тоже не гарантирует безопасность.

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

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

Временные меры до установки исправлений

Если обновление откладывается, наиболее надёжный способ сократить внешнюю экспозицию — закрыть доступ к уязвимому обработчику на уровне сети или прокси. Для закрытого сервиса можно использовать VPN или список разрешённых адресов. Для публичного сайта — временно отдавать статическую страницу, не передавая запросы в PHP. Режим обслуживания внутри CMS этого не гарантирует.

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

Настройка session.upload_progress.enabled=0 перекрывает подтверждённые сессионные пути CVE-2026-109619, но не все варианты атаки. Применять её нужно до разбора запроса, через серверную конфигурацию или php.ini, с перезапуском всех рабочих процессов; ini_set() в коде сайта для этой цели слишком поздно. На PHP 8.5 отключение fatal_error_backtraces закрывает ещё один подтверждённый путь, но также не заменяет патч.

Для CVE-2026-109618 PHP описывает временное административное снятие memory_limit вместе с ограничениями запросов и контролем памяти извне. Это требует расчёта ресурсов: memory_limit=-1 без защиты от перерасхода памяти способен ухудшить доступность. Базовый патч меняет саму обработку OOM; настройка лимита его не заменяет.

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

Первый Бит поможет обновить PHP и проверить работу сайта

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

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

Заказать проверку и обновление PHP