PHP выпустил четыре обновления для устранения двух критических уязвимостей
PHP выпустил четыре обновления для устранения двух критических уязвимостей: при определённых условиях атакующий мог выполнить код на сервере. Владельцам сайтов и разработчикам рекомендуется обновить PHP.
21 октября проект PHP выпустил версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35 с исправлениями двух критических уязвимостей. При определённых условиях атакующий без авторизации мог выполнить код на сервере. Как пишет PHP Foundation, пользователям PHP нужно обновиться; технические детали и инструкции для разных систем опубликованы в объявлении проекта на php.net.
Как работают две уязвимости
CVE-2026-109618 связана с нехваткой памяти. Если запрос достигает ограничения memory_limit в определённый момент, PHP может оставить внутренние данные частично инициализированными и позже принять их за корректные. Это повреждает память. На Apache с mod_php исследователи показали удалённое выполнение кода через запрос без авторизации при настройках по умолчанию — ещё до запуска кода приложения. Для PHP-FPM выполнение кода подтвердили через пути, зависящие от приложения.
При CVE-2026-109619 фатальная ошибка может оставить во внутреннем состоянии указатель на память предыдущего запроса. Следующий запрос в том же рабочем процессе способен обратиться к уже освобождённой памяти. Были подтверждены такая ошибка и аварийное завершение процесса; исследователь также показал выполнение кода на реальном приложении под Apache с mod_php.
Обе проблемы находятся в механизмах, которые задействованы почти в каждом запросе: управлении памятью и обработке ошибок. При подготовке исправлений команде приходилось учитывать совместимость, производительность и сторонние расширения. При этом подтверждённые сценарии атаки различаются для mod_php и PHP-FPM.
Почему исправление заняло время
Первые признаки проблемы с нехваткой памяти разработчик ядра обнаружил при устранении находки внешнего аудита 2024 года. Возможность эксплуатации тогда предполагали, но конкретного пути к выполнению кода не нашли. Варианты исправления грозили нарушить совместимость, создать риск отказа в обслуживании либо потребовать изменений во множестве расширений. Работа останавливалась и возобновлялась месяцами. Foundation связывает задержку и с порядком принятия решений в команде безопасности, и с нехваткой специалистов, знающих движок PHP.
11 августа 2026 года Calif сообщила об удалённом выполнении кода с тем же корнем проблемы; независимо от неё в тот же день о нём сообщила OpenAI. Позже поступили дополнительные способы атаки от Wiz и OpenAI. После этих сообщений исправление стало главным приоритетом специалистов Foundation по безопасности. Патч подготовили для всех поддерживаемых веток.
Организация меняет и сам процесс. В мае 2026 года она создала Ecosystem Security Team для разбора сообщений, координации и работы над защищённостью PHP. Инструменты помогают проверять находки и сопоставлять сообщения с общей причиной, но решения по ним и исправления остаются за людьми. С 1 июля команда опубликовала 15 CVE и обработала более 100 сообщений, оказавшихся ошибочными, повторными или невоспроизводимыми.
Срок выпуска пришлось сдвинуть: 20 октября номера CVE появились в сети без технических деталей, но с неверной оценкой 10,0 вместо фактических 9,2. Обновления перенесли с 22 на 21 октября. Выпустить их немедленно не могли: дистрибуторы ещё готовили пакеты. До согласованного срока также появились видео с демонстрацией атаки и образы с исправлением от Chainguard. На момент публичного выпуска команда безопасности PHP не обнаружила работающих эксплойтов среди изученных ею образцов.
Что проверить тем, кто использует PHP
Владельцу сайта и разработчику прежде всего нужно выяснить текущую версию PHP и проверить доступность обновления до 8.5.12, 8.4.27, 8.3.36 или 8.2.35 для своей ветки. Foundation призывает обновляться и направляет за инструкциями для конкретных систем к объявлению PHP. Её обзор посвящён причинам и истории исправления, а не порядку установки.
Нельзя сводить проверку к одному способу эксплуатации. Для mod_php показан сценарий до запуска кода приложения, а для PHP-FPM выполнение кода подтвердили через пути в приложении. Если средой управляет подрядчик или хостинг-провайдер, я бы уточнил у него версию PHP и статус обновления. О самих исправлениях в ядре также рассказано в отдельной новости блога.
Моё мнение
Для меня главный вывод — риск нельзя оценивать только по коду сайта. В одном из подтверждённых сценариев запрос вызывает проблему до того, как этот код начнёт работать. Поэтому я бы сначала проверил версию среды, а затем разбирался, какие условия атаки относятся к конкретной конфигурации.
Foundation прямо описывает, почему исправление задержалось: у каждого варианта были последствия, а специалистов для выбора и проверки не хватало. На мой взгляд, эта часть истории не менее полезна, чем сообщение о патче. Поиск ошибки и выпуск надёжного исправления — разные задачи; для второй нужны люди, которые знают устройство PHP и могут оценить последствия изменений.
Источники
Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.
- PHP Foundation's Overview of CVE-2026-109618 and CVE-2026-109619 thephp.foundation
начинающий fullstack-разработчик
Делаю учебный сервис бронирования и разбираюсь, как связать клиентскую часть с API. В ответах стараюсь описывать не только что выбрал, но и почему.
Все публикации автораПохожие статьи
В ядре PHP исправили уязвимости, позволяющие удалённо выполнить код
В ядре PHP исправили уязвимости, которые могли привести к удалённому выполнению кода и чтению памяти процесса. Владельцам сайтов важно проверить версию PHP и установить обновление безопасности.
Опубликованы детали предполагаемой уязвимости в обработке загрузок PHP
Автор публикации описал предполагаемую уязвимость PHP, связанную с обработкой загрузок файлов. Официального подтверждения проблемы и исправления пока нет.
Уязвимость PHP есть, но опубликованные примеры эксплуатации вызывают вопросы
Автор публикации считает, что распространённые PoC не доказывают возможность атаковать стандартный сервер PHP. При этом уязвимость реальна, и затронутые серверы нужно исправить.
Обсуждение 5
Петро Климчук
У нас на одном проекте PHP-FPM долго оставался на старой версии из-за образа в CI: после таких обновлений проверяю не только прод, но и базовый образ, иначе уязвимая версия возвращается при следующем деплое
Рамин Алиев
Уязвимость исправили, а CI уже приготовил её камбэк в следующем деплое — автоматизация, как всегда, заботится о нас. После обновления образа ещё и поддержку этой версии кто-нибудь проверит, или это уже задача следующего инцидента?
Винсент Лаан
@ramin.api Проверять нужно и базовый образ, и поддержку ветки: патч на сервере не поможет, если CI вернёт старый PHP при деплое.
Турал Латып
@petro_klym, вы проверяете версию PHP в самом образе после его пересборки? Иначе старый базовый образ может снова попасть в CI.
Азамат Токтосунов Автор публикации
После пересборки стоит прогнать проверку версии именно внутри итогового образа, например на этапе CI перед публикацией. Иначе можно обновить базовый образ, но по ошибке собрать деплой из старого тега; для этих исправлений важно убедиться, что в образ попала нужная ветка PHP, а не только что пакет обновлён в репозитории.