~/ / Статьи об ИИ / ИИ помог найти PHP2Shell: критические уязвимости PHP октября 2026 года

ИИ помог найти PHP2Shell: критические уязвимости PHP октября 2026 года

По сообщениям прессы, модели ИИ помогли исследователям найти две критические уязвимости в самом PHP, CVE-2026-109618 и CVE-2026-109619, которые могут позволить удалённое выполнение кода без аутентификации. Разработчики PHP выпустили исправленные версии 21 октября 2026 года. В этой статье кратко изложено, что говорят об этих уязвимостях и о роли ИИ официальные объявления и сообщения прессы, а также можно проверить, есть ли исправление в используемом вами PHP.

Сверено с официальными объявлениями 2026-10-24. Эта страница не является официальным бюллетенем, а подробности могут меняться, поэтому следите за источниками внизу страницы.

Что сделать в первую очередь

Обновите PHP до исправленного выпуска (8.5.12, 8.4.27, 8.3.36 или 8.2.35) либо до исправленного пакета вашего дистрибутива Linux. PHP сообщает, что полных способов смягчения нет и единственный безопасный выбор — обновление.
После обновления перезапустите PHP-FPM, Apache и все долгоживущие рабочие процессы PHP, чтобы они загрузили исправленный код. Служба, запущенная до обновления, по-прежнему выполняет старый код.
Если PHP установлен из пакета дистрибутива, проверьте полную версию пакета, включая часть после первого дефиса. Дистрибутивы могут включать исправление, не меняя первую часть номера.
Если обновиться сразу нельзя, см. меры смягчения ниже. PHP сообщает, что они снижают подверженность отдельным путям атаки, но не делают установку безопасной.

Что произошло

21 октября 2026 г. PHP выпустил версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Они исправляют две критические уязвимости, обе с оценкой CVSS v4.0 9.2.

CVE-2026-109618, названная RCE via OOM corruption: обработка нехватки памяти может прервать PHP в момент, когда внутренние данные запроса инициализированы лишь частично, и очистка запроса может затем счесть некорректные данные корректными.

CVE-2026-109619, названная RCE via stale global state: принадлежащее запросу внутреннее состояние может сохраниться после освобождения памяти, на которой оно размещалось, а более поздний запрос, обработанный тем же рабочим процессом, может использовать это устаревшее состояние.

CVE-2026-109618 · CVSS 4.0 9.2
CVE-2026-109619 · CVSS 4.0 9.2

Как был задействован ИИ

По данным The Next Web, компания по безопасности Calif нашла первую ошибку в августе с помощью модели OpenAI во время аудита исходного кода PHP, который финансировала OpenAI. Wiz сообщила, что нашла эти недостатки независимо, на несколько недель позже, с помощью инструментов ИИ, включая модели Gemini от Google.

Сайт php2shell.com указывает авторами исследования Wiz Research, OpenAI Codex Security и Calif. Calif сообщила, что использовала общедоступные модели и что знание истории PHP значило больше, чем сама модель.

В той же статье сообщается, что Cloudflare включила правила WAF для своих клиентов примерно за девять часов до раскрытия информации, а затем в сети распространился эксплойт-прототип (proof-of-concept). Сайт php2shell.com сообщает, что правило WAF или CDN не следует считать заменой обновления PHP.

Хронология

2026-10-20PHP объявляет о предстоящем критическом выпуске с исправлениями безопасности, запланированном на 21 октября в 14:00 UTC.
2026-10-21Выходят PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35 вместе с бюллетенем безопасности, а Ubuntu публикует USN-8948-1.
2026-10-23PHP публикует информационный бюллетень о session.upload_progress.enabled — о ещё одном маловероятном векторе, отслеживаемом как CVE-2026-115560.

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

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

В бюллетенях GitHub затронутыми названы версии ниже 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Сайт php2shell.com, который, как указано, ведёт Wiz, сообщает, что затронутые выпуски восходят к PHP 5.4.

PHP 8.1 и более старые версии больше не получают обновлений от проекта PHP. Некоторые дистрибутивы и поставщики LTS предоставляют перенесённые исправления, а для тех, кто собирает из исходников, PHP выпустил минимальные переносы исправлений в исходном коде для PHP 7.4, 8.0 и 8.1.

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

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

Собственные выпуски PHP

Ветка	Первый исправленный выпуск
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Пакеты Ubuntu и Debian

Дистрибутив	Пакет	Исправленная версия пакета	Уведомление
Ubuntu 26.10	php8.5	8.5.9-0ubuntu2.1	USN-8948-1
Ubuntu 26.04 LTS	php8.5	8.5.4-0ubuntu1.5	USN-8948-1
Ubuntu 24.04 LTS	php8.3	8.3.6-0ubuntu0.24.04.13	USN-8948-1
Ubuntu 22.04 LTS	php8.1	8.1.2-1ubuntu2.28	USN-8948-1
Debian 12 (bookworm)	php8.2	8.2.35-1~deb12u1	DLA-4848-1
Debian 13 (trixie)	php8.4	8.4.27-1~deb13u1	DSA-6574-1

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

Проверьте свой PHP

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

Команды, показывающие версию

php -v
dpkg -l 'php*' | grep ^ii
apt-cache policy php8.3-fpm | grep Installed

Откуда взят ваш PHP?

Текст с версией

Всё выполняется в вашем браузере. Вставленный текст не загружается на сервер.

Если обновиться сразу нельзя

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

CVE-2026-109618

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

CVE-2026-109619

Задайте session.upload_progress.enabled=0 в php.ini, в пуле FPM или в конфигурации сервера и перезапустите все рабочие процессы. Не полагайтесь на ini_set() или на файл .user.ini для FPM.
В PHP 8.5 задайте fatal_error_backtraces=0 и перезапустите все рабочие процессы.
Уберите недопустимые или устаревшие настройки, применяемые для каждого запроса, которые выводят диагностические сообщения до инициализации. Скрытие диагностики не помогает.
Исправьте фатальные ошибки и тайм-ауты выполнения, до которых может добраться атакующий.

Информационный бюллетень от 23 октября

PHP советует задать session.upload_progress.enabled=0 до следующего планового выпуска с исправлением ошибок, чтобы полностью защититься от маловероятного ещё одного вектора удалённого выполнения кода. Если вы уже применили эту настройку по бюллетеню от 21 октября, оставьте её.

PHP сообщает, что проблема возможна только при необычном сочетании условий: приложение задаёт в конфигурации session.serialize_handler равным php_binary или php_serialize, переключает его на php во время выполнения с помощью ini_set() перед session_start(), а отслеживание прогресса загрузки сессии всё ещё включено. С очередным выпуском PHP опубликует полный бюллетень по CVE-2026-115560.

Чего эта страница не делает

Она не является официальным бюллетенем и не приводит подробностей эксплуатации. Авторитетными являются официальные объявления и бюллетени ниже.
Она не может сказать, подвергалась ли система атаке. Сайт php2shell.com отмечает, что отсутствие подозрительной активности не доказывает, что система не затронута.
Подверженность зависит от версии, конфигурации и конкретной уязвимости. Меры смягчения могут влиять на работу приложения.