**PHP2Shell: две критические RCE в ядре PHP, патчи уже вышли**
**PHP2Shell: две критические RCE в ядре PHP, патчи уже вышли** 20–21 октября 2026 года PHP Foundation выпустила внеплановое обновление, закрывающее две критические уязвимости в ядре PHP. Обе — unauthenticated RCE с CVSS 9.2. Эксплуатацию уже фиксируют в дикой природе, а патч пришлось выкатить на день раньше из-за утечки. Уязвимости получили общее имя PHP2Shell: CVE-2026-109618 и CVE-2026-109619. Формально это две разные ошибки, но обе бьют по жизненному циклу запроса в PHP. Первая, CVE-2026-109618, — «RCE via OOM corruption». PHP использует `longjmp()` (аварийный выход из контекста в C) при out-of-memory. В момент, когда память запроса ещё не полностью инициализирована, неудачное выделение может оставить её в невалидном состоянии. Дальше shutdown-процедура читает или ветвится по этим данным. Через multipart-парсинг можно организовать OOM, оставаясь в пределах `post_max_size` и `memory_limit`: запрос без внятного `Content-Length`, неограниченное число заголовков, пустые file-контролы, вложенные имена полей. На Apache с `mod_php` это срабатывает до любого кода приложения — отсюда и максимальный риск. Вторая, CVE-2026-109619, — «RCE via stale global state». Воркер хранит глобальное состояние (error, session, object, extension), которое указывает на память, принадлежащую конкретному запросу. Если запрос завершается фатальной ошибкой или предупреждением, состояние может пережить освобождение памяти. Следующий запрос на том же воркере успевает прочитать stale-указатель до нормальной инициализации. Это классический use-after-free (UAF — обращение к уже освобождённой памяти). Подтверждённые пути — `mod_php` на PHP 8.5 с `fatal_error_backtraces` и механизм `session.upload_progress`, который включён по умолчанию. Для FPM эксплуатация зависит от приложения, но source analysis считает его уязвимым. Затронуты все PHP-установки, обслуживающие веб-запросы: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed. По данным Wiz, дыры тянутся с PHP 5.4; watchTowr говорит про PHP 5 и новее. Официальные бинарные патчи есть для 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Для 7.4, 8.0 и 8.1 PHP Security Team выложила минимальные source-backport'ы, но это именно «собери сам», а не готовые пакеты. Для PHP 8.1 и старше поддержки upstream уже нет. Эксплуатация началась быстро. Утечка деталей произошла 20 октября, патч изначально планировали на 22-е, но перенесли на 21-е. watchTowr зафиксировал атаки в своей honeypot-сети, Cloudflare сообщала о тысячах попыток до анонса и миллионах после. CISA добавила уязвимости в KEV и требует немедленного патча; NSA и FBI также выпустили предупреждения. Практический чек-лист выглядит так: ```bash php -v php -i | grep -E 'memory_limit|post_max_size|session.upload_progress.enabled|fatal_error_backtraces' ``` Если версия ниже 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 — вы в зоне риска. Обновление — единственное полное решение. Если патч прямо сейчас невозможен, официальные временные меры такие: ```ini ; это не замена патчу, а снижение поверхности атаки memory_limit = -1 post_max_size = 8M session.upload_progress.enabled = 0 ; только для PHP 8.5 fatal_error_backtraces = 0 ``` `memory_limit=-1` лучше выставлять через `php_admin_value` в FPM-пуле или конфиге Apache, чтобы приложение не вернуло конечный лимит обратно. И не заменяйте это на `RLIMIT_AS`/`RLIMIT_DATA` — они сами могут привести к тому самому allocation failure. После смены `session.upload_progress` нужно перезапустить всех воркеров. И помните: эти меры закрывают лишь подтверждённые пути, а не уязвимость целиком. Если хост был доступен из интернета и не пропатчен — стоит проверить логи на компрометацию и, при подозрениях, ротировать креды, которые видел веб-сервер: доступы к БД, API-ключи, секреты в конфигах. 🛠 Мнение DevGeek.IT: Обновляйтесь. Это не тот случай, где можно «подождать до пятницы»: дыра в ядре, срабатывает до кода приложения, без авторизации, с подтверждённым RCE. История с утечкой и переносом патча на день раньше —