# PHP выпустила срочные патчи для двух критических уязвимостей PHP2Shell

> Источник: 404 Media. Канонический URL: https://404-media.ru/tehnologii/php-vypustila-srochnye-patchi-dlya-dvuh-kriticheskih-uyazvimostey-php2shell

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

- Рубрика: Технологии (https://404-media.ru/tehnologii)
- Опубликовано: 2026-10-21T19:54:18+03:00
- HTML: https://404-media.ru/tehnologii/php-vypustila-srochnye-patchi-dlya-dvuh-kriticheskih-uyazvimostey-php2shell
- Markdown: https://404-media.ru/tehnologii/php-vypustila-srochnye-patchi-dlya-dvuh-kriticheskih-uyazvimostey-php2shell.md
- llms.txt: https://404-media.ru/llms.txt

![PHP выпустила срочные патчи для двух критических уязвимостей PHP2Shell](https://storage.yandexcloud.net/404-media/media/2026/10/4OYY78IPhQU3LPTrXsQ7yfgyvyZnYmUKyPN6AywX.png)

21 октября команда PHP выпустила внеочередные обновления для двух критических уязвимостей в ядре языка. Проблемам присвоены идентификаторы CVE-2026-109618 и CVE-2026-109619, а их серьёзность оценена в 9,2 балла из 10. Исследователи назвали цепочку атак PHP2Shell: она позволяет удалённо выполнить код на сервере без учётной записи и без наличия ошибки в самом веб-приложении.

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

## Как работают уязвимости

CVE-2026-109618 возникает при исчерпании **memory_limit** во время разбора входящих данных. Интерпретатор выходит из текущего контекста с помощью **longjmp()**, оставляя некоторые структуры недоинициализированными. На этапе завершения запроса эти данные могут быть ошибочно приняты за действующие, а часть содержимого контролируется атакующим.

Вторая проблема, CVE-2026-109619, связана с использованием памяти после её освобождения. После фатальной ошибки глобальные структуры воркера могут сохранять указатели на область, которая уже была возвращена системе и затем выделена для другого запроса. Это создаёт условия для межзапросного use-after-free, а также может привести к утечке данных из памяти процесса — включая сессии, токены и ключи.

Для эксплуатации требуется, чтобы запросы попали в один и тот же процесс-воркер, а атакующему пришлось подстроиться под раскладку памяти. Однако это не является полноценной защитой: подбор параметров можно выполнять серией попыток. Уязвимыми считаются серверы, принимающие HTTP-запросы и исполняющие PHP, включая PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. В режиме mod_php атака особенно опасна, поскольку может сработать до запуска кода приложения.

## Масштаб проблемы и первые атаки

Проблема затрагивала все ветки PHP начиная с версии 5.4. Таким образом, за последнее десятилетие не существовало полностью защищённой версии языка. Исследователи Wiz продемонстрировали готовый эксплойт против свежих контейнеров WordPress, Drupal и Joomla, а Sansec сообщила о подтверждённом удалённом выполнении кода в Magento и других приложениях. Само по себе [приложение](/tehnologii) не обязательно должно содержать уязвимость: целью может стать даже минимальная страница на уязвимой версии PHP.

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

Ситуация усугубилась тем, что сведения об уязвимостях появились до официального релиза исправлений. Видео с демонстрацией атаки распространилось по сети, а Cloudflare и watchTowr зафиксировали первые попытки эксплуатации в день публикации патчей.

## Что нужно сделать администраторам

Исправления выпущены для следующих веток: PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Обновить пакеты можно через менеджер дистрибутива либо пересобрав контейнер. Плагины и темы обновлять специально из-за этой проблемы не требуется: уязвимость находится в самом PHP.

- **Установите исправленную версию PHP** в зависимости от используемой ветки.
- **Перезапустите воркеры** PHP-FPM или Apache. Одной установки новых пакетов недостаточно: старое состояние может сохраняться в уже запущенных процессах.
- **Для PHP 8.1 и более старых версий** проверьте наличие бэкпорта от поставщика дистрибутива или подготовьте переход на поддерживаемую ветку. Официальные патчи для этих версий не заявлены.
- **До обновления ограничьте внешний доступ** к серверу, если он доступен из интернета. Дополнительно можно отключить параметр **session.upload_progress.enabled=0**, который связан с одним из подтверждённых векторов атаки.
- **Проверьте журналы** после обновления: ищите ошибки memory_limit при multipart-запросах, необычно большие значения PHPSESSID и необъяснимые падения воркеров.

Правила для WAF уже выпускали Cloudflare и Akamai, однако они могут лишь выиграть время. По оценке команды PHP, единственным надёжным способом закрыть проблему остаётся установка исправлений и перезапуск процессов, обслуживающих запросы.