21 октября 2026 года PHP выпустила экстренные обновления, устраняющие две критические уязвимости, которые позволяют выполнять код на веб-сервере без авторизации. Исправления вошли в версии PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. По данным команды PHP, только установка обновления обеспечивает полную защиту от этих уязвимостей.
Уязвимости, получившие общее название PHP2Shell, находятся в самом движке PHP, а не в коде приложений. Поэтому под угрозой оказываются сайты даже в том случае, если их собственный код не содержит ошибок. Наибольший риск связан с серверами, использующими Apache mod_php: при успешной эксплуатации уязвимости атака выполняется до запуска кода приложения.
Обе уязвимости получили оценку 9,2 по шкале CVSS 4.0. Им присвоены идентификаторы CVE-2026-109618 и CVE-2026-109619.
PHP опубликовала исправления примерно в запланированное время выпуска, в 14:00 UTC 21 октября. Это произошло на день раньше первоначально намеченного раскрытия информации, запланированного на 22 октября. Причиной стал преждевременный слив сведений об уязвимостях.
Уязвимости обнаружили исследователи Wiz Research, Calif и команда Codex Security компании OpenAI. Они затрагивают практически все версии PHP, начиная с PHP 5.4.
Какие установки PHP подвержены риску
Согласно бюллетеню безопасности PHP, уязвимы все установки PHP, обрабатывающие веб-запросы. Это касается PHP-FPM, Apache mod_php, php-cgi, FrankenPHP и LiteSpeed.
Поскольку ошибки находятся в движке PHP, атаковать можно даже простую страницу с выводом строки "Hello World", если она работает на уязвимой версии PHP.
В бюллетене отдельно отмечен повышенный риск для mod_php. Исследователи продемонстрировали эксплуатацию, при которой один запрос без авторизации запускает атаку до выполнения кода приложения.
PHP-FPM работает иначе: если запрос завершается ошибкой на раннем этапе настройки, процесс-обработчик останавливается. При этом для одной из уязвимостей собственный анализ PHP подтверждает подверженность FPM, хотя полноценную эксплуатацию этого сценария продемонстрировать не удалось. Вторая уязвимость позволяет добиться выполнения кода как при использовании mod_php, так и PHP-FPM. Однако для сценария с FPM требуется выполнение определённой операции внутри работающего приложения.
Помимо выполнения произвольного кода, злоумышленник может читать память процесса PHP-обработчика. В ней могут находиться пароли, токены аутентификации, API-ключи и сертификаты, относящиеся к другим запросам. Для такого доступа предварительно получать возможность выполнять код не требуется.
Исследователи продемонстрировали чтение памяти работающих процессов на приложениях, которыми они не управляли. Это подтвердило, что атака не зависит от конкретного приложения, работающего поверх PHP.
Какие версии необходимо установить
Необходимо обновить среду PHP, которая обрабатывает веб-запросы, а затем перезапустить Apache, PHP-FPM и все долгоживущие PHP-процессы.
Обновление самого приложения, например WordPress или Laravel, не обновляет установленный под ним PHP. Версия среды выполнения определяется пакетами операционной системы, настройками хоста или используемым образом контейнера.
Ветка PHP | Уязвимые версии | Первая исправленная версия |
|---|---|---|
PHP 8.5 | Ниже 8.5.12 | 8.5.12 |
PHP 8.4 | Ниже 8.4.27 | 8.4.27 |
PHP 8.3 | Ниже 8.3.36 | 8.3.36 |
PHP 8.2 | Ниже 8.2.35 | 8.2.35 |
PHP 8.1 и более старые версии больше не получают обновления непосредственно от проекта PHP. Поддержка PHP 8.2 завершится 31 декабря 2026 года.
Для старых веток команда безопасности PHP подготовила исправления исходного кода, которые можно использовать при самостоятельной сборке или ожидании обновлений от поставщика:
Дистрибутивы Linux и поставщики систем с длительной поддержкой получили исправления заранее. Поэтому пакет может содержать исправление, даже если его номер версии выглядит устаревшим. В таких случаях следует проверять журнал изменений пакета на наличие соответствующих CVE, а не ориентироваться только на строку версии. Такой подход рекомендует и Debian.
Что делать, если обновление пока невозможно
Полностью устранить уязвимости можно только обновлением PHP. Перечисленные ниже меры снижают риск отдельных сценариев эксплуатации, но не обеспечивают полной защиты сервера.
Для CVE-2026-109618 рекомендуется установить memory_limit=-1, запретив приложениям переопределять это значение, сохранить небольшое значение post_max_size и ограничить размер запросов на уровне веб-сервера или прокси.
Использовать RLIMIT_AS или RLIMIT_DATA вместо этих мер не следует: PHP предупреждает, что такие ограничения могут привести к запуску того же уязвимого сценария.
Для CVE-2026-109619 необходимо установить session.upload_progress.enabled=0 и перезапустить все рабочие процессы. В PHP 8.5 дополнительно следует установить fatal_error_backtraces=0.
Отключение отслеживания прогресса загрузки файлов в сессиях блокирует подтверждённые сценарии атаки, связанные с обработкой сессий, но не исключает другие варианты эксплуатации. Полностью устранить эту уязвимость настройками без обновления невозможно.
Именно отключение session.upload_progress ранее распространялось как обходное решение до выхода исправлений. Однако в опубликованном обновлении подтверждено, что эта мера никогда не обеспечивала полной защиты. Отслеживание прогресса загрузки файлов включено по умолчанию и может обращаться к обработке сессий до завершения настройки запроса в PHP. Поэтому этот механизм участвует в одном из подтверждённых сценариев эксплуатации CVE-2026-109619. На CVE-2026-109618 отключение настройки не влияет.
До выхода обновления разработчик ядра PHP Джина Питер Баньярд (Gina Peter Banyard) ответила на предложение использовать эту настройку как достаточную меру защиты:
"Единственная мера, которую я могу рекомендовать, это установка исправления или обновление PHP. К сожалению, я знаю слишком много".
После обновления необходимо проверить настройки памяти. Исправление вводит новый жёсткий лимит памяти: при его достижении процесс завершается, а обработчики завершения работы не запускаются. Поэтому значения memory_limit и post_max_size следует сопоставить с требованиями приложения.
Если обновление уже установлено, но есть подозрение на более раннее проникновение, исследователи рекомендуют отслеживать необычные multipart-запросы, за которыми следуют ошибки превышения лимита памяти или повторяющиеся ответы HTTP 500. Также следует обращать внимание на аномально большие cookies PHPSESSID и необъяснимые перезапуски PHP-процессов.
Зафиксированы ли атаки
Ещё до выхода исправлений Cloudflare сообщила о первых попытках эксплуатации уязвимостей.
"Мы наблюдаем первые атаки и обновляем меры защиты по мере появления новых векторов", заявил технический директор Cloudflare Дейн Кнехт (Dane Knecht). Он отметил, что правила межсетевого экрана, развернутые компанией, являются временной мерой, и призвал администраторов установить исправления.
На момент публикации статьи подтверждений успешных взломов обнаружено не было. Компания watchTowr, воспроизведшая CVE-2026-109618, сообщила, что по состоянию на 11:26 UTC 21 октября не наблюдала эксплуатации уязвимости в реальных атаках. На тот момент ни одна из двух уязвимостей также не была включена в каталог известных эксплуатируемых уязвимостей CISA.
Некоторые организации временно отключили свои сервисы в качестве меры предосторожности, а не в ответ на подтверждённое проникновение.
BambooHR отключила сервис в США, Канаде и Ирландии, предупредила о перебоях в обработке заработной платы и сообщила, что пока не может назвать время восстановления работы.
В Нидерландах были отключены MijnOverheid, DigiD, сайт нижней палаты парламента, национальный центр кибербезопасности и несколько образовательных систем. Об этом сообщила телерадиокомпания NOS. Представители центра заявили, что не наблюдали эксплуатации уязвимости, но призвали организации установить исправления.
Как информация об уязвимостях стала публичной
Выход исправлений был перенесён из-за утечки информации. 20 октября, как ранее сообщало издание The Hacker News, на Hacker News появилась публикация о двух уязвимостях удалённого выполнения кода в PHP. В сообщении приводились оба идентификатора CVE и указывалось, что раскрытие информации запланировано на 22 октября. При этом автор ссылался только на полученные из доверенного источника сведения.
В тот же вечер PHP опубликовала предварительное уведомление и перенесла выпуск исправлений на 21 октября. Указанная в утечке оценка CVSS 10.0 не соответствовала оценке PHP: команда проекта присвоила обеим уязвимостям 9,2 балла.
Уязвимости обнаружили Wiz Research, Calif и команда Codex Security компании OpenAI. В подготовке исправлений также участвовали команда безопасности PHP и команда Gemini компании Google. Уязвимый код находился в PHP более десяти лет.
Исследователи отметили, что модели искусственного интеллекта помогли превратить давно существовавшие ошибки в работающие эксплойты. По их оценке, благодаря ИИ одному исследователю удалось примерно за неделю выполнить работу, которая без этих инструментов могла бы занять у целой команды несколько месяцев.
Компания Calif, проследившая происхождение ошибки до исследований PHP 2004 года, подчеркнула, что знание истории целевой системы по-прежнему имело значение. Современные модели пока не способны надёжно находить и использовать малоизвестные механизмы, появившиеся около двадцати лет назад, без дополнительного контекста.
Источник: HN