Сегодня, 21 октября 2026 года, разработчики PHP выпустили экстренные исправления двух критических уязвимостей — CVE-2026-109618 и CVE-2026-109619, известных как PHP2Shell. Пока администраторы готовили обновления, часть компаний временно отключала веб-сервисы: риск удалённого выполнения кода оказался серьёзнее последствий технического перерыва.

Что случилось с PHP

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

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

Для Apache с mod_php показаны атаки ещё до запуска кода приложения. PHP-FPM также требует обновления: для второй ошибки подтверждён путь, зависящий от поведения приложения. Наличие Nginx перед PHP или актуального WordPress само по себе не закрывает эти уязвимости.

Почему сайты ставили на паузу

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

Какие версии исправлены

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

Как проверить, что обновлён именно сайт

• php -v показывает версию командной строки. Сайт может работать через другую ветку или отдельный контейнер.
• В WordPress фактическую версию можно посмотреть в разделе «Инструменты → Здоровье сайта → Информация → Сервер».
• После установки пакетов нужно перезапустить соответствующие PHP-FPM-процессы или другой обработчик PHP и проверить версию повторно. Обновление WordPress и плагинов не заменяет патч интерпретатора.

Что дают временные меры

Если обновление задерживается, команда PHP предлагает меры снижения риска. Для подтверждённых путей второй уязвимости в php.ini можно задать:

; Временные меры в php.ini
session.upload_progress.enabled = 0; Дополнительно только для PHP 8.5
fatal_error_backtraces = 0

После этого требуется перезапустить все PHP-воркеры. Для upload_progress нельзя рассчитывать на ini_set() или FPM .user.ini: настройка должна действовать до разбора запроса. Включённый механизм может задействовать обработку сессии даже без вызова session_start() в приложении.

Размер запросов тоже стоит ограничить: ориентир из рекомендаций PHP — post_max_size = 8M без загрузки файлов или 32M, если она нужна; upload_max_filesize должен быть меньше. Но ни эти лимиты, ни отключение upload_progress не закрывают все варианты атак. Полное исправление — установка патча.