В ядре PHP исправили уязвимости, позволяющие удалённо выполнить код

21 октября 2026 года команда PHP выпустила обновление, исправляющее несколько уязвимостей безопасности памяти в ядре языка. Как пишет Wiz Research, исследователи продемонстрировали удалённое выполнение кода без авторизации и чтение памяти PHP-процесса. Владельцам сайтов стоит проверить, какая версия PHP обслуживает их сайт, и установить обновление безопасности: проблема находится в самом PHP, а не только в приложениях на нём.

Что обнаружили в PHP

Исследователи объединили ошибки под номерами CVE-2026-109618 и CVE-2026-109619. Максимальная оценка серьёзности достигает 9,2 по CVSS. По данным Wiz, каждая версия PHP, выпущенная за последнее десятилетие, затронута хотя бы одной из проблем; среди затронутых есть версии начиная с PHP 5.4. Это не значит, что один и тот же сценарий сработает на любом сайте: цепочка атаки зависит от версии, конфигурации и поведения приложения.

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

Wiz проверила свой сценарий php2shell на WordPress, Drupal и Joomla, используя их актуальные на момент тестирования контейнерные образы. Продемонстрированные атаки не требовали авторизации. CMS здесь служат примерами: уязвимый код находится в PHP, поэтому, как отмечают исследователи, затронутым может оказаться даже простое приложение на уязвимой версии языка.

Отдельно команда показала чтение памяти процесса без выполнения кода. Там могут находиться пароли, токены и API-ключи, включая данные вне запроса атакующего. Поэтому оценивать риск только по возможности выполнения кода на сервере нельзя.

Почему цепочки атак стали практическими

Ошибки оставались в кодовой базе более десяти лет. Чтобы получить работающий сценарий, исследователям пришлось соединить несколько сбоев и учесть, как PHP выделяет и повторно использует память. Другая версия, настройка или поведение приложения могли нарушить цепочку и потребовать новой проверки.

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

До публикации команда сотрудничала с разработчиками PHP и другими участниками, чтобы проверить исправление и подготовить защитные меры. В материале подробно разобраны четыре случая эксплуатации в рамках двух CVE; исследователи также упоминают другие варианты ошибок. По их оценке, обновление PHP устраняет общую причину этих проблем в исправленном выпуске.

Что проверить владельцам сайтов и разработчикам

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

Если обновиться сразу невозможно, стоит обратить внимание на необычные multipart-запросы, за которыми следуют ошибки нехватки памяти или повторяющиеся ответы HTTP 500. Ещё возможные сигналы — неожиданно большие либо некорректные cookies PHPSESSID и необъяснимая смена рабочих процессов PHP. Это ориентиры для расследования, а не замена обновлению: в журналах приложения может остаться мало сведений. Полным устранением проблемы исследователи называют установку исправления PHP.

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

Моё мнение: обновлять нужно основу, а не только сайт

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

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

Источники

Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.

1. PHP2Shell: AI uncovers critical RCE in PHP www.wiz.io

Об авторе

Бекжан Халелов

начинающий backend-разработчик

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

Все публикации автора