Критические уязвимости PHP в октябре 2026: что проверить владельцу сайта

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

Важно отделять факт обнаружения уязвимости от факта взлома конкретного ресурса. Само использование PHP не означает, что сайт уже скомпрометирован. Однако откладывать обновление публичного сервера опасно: уязвимости находятся ниже уровня прикладной логики и могут затрагивать разные CMS и самописные проекты.

Что произошло 21 октября

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

Уязвимости получили идентификаторы CVE-2026-109618 и CVE-2026-109619. По состоянию на 23 октября их нельзя считать проблемой только какой-либо одной CMS. Если на сервере используется уязвимая ветка PHP для обработки веб-запросов, оценка риска нужна независимо от того, написан сайт на WordPress, Drupal, собственном фреймворке или без него.

Какие версии исправлены

21 октября опубликованы исправленные версии PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Администратору следует определить установленную ветку и обновить её как минимум до соответствующей исправленной версии. Для PHP 8.1 и более старых веток ситуация сложнее: они не получают обычные официальные обновления в рамках поддерживаемого цикла, поэтому требуется план миграции на поддерживаемую версию или проверенная поддержка безопасности от поставщика дистрибутива.

Не стоит делать вывод о защищённости только по номеру, показанному в панели хостинга. Поставщики Linux иногда переносят исправления в свои пакеты без изменения основного номера версии. В этом случае запросите у провайдера конкретный номер пакета и подтверждение, что исправлены обе CVE.

Как понять, относится ли проблема к вашему сайту

Первый шаг — инвентаризация. Составьте список доменов, поддоменов, админок, API, тестовых стендов и фоновых задач. У каждого компонента должны быть понятны хостинг, версия PHP, ответственный за обновления и способ резервного восстановления. Не забудьте забытые сайты и старые административные панели: именно их часто не включают в план сопровождения.

Второй шаг — проверить окружение. Узнайте, какая версия PHP обслуживает реальные веб-запросы. Версия командной строки и версия веб-сервера могут различаться. Уточните способ запуска — PHP-FPM, Apache-модуль или другой обработчик — и есть ли опубликованный патч от поставщика. Если используется виртуальный хостинг, задайте вопрос технической поддержке письменно и сохраните ответ.

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

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

Почему WAF и резервная копия не заменяют патч

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

Для бизнеса главный риск не ограничивается простоем. Если злоумышленник получает возможность выполнять код с правами веб-процесса, под угрозой могут оказаться конфигурация приложения, секреты интеграций, персональные данные и доступность сервиса. Конкретные последствия зависят от прав процесса и устройства инфраструктуры — заранее считать их одинаковыми для всех сайтов нельзя.

Чек-лист для владельца бизнеса

• Назначить ответственного за обновление каждого публичного сайта и API.
• Получить подтверждение версии PHP и наличия исправлений для обеих CVE.
• Сделать проверяемую резервную копию и подготовить план отката.
• Обновить сначала тестовую среду, затем рабочую в согласованное окно.
• Проверить оформление заказов, оплату, формы, CRM и личный кабинет.
• Сохранить технический отчёт: что обновлено, когда и как проверено.
• При подозрении на взлом — изолировать затронутые компоненты и провести расследование, а не просто перезапустить сервер.

Что это означает для разработки и сопровождения

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

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

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