Критическая уязвимость в PHP: что случилось в октябре 2026 и что делать

21 октября 2026 года вышли PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Это не плановое обновление: релиз закрывает две уязвимости, через которые можно выполнить свой код на сервере без логина и пароля. Оценка обеих — CVSS v4.0 9.2 из 10. Ниже — что именно сломано, кого это касается и что делать, если обновиться прямо сейчас нельзя.

Почему это не «ещё одна дырка в плагине»

Обычные истории про взломы сайтов выглядят так: в плагине нашли ошибку, вышло обновление, надо нажать «Обновить». Здесь другой уровень. Ошибка в самом PHP — то есть в языке, который выполняет код сайта. Ни обновление WordPress, ни свежий плагин, ни тема, ни установленный WAF сами по себе её не закрывают: уязвимость находится ниже приложения.

Уязвимы все установки, которые принимают веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP, LiteSpeed. Команда PHP отдельно отмечает mod_php: для него показан рабочий сценарий, где неаутентифицированный запрос срабатывает до того, как начнёт выполняться код приложения. То есть проверки входа, правила CMS и код сайта в этот момент ещё не участвуют.

Что именно сломано

CVE-2026-109618: обрыв по памяти

У PHP есть лимит памяти на запрос (memory_limit). Когда лимит исчерпан, движок обязан аккуратно прибрать за собой: освободить структуры запроса и завершиться. В этой уборке и нашлась ошибка — она может выполняться, когда внутренние данные запроса инициализированы лишь частично. Дальше очистка принимает невалидные данные за валидные, и то, что должно было быть безобидным завершением, превращается в выполнение чужого кода.

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

CVE-2026-109619: чужие данные в следующем запросе

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

Это классическая ошибка работы с памятью, но последствия те же — выполнение кода. И тоже без авторизации: атакует не «пользователь», а сам HTTP-запрос.

Кого это касается

• Хостинг и серверы. Любой сайт на PHP: WordPress, Bitrix, Laravel, самописная админка, внутренний портал.
• Офисные системы. Тикетницы, CRM, системы документооборота — всё, что открыто хотя бы во внутреннюю сеть.
• Не касается только статики: если PHP на сервере не выполняется вообще, уязвимости нет.

На shared-хостинге версию PHP обычно выбирает владелец сайта в панели, а патчи ставит хостер. Поэтому первое, что нужно сделать, — посмотреть, какая версия стоит у вас, а не у соседа.

Как проверить версию

• Панель хостинга (ISPmanager, cPanel, Plesk): раздел с PHP — там версия указывается для каждого сайта отдельно.
• WordPress: «Инструменты» → «Здоровье сайта» → «Сведения» → «Сервер». Показывается версия, которую использует веб-сервер.
• Сервер: php -v в консоли. Важно: версия в консоли и версия под веб-сервером могут отличаться.

Исправленные версии:

Как обновить

Сервер на Linux

1. Обновите пакеты из репозитория дистрибутива или вендора (например, deb.sury.org для Debian и Ubuntu или Remi для RHEL-совместимых).
2. Проверьте, что обновились и CLI, и FPM: php -v и версия в пуле.
3. Перезапустите PHP-FPM и сбросьте OPcache. Без перезапуска старый код продолжит работать из кэша.
4. Проверьте расширения (php -m) и сайт: формы, загрузку файлов, отправку почты, обработку изображений.

Хостинг с панелью

Переключите версию PHP для сайта в панели. Если в списке нет исправленной сборки — напишите в поддержку и укажите номера CVE-2026-109618 и CVE-2026-109619: так вопрос не потеряется в общих формулировках. Перед переключением сделайте бэкап: старые плагины иногда несовместимы с новой веткой.

Docker и контейнеры

Обновите тег базового образа и пересоберите контейнер. Просто docker pull без пересборки не поможет, если версия зафиксирована в вашем Dockerfile.

Windows

26 октября вышли пересобранные пакеты: 8.5.12-1, 8.4.27-1, 8.3.36-1 и 8.2.35-1. Суффикс «-1» означает пересборку с Brotli 1.2.1 — она закрывает CVE-2026-111497, запись за границы буфера при распаковке. В сборках PHP этот декодер доступен через cURL, если включена автоматическая распаковка ответа (по умолчанию в cURL она выключена).

Если обновиться нельзя сегодня

Сразу оговорюсь: команда PHP пишет прямо — полного обхода нет, обновление остаётся единственным полным решением. Всё, что ниже, снижает риск конкретных путей атаки, но не делает сервер безопасным. Это режим «до вечера», а не образ жизни.

Против CVE-2026-109618:

• memory_limit=-1, причём так, чтобы приложение не могло переопределить: через php_admin_value в пуле FPM или в конфигурации Apache. Проверьте, что нигде ниже не выставлен конечный лимит.
• Низкий post_max_size: 8M, если загрузка файлов не нужна, 32M, если нужна. upload_max_filesize — меньше.
• Лимиты на уровне веб-сервера или прокси: размер запроса, число полей, частей multipart, заголовков, глубина вложенности. Важно, чтобы они работали и для запросов без корректного Content-Length.
• Лимит памяти контейнера или cgroup как граница доступности. Не заменяйте его на RLIMIT_AS или RLIMIT_DATA — они сами могут вызвать сбой нужной аллокации.

Против CVE-2026-109619:

• session.upload_progress.enabled=0 и перезапуск всех рабочих процессов. Настройка должна применяться до разбора запроса: php.ini, пул FPM или конфигурация сервера — но не ini_set() и не .user.ini.
• На PHP 8.5 — fatal_error_backtraces=0, тоже с перезапуском процессов.
• Уберите невалидные и устаревшие настройки, которые применяются на каждый запрос и пишут диагностику до инициализации. Скрыть её через error_reporting, display_errors или «@» не получится.
• Почините фатальные ошибки и таймауты, до которых может дотянуться атакующий: колбэки, обработка загрузок и импорта, очистка.

Отдельно про session.upload_progress: 23 октября команда PHP выпустила уточнение. Проблема проявляется только в редкой комбинации — приложение меняет session.serialize_handler на php через ini_set() перед session_start(), а прогресс загрузки включён. Полный advisory обещают вместе со следующим релизом (CVE-2026-115560). Если вы уже отключили настройку 21 октября — оставьте как есть.

«У меня 8.1, и всё работает»

Это и есть главная проблема. PHP 8.1 не получает обновлений от проекта с конца 2025 года. Для 7.4, 8.0 и 8.1 команда PHP выложила минимальные патчи в исходниках — для тех, кто собирает PHP сам. Если сервер обслуживает дистрибутив или LTS-вендор, патч может прийти от него. Проверить просто: спросите хостера, закрыты ли CVE-2026-109618 и CVE-2026-109619 на вашей версии и когда будет обновление. Ответ «у нас всё обновлено» без номеров версий — не ответ.

Следующий на очереди — PHP 8.2: он уходит с поддержки 31 декабря 2026 года. Если планируете обновление, планируйте сразу переход на 8.3 или 8.4, а не на 8.2.

Что сделать в компании: короткий план

1. Составьте список: где вообще выполняется PHP — сайты, CRM, внутренние порталы, старые серверы «на всякий случай».
2. По каждому пункту зафиксируйте версию и статус патча. Таблица на десять строк полезнее переписки в мессенджере.
3. Обновляйте начиная с того, что смотрит в интернет. Внутренние системы — сразу после.
4. Там, где обновление задерживается, включите временные меры из раздела выше и запишите, кто и когда их снимет.
5. После обновления проверьте сайт и логи, убедитесь, что перезапущены FPM и OPcache.
6. Назначьте ответственного и дату следующей проверки. «Как-нибудь потом» здесь не работает: следующие критические релизы PHP выйдут снова.

Что сделал я

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

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

Если разбираться с версиями, пулами и расширениями нет времени — обслуживаю IT-инфраструктуру организаций в Минске, включая обновления и проверку безопасности. Частным пользователям — компьютерная помощь. Короткие заметки по администрированию публикую в Telegram-канале.

Источники: новости php.net, advisories GHSA-w8hw-w9fx-j79w и GHSA-6wmf-4rv5-p3rp.