Патч вышел, и работа перешла к тем, кто обслуживает сайты

21 октября 2026 года команда PHP выпустила экстренные релизы сразу четырёх веток: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Они закрывают две критические уязвимости, CVE-2026-109618 и CVE-2026-109619. Первая использует повреждение памяти при её нехватке, вторая обращается к «устаревшему» глобальному состоянию между запросами. Обе позволяют злоумышленнику выполнить свой код на сервере, не предъявляя никаких учётных данных. Анонс от 20 октября оценил каждую в 9,2 балла из 10 по шкале CVSS v4.0, а в advisory сказано прямо: полного средства защиты, кроме обновления, нет.

Для команды, обслуживающей портал или критическую веб-систему, такой релиз означает прямую работу: обновить, проверить, доложить. И вопросов у такой команды три. Кто попал в зону риска и можно ли было защититься иначе? Что делать со старой версией PHP, если обновить её нельзя? Наконец, кто вообще отвечает за платформу, когда проект PHP прекращает поддержку ветки?

Начнём с того, где именно находится уязвимость.

Уязвим сам интерпретатор, и обновление CMS не спасает

В этот раз уязвимость нашлась не в коде сайта и не в CMS, а в интерпретаторе, то есть в программе, которая исполняет этот код. Затронуты все установки PHP, обслуживающие веб-запросы: PHP-FPM, mod_php, php-cgi и другие режимы. Сайт может стоять на свежей версии WordPress, Drupal или Joomla, но пока не обновлён сам интерпретатор, уязвимость никуда не уходит. Именно такую оценку давали 21 октября эксперты «Гарды WAF» и Positive Technologies: проблема лежит глубже прикладного уровня, и обновление CMS её не закрывает. Причём это уравнивает всех. Самописный портал и известная CMS попадают в один список, потому что ошибка не в их коде, а в среде, которая его исполняет.

По этой же причине инцидент сразу вышел на уровень хостинг-провайдеров. Крупные российские хостеры начали уведомлять клиентов об угрозе во второй половине дня 21 октября. Исправления стали доступны примерно к 17:00 по Москве, и до этого момента многие сайты приостанавливали работу или отключались целиком. Хостер приостанавливал не отдельные проблемные сайты, а целые группы, потому что под ударом оказывались все его клиенты сразу.

Там, где патча не было, закрывали сам путь атаки. «Рег.ру», один из крупнейших регистраторов и хостинг-провайдеров страны, временно ограничил загрузку файлов через панель управления. Клиенты получали ошибки 403, а обработка multipart/form-data, по сообщениям пользователей, была отключена. Техподдержка объяснила меру защитой сайтов. Мера вынужденная и временная, но она точно передаёт суть момента: между публикацией уязвимости и готовым исправлением владельцы систем остаются с риском один на один.

Насколько широк круг тех, кто оказался в таком положении, показывают цифры.

PHP — стандарт рунета, а треть установок живёт на мёртвых ветках

PHP работает на 69,3% сайтов мира, у которых удалось определить серверный язык. Среди сайтов на русском языке его доля ещё выше и составляет 90,8% (данные W3Techs, октябрь 2026 года). По версиям картина такая: 65,3% сайтов на PHP используют восьмую ветку, 26,9% седьмую, 7,7% пятую и 0,1% четвёртую. Около 34,7% сайтов на PHP работают на ветках 7, 5 и 4, которые проект уже не поддерживает.

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

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

Поддержка кончается раньше системы, которая на ней работает

PHP развивается ветками, и у каждой ветки свой срок жизни: два года активной поддержки, затем ещё два года только исправлений безопасности, после чего ветка объявляется устаревшей. Сейчас в поддержке только четыре ветки, от 8.2 до 8.5. При этом исправления безопасности для 8.2 закончатся 31 декабря 2026 года. Для 8.3 поддержка продлится до 31 декабря 2027 года.

Для тех, кто остался на 8.1 и старше, проект PHP обновлений больше не выпускает. Патчи под свежие CVE дистрибутивы и LTS-вендоры, то есть компании, берущие платформу на долгосрочное коммерческое сопровождение, получили заранее. Сама же команда PHP опубликовала лишь минимальные исходные бэкпорты для 7.4, 8.0 и 8.1, и то в расчёте на сборку интерпретатора из исходников.

За этими сроками стоят вполне живые системы. Представим портал, который много лет работает на PHP 7.4. Бизнес-логика срослась с версией, половина модулей давно не обновлялась, а тестового контура для переезда, возможно, и нет. Переезд на восьмёрку для такой команды равен отдельному проекту на месяцы, и каждая новость о критической уязвимости означает выбор между этим проектом и открытым риском.

Отреагировал и регулятор. НКЦКИ, Национальный координационный центр компьютерных инцидентов при ФСБ, письмом от 22 октября предписал объектам критической инфраструктуры, среди которых госорганы, финансовые организации, связь, энергетика, транспорт и медицина, обновить PHP до исправленной версии, проверить серверы антивирусом и изучить журналы. Если быстро обновить систему не получается, центр рекомендует рассмотреть временное ограничение внешнего доступа к уязвимым веб-серверам вплоть до их отключения. Формулировка жёсткая, и она адресована именно владельцам систем, а не сообществу разработчиков платформы.

Обновиться по предписанию может не каждая команда. Остаётся главный вопрос: есть ли в стране компания, готовая взять сопровождение платформы на себя.

Вендора платформы PHP в России публично не нашлось

Мы проверили это по открытым источникам на 23 октября 2026 года, и картина такая. Сопровождение PHP публично прослеживается только у вендоров операционных систем, и то в составе дистрибутивов. «Базальт СПО» ведёт открытую ленту обновлений безопасности для веток АЛЬТ СП 10, 8 СП и СПТ 7, пакеты php8 в них обновляются, в августе 2026 года выходили версии 8.3.33 и 8.4.24. Отдельного бюллетеня под октябрьские CVE в открытой ленте на дату проверки не было. Такая поддержка распространяется на пакет внутри дистрибутива и заканчивается вместе с ним. По сути, это сопровождение операционной системы, а не платформы. Владелец сайта получает исправление, только если сам отслеживает errata своего дистрибутива, сам планирует обновление и сам отвечает за результат.

Коммерческого вендора, который поддерживает PHP именно как платформу, включая устаревшие версии, и отвечает перед клиентом за сбои и уязвимости, поиск не обнаружил. Мы проверили в том числе «Ключ-АСТРОМ», «Сферу», ЕМДЕВ и Zend. Корректная формулировка результата одна: публично не найдено. Публично, потому что поиск шёл по открытым материалам на конкретную дату, а не по закрытым коммерческим предложениям.

Из собранного складывается вывод, ради которого весь разбор и затевался.

Патч кончается, ответственность остаётся

Октябрьская история с PHP вышла далеко за рамки одного релиза и показала, как устроена ответственность за открытую платформу. Сформулируем выводы.

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

2. Сроки поддержки известны заранее и конечны. Даже свежая сейчас ветка 8.2 перестанет получать исправления 31 декабря 2026 года, а через год то же самое ожидает 8.3. Обновление закрывает сегодняшнюю уязвимость, но не отменяет следующий срок.

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

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

Октябрь 2026 года задал вопрос не о том, патчить или нет. Он задал вопрос о том, с кем остаёшься, когда патч кончается.