PHP2Shell: чему разработчики на PHP могут научиться на примере критического уязвимого открытия

PHP уже несколько десятилетий обеспечивает работу веб-приложений. От WordPress и Drupal до приложений на Laravel, корпоративных платформ и API — этот язык остается одним из самых популярных языков программирования для серверной стороны.

Но октябрь 2026 года преподнес экосистеме PHP важное напоминание:

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

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

Уязвимости получили название PHP2Shell и следующие идентификаторы:

• CVE-2026–109618
• CVE-2026–109619

Обе уязвимости получили оценку критичности 9.2 по шкале CVSS v4.0.

Что делает этот инцидент особенно интересным, так это то, что уязвимости были вызваны не плохо написанным контроллером Laravel, небезопасным эндпоинтом API или устаревшим пакетом Composer.

Их корни лежали во внутренней системе управления памятью и жизненным циклом запросов PHP.

Давайте разберем, что произошло, почему это произошло и какие выводы мы можем из этого сделать как PHP-разработчики.

1. Что на самом деле произошло?

Специалисты по безопасности из Wiz Research обнаружили две критические уязвимости в основном движке PHP.

Эти уязвимости могли позволить злоумышленникам выполнять произвольный код на затронутых серверах без аутентификации.

Это вызывает особую тревогу, поскольку PHP — это не просто фреймворк для приложений. Это базовая среда выполнения, отвечающая за обработку HTTP-запросов, управление памятью, работу с сессиями и выполнение кода приложения.

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

Команда PHP выпустила обновления безопасности для следующих веток:

PHP branchFixed versionPHP 8.58.5.12PHP 8.48.4.27PHP 8.38.3.36PHP 8.28.2.35

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

Важное отличие заключается в том, что эти уязвимости существуют ниже уровня приложений.

Ваше приложение может следовать лучшим практикам, валидировать каждый запрос, использовать подготовленные SQL-запросы и реализовывать надежную аутентификацию. Это не защищает его автоматически от уязвимости в среде выполнения PHP.

Источник: Официальное объявление безопасности PHP.

2. Понимание первопричины

Чтобы понять эти уязвимости, нам нужно выйти за рамки повседневной разработки на PHP.

Большинство разработчиков на PHP работают с объектами, массивами, функциями, классами и фреймворками. Однако сам PHP написан на C.

Движок PHP управляет памятью, инициализирует внутренние структуры, обрабатывает запросы и освобождает ресурсы.

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

Давайте рассмотрим их по отдельности.

3. CVE-2026–109618: Удаленное выполнение кода из-за повреждения памяти при её нехватке (Out-of-Memory)

Первопричина: Некорректная обработка частично инициализированных данных внутренних запросов при исчерпании памяти.

В PHP есть директива конфигурации:

memory_limit 

Например:

memory_limit = 128M

Это ограничивает объем памяти, который может потреблять PHP-скрипт.

Представьте себе приложение, получающее большой составной HTTP-запрос (multipart), содержащий загружаемые файлы и поля формы.

В процессе обработки запроса PHP выделяет память и инициализирует внутренние структуры данных для хранения информации о входящем запросе.

Теперь представьте, что происходит, когда PHP достигает заданного лимита памяти во время обработки такого запроса.

Движок может прервать выполнение с помощью своего механизма обработки нехватки памяти.

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

Когда впоследствии PHP выполнял очистку, он мог ошибочно принять неполные внутренние данные за действительные.

Это создавало возможность для повреждения памяти.

Почему это опасно?

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

Область памяти может содержать непредвиденные данные, потенциально оставшиеся от предыдущих выделений.

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

Потенциально это может стать путем к выполнению произвольного кода.

Фундаментальная инженерная проблема

Важная проблема заключается вовсе не в том, что в PHP закончилась память.

Приложения должны уметь безопасно обрабатывать исчерпание памяти.

Более глубокая проблема заключалась во взаимодействии между:

• Выделением памяти.
• Частичной инициализацией внутренних структур.
• Исключительным управлением потоком выполнения.
• Очисткой ресурсов.

Это классическая проблема безопасности памяти.

4. CVE-2026–109619: Удаленное выполнение кода через устаревшее глобальное состояние

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

Эта уязвимость затрагивает другую важную концепцию системного программирования: время жизни объектов и владение памятью.

PHP обрабатывает запросы, используя внутренние структуры среды выполнения.

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

Представьте себе следующую последовательность:

1. Воркер начинает обработку Запроса А.
2. PHP создает состояние, связанное с внутренним запросом.
3. Возникает исключительная ситуация, например фатальная ошибка.
4. Память, связанная с частью этого запроса, освобождается.
5. Некоторое внутреннее состояние все еще сохраняет ссылку на эту освобожденную память.
6. Тот же воркер получает Запрос Б.
7. До того, как нормальная инициализация все сбросит, можно получить доступ к устаревшему состоянию.

Это создает проблему безопасности памяти типа use-after-free.

Что такое уязвимость типа use-after-free?

Рассмотрим упрощенный пример на C:

int *data = malloc(sizeof(int));
*data = 100;
free(data);

// Dangerous: accessing released memory
printf("%d", *data);

После вызова free()  программа больше не должна использовать эту память через старый указатель.

Однако указатель все еще существует.

Теперь он ссылается на память, которой программа больше не владеет.

Впоследствии эта память может быть повторно использована для чего-то другого.

Это известная уязвимость типа use-after-free.

В PHP2Shell проблема была сложнее, чем в этом упрощенном примере. Она включала в себя внутреннее состояние запроса PHP, которое переживало время жизни своей опорной памяти.

Самое интересное: исследование уязвимостей с помощью ИИ

Один из самых интересных аспектов PHP2Shell — то, как были обнаружены эти уязвимости.

По данным Wiz Research, лежащие в их основе уязвимости существовали в кодовой базе PHP более десяти лет.

Поиск проблемного кода был лишь частью задачи.

Исследователям также нужно было понять, как выделяется память, как повторно используются внутренние структуры и как можно объединить несколько слабых мест в работающий эксплойт.

Это потребовало значительных исследований и экспериментов.

Исследования с помощью ИИ помогли снизить эту сложность.

В Wiz сообщили об использовании нескольких систем искусственного интеллекта, включая Gemini 4 Argon и GPT-5.6 Sol, наряду с собственными исследовательскими инструментами.

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

Это особенно интересно с точки зрения разработки программного обеспечения.

В течение многих лет дискуссии об ИИ в разработке фокусировались в основном на генерации кода, написании тестов и повышении производительности.

Но это исследование демонстрирует другое важное направление:

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

5. Позитивный пример open-source сотрудничества

Другим важным аспектом этого инцидента стала скоординированная реакция.

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

Исследователи следовали процессу ответственного раскрытия информации (responsible disclosure), позволив команде PHP изучить проблему и подготовить исправления до публичного релиза.

Широкая экосистема также внесла свой вклад, предоставив рекомендации, средства обнаружения и поддержку по минимизации рисков.

В этом заключается одна из сильных сторон зрелых сообществ открытого исходного кода.

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

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

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

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

Безопасность заключается не только в обнаружении уязвимостей.

Она также зависит от того, насколько эффективно сообщество реагирует на них. 6. Что делать разработчикам PHP и инженерным командам?

Первоочередная задача — обновить затронутые инсталляции PHP.

Команда безопасности PHP рекомендует обновиться до патченных версий:

PHP 8.5.12+
PHP 8.4.27+
PHP 8.3.36+
PHP 8.2.35+

Проверьте фактический рантайм PHP, используемый вашим веб-сервером, а не только версию CLI:

php -v

Для развертываний с использованием PHP-FPM также проверьте службу PHP-FPM и версию установленного пакета.

Для приложений на базе Docker проверьте образ PHP:

FROM php:8.4.27-fpm

Пересоберите и повторно разверните образ после обновления.

Помните, что изменение только одного Dockerfile не обновляет уже запущенные контейнеры.

Дополнительные проверки безопасности

1. Проверьте конфигурацию памяти

Проверьте:

memory_limit
post_max_size
upload_max_filesize

Бюллетень безопасности PHP рекомендует внести конкретные временные изменения в конфигурацию, чтобы снизить подверженность атакам, связанным с повреждением памяти (memory-corruption).

Это дополнительные меры, а не замена патчам.

2. Проверьте прогресс загрузки сессий

Бюллетень PHP также рекомендует:

session.upload_progress.enabled = 0

Это помогает заблокировать подтвержденные векторы атак, связанные с устаревшим внутренним состоянием.

Примените это на уровне конфигурации сервера или PHP-FPM и перезапустите воркеры.

3. Проверьте политику поддержки версий PHP

Срок поддержки PHP 8.2 истекает 31 декабря 2026 года.

Командам, все еще использующим PHP 8.1 или более старые версии, следует уделить особое внимание схемам поддержки и спланировать обновление.

4. Проверьте свою инфраструктуру

Не думайте, что обновление зависимостей приложения обновляет сам PHP.

Забытый контейнер или стейджинг-сервер могут оставаться уязвимыми даже после обновления основного приложения.

6. Интересный аспект: как ИИ изменил исследования уязвимостей

Один из особенно интересных аспектов этого инцидента — то, как уязвимости были обнаружены и исследованы.

По данным Wiz Research, лежащие в их основе слабые места существовали в PHP более десяти лет.

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

Это важное событие для индустрии разработки программного обеспечения.

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

Он может помочь исследователям:

• Анализировать большие кодовые базы.
• Выявлять подозрительные паттерны управления памятью.
• Трассировать сложные пути выполнения.
• Понимать взаимодействия между внутренними компонентами.
• Исследовать потенциальные условия для эксплойтов.
• Разрабатывать и проверять PoC-эксплойты (proof-of-concept).

Однако у этого развития есть и обратная сторона.

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

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

Заключение

PHP2Shell — важное открытие в области безопасности, но я считаю, что главная новость здесь касается инженерного прогресса.

Уязвимость, существовавшая в кодовой базе PHP много лет, была исследована, продемонстрирована, ответственно раскрыта и устранена посредством скоординированных релизов безопасности.

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

Для разработчиков на PHP урок заключается не в том, чтобы терять веру в язык или экосистему.

Он в том, чтобы лучше разбираться в системах, на которых мы строим.

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

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

И именно это делает зрелую экосистему ПО сильнее со временем.