Представьте обычный сайт на WordPress. Администратор своевременно обновляет плагины, защищает панель управления, использует сложные пароли и двухфакторную аутентификацию. Но злоумышленнику может оказаться достаточно специально подготовленного HTTP-запроса, чтобы выполнить собственный код на сервере. Даже если в самом WordPress нет ни одной подходящей уязвимости.
Именно такую опасность представляют две критические ошибки в интерпретаторе PHP, получившие идентификаторы CVE-2026-109618 и CVE-2026-109619. Исследователи объединили проблемы под названием PHP2Shell. Обе получили оценку 9,2 балла по CVSS 4.0, а команда PHP 21 октября выпустила внеплановые исправления. Разработчики подтвердили возможность удалённого выполнения кода без предварительной аутентификации.
В отличие от типичных уязвимостей CMS, PHP2Shell затрагивает базовый программный компонент, через который работают миллионы сайтов. Для некоторых конфигураций Apache атаку можно провести ещё до запуска прикладного PHP-кода. Проверка прав пользователя, защитные плагины и фильтрация запросов внутри приложения в таком случае просто не успеют сработать.
По данным Palo Alto Networks, в интернете обнаружено более 22,6 млн публично доступных экземпляров, потенциально подверженных двум уязвимостям. Масштаб не означает, что каждый экземпляр можно гарантированно взломать, но показывает размер проблемы, с которой столкнулись владельцы сайтов и хостинг-провайдеры.
Материал предназначен для анализа уязвимостей и защиты собственных систем. Проверять эксплуатацию PHP2Shell на чужих серверах без разрешения нельзя. Не запускайте непроверенные публичные эксплойты на рабочих системах. Некоторые способы проверки способны нарушить работу PHP-процессов и вызвать отказ в обслуживании.
Какие версии PHP уязвимы и что нужно обновить
Команда PHP выпустила четыре исправленные версии. Если сервер использует официальную сборку без перенесённых исправлений поставщика, минимальные безопасные версии выглядят следующим образом.
| Ветка PHP | Уязвимые выпуски ветки | Исправленная версия |
|---|---|---|
| PHP 8.2 | До 8.2.34 включительно | 8.2.35 |
| PHP 8.3 | До 8.3.35 включительно | 8.3.36 |
| PHP 8.4 | До 8.4.26 включительно | 8.4.27 |
| PHP 8.5 | До 8.5.11 включительно | 8.5.12 |
| PHP 8.1 и старше | Устаревшие ветки | Исправление поставщика или миграция |
Проблемы затрагивают и старые поколения PHP. Исследователи проследили уязвимые механизмы до PHP 5.4, а некоторые связанные ошибки уходят корнями ещё глубже. Для PHP 7.4, 8.0 и 8.1 подготовлены минимальные исправления исходного кода, которые могут использовать сопровождающие устаревшие системы. Наличие такого исправления не возвращает старой ветке официальную поддержку.
Если сервер работает на Ubuntu, Debian, RHEL или другом дистрибутиве с собственными пакетами, проверяйте бюллетень поставщика. Производители Linux нередко переносят исправления безопасности в старые версии без изменения основного номера PHP. Поэтому вывод php -v не всегда позволяет однозначно определить состояние защиты.
Для первоначальной инвентаризации выполните команды.
php -v php --ini php -i | grep -E 'Server API|memory_limit|post_max_size|session.upload_progress.enabled|fatal_error_backtraces'
На сервере с PHP-FPM дополнительно проверьте установленные службы и активные рабочие процессы.
systemctl list-units --type=service 'php*-fpm.service' ps aux | grep '[p]hp-fpm'
Команды для интерфейса командной строки не гарантируют, что веб-сервер использует тот же исполняемый файл и тот же конфигурационный файл PHP. При нескольких установленных версиях необходимо проверить конкретный пул PHP-FPM, контейнер или модуль Apache, который обслуживает сайт.
Обычное обновление WordPress, Drupal, Joomla или Magento проблему не устраняет. Ошибка находится ниже уровня CMS. Даже полностью обновлённый сайт остаётся под угрозой, если веб-запросы обрабатывает уязвимый PHP.
Как работает CVE-2026-109618 и почему атака возможна до запуска сайта
Первая уязвимость связана с обработкой нехватки оперативной памяти. Внутри PHP существует механизм аварийного прекращения операций при невозможности выделить очередной участок памяти. Для перехода к обработчику ошибки интерпретатор использует в том числе longjmp().
Сама функция longjmp() не является уязвимостью. Опасность возникает, когда аварийный переход нарушает порядок подготовки и освобождения внутренних объектов. PHP прекращает текущую операцию, но при завершении запроса может обратиться к структурам, которые не были корректно инициализированы или уже находятся в недопустимом состоянии.
Цепочка эксплуатации в упрощённом виде выглядит так.
- PHP получает HTTP-запрос и начинает разбирать входные данные.
- Обработка запроса приводит к интенсивному выделению памяти.
- Возникает ошибка нехватки памяти, которая прерывает обычный порядок выполнения операций.
- PHP начинает завершать запрос и очищать внутренние структуры, часть которых осталась в некорректном состоянии.
- Работа с такими структурами вызывает повреждение памяти. При подходящем расположении объектов атакующий может превратить повреждение в выполнение собственного кода.
Исследователи показали несколько способов спровоцировать опасное состояние. Один из них связан с разбором multipart/form-data, стандартного формата передачи веб-форм и загружаемых файлов. Запрос может содержать множество полей, сложные вложенные имена и дополнительные заголовки частей. PHP расходует память не только на содержимое запроса, но и на служебные структуры, необходимые для его обработки.
Из-за разницы между размером сетевых данных и объёмом выделенной памяти ограничение post_max_size не гарантирует защиту. Дополнительную проблему создают запросы без пригодного Content-Length, когда некоторые предварительные проверки размера тела запроса не могут сработать обычным образом.
Наиболее опасная подтверждённая конфигурация связана с Apache и модулем mod_php. В таком режиме PHP может обрабатывать входные данные и столкнуться с уязвимым состоянием ещё до того, как управление перейдёт к файлу сайта. Исследователям удалось продемонстрировать удалённое выполнение кода без аутентификации при обычных ограничениях памяти.
Для PHP-FPM картина сложнее. Рабочий процесс в ряде случаев завершается при ошибке инициализации запроса, что разрушает конкретную цепочку, проверенную для mod_php. Но уязвимый код присутствует и в PHP-FPM, а опасные ошибки управления памятью могут возникать после успешного запуска запроса. Поэтому считать PHP-FPM защищённым нельзя.
В список потенциально затронутых конфигураций входят также php-cgi, FrankenPHP и LiteSpeed LSAPI. Различается степень подтверждённой эксплуатации, а не необходимость исправления. Подробное техническое описание первой ошибки опубликовано в GHSA-w8hw-w9fx-j79w.
Вторая уязвимость, утечка памяти и возможности атакующего
CVE-2026-109619 представляет отдельную проблему, связанную с глобальным состоянием PHP и повторным использованием рабочих процессов. PHP сохраняет в памяти некоторые данные, относящиеся к ошибкам, сеансам, объектам и расширениям. Перед освобождением памяти очередного HTTP-запроса ссылки на связанные объекты должны быть очищены.
В определённых ситуациях очистка происходит неправильно. Следующий запрос получает доступ к оставшейся ссылке на уже освобождённую память. Возникает состояние Use After Free, когда программа обращается к участку памяти, который больше не принадлежит прежнему объекту.
Повторное выделение памяти позволяет разместить в освобождённом участке другие данные. Если атакующий достаточно точно управляет расположением объектов, некорректная ссылка может привести к чтению чужой памяти или выполнению произвольного кода. Разработчики описали несколько путей возникновения опасного состояния, включая ошибки при работе с сеансами и обработке исключительных ситуаций.
Принципиальное отличие от первой уязвимости заключается в возможности переноса опасного состояния между запросами, которые обслуживает один рабочий процесс. Для успешной эксплуатации требуется соблюдение определённых условий, но предварительная аутентификация не обязательна.
Специалисты Wiz продемонстрировали не только удалённое выполнение кода, но и раскрытие памяти PHP-процесса без предварительного захвата сервера. Последствие напоминает класс атак, ставший известным после Heartbleed. В памяти веб-приложения могут находиться ключи API, токены, пароли, параметры сеансов и данные других запросов.
Однако сравнение с Heartbleed не означает идентичный механизм или гарантированную возможность массово извлекать секреты из любого PHP-сервера. Эксплуатация PHP2Shell зависит от поведения интерпретатора, конфигурации, состояния памяти и построения подходящей цепочки.
Исследователи Wiz подтвердили рабочие сценарии на тестовых установках WordPress, Drupal и Joomla. Речь идёт о проверке уязвимостей в лабораторных условиях, а не о доказанном взломе реальных сайтов соответствующих проектов. Технические детали экспериментов доступны в исследовании Wiz.
Реальные атаки, масштаб угрозы и роль искусственного интеллекта
Сообщения об эксплуатации PHP2Shell появились ещё до выхода исправлений. 21 октября в 07:34 UTC компания Patchstack получила от нескольких хостинг-провайдеров сведения об активных атаках. Cloudflare также зафиксировала вредоносный трафик и попытки изменять атакующие запросы, чтобы обойти защитные правила.
Здесь необходимо разделять три события. Обнаружение подозрительных запросов подтверждает интерес злоумышленников. Срабатывание защитного механизма говорит о попытке атаки, но не доказывает успешный взлом. Только результаты расследования конкретного инцидента позволяют уверенно утверждать, что атакующий выполнил код или похитил данные.
На момент подготовки материала подтверждены рабочие исследовательские цепочки удалённого выполнения кода, опубликованы исправления и зафиксированы атаки на реальные серверы. Достоверного публичного подсчёта успешно скомпрометированных систем пока нет. Сообщения о массовой эксплуатации не следует автоматически превращать в утверждения о миллионах взломанных сайтов.
Отдельного внимания заслуживает реакция Cloudflare. Компания сообщила, что начала разрабатывать защиту заранее, а 21 октября в 03:02 UTC правила для пользователей бесплатных и платных тарифов WAF уже действовали по умолчанию. Защитные механизмы пришлось расширить анализом не только входящих HTTP-запросов, но и ответов сервера. Такой подход помогает распознавать опасные последовательности, которые сложно отличить от обычного трафика по одному запросу.
Проверить срабатывания можно в Cloudflare через раздел Security → Security Analytics → Events. Для платных тарифов рекомендуется убедиться, что управляемые правила работают в режиме блокировки. Конкретные идентификаторы и состав защитных правил опубликованы Cloudflare. WAF остаётся дополнительным уровнем защиты и не заменяет обновление PHP.
Реакция затронула и государственную инфраструктуру. В Нидерландах в качестве меры предосторожности временно отключали DigiD, MijnOverheid и некоторые другие государственные и муниципальные ресурсы. Профилактическое отключение не означает, что сайты были взломаны. Администраторы предпочли ограничить доступ, пока оценивали риск и устанавливали исправления.
По оценке Palo Alto Networks Unit 42, число публично доступных экземпляров, потенциально затронутых PHP2Shell, превышает 22,6 млн. При этом статистика распространённости PHP среди сайтов с определяемым серверным языком приближается к 70%. Ни первая, ни вторая цифра не показывает количество гарантированно эксплуатируемых серверов. Для реальной атаки имеют значение версия PHP, способ запуска интерпретатора, конфигурация, установленные исправления и доступность опасных путей обработки данных.
Как исследователи обнаружили ошибки, существовавшие годами
История PHP2Shell началась задолго до публичного раскрытия. Компания Wiz обнаружила первую проблему 19 августа и уже 20 августа подтвердила удалённое выполнение кода на тестовом Drupal. На следующий день исследователи воспроизвели атаку на WordPress, а 24 августа сообщили об уязвимостях команде PHP.
Независимо над проблемой работала компания Calif. В исследованиях участвовали современные языковые модели, включая GPT-5.6 Sol и Gemini 4 Argon. Wiz также применяла собственную исследовательскую платформу Wiz Atlas. Модели помогали анализировать исходный код, находить опасные состояния памяти, строить цепочки эксплуатации и проверять исправления.
Интерес PHP2Shell заключается не просто в использовании ИИ. Некоторые ошибки управления памятью в PHP были известны или обсуждались много лет, но превратить отдельные дефекты в надёжную цепочку удалённого выполнения кода было значительно сложнее.
Современные модели помогли исследователям преодолеть часть сложности. По оценке Wiz, задачи, которые прежде потребовали бы длительной работы сильной команды специалистов, удалось выполнить намного быстрее. Однако речь идёт об оценке участников исследования, а не о независимом доказательстве универсального превосходства ИИ над специалистами по поиску уязвимостей.
Случай PHP2Shell показывает более конкретную тенденцию. Старый и хорошо изученный программный код может содержать ошибки, которые становятся практически эксплуатируемыми после появления новых инструментов анализа. Поэтому возраст уязвимости не определяет её опасность, а отсутствие известных эксплойтов в прошлом не гарантирует безопасность сегодня.
Как защитить сервер и проверить возможную компрометацию
Единственное полноценное исправление обеих уязвимостей заключается в установке обновлённого PHP или пакета поставщика с перенесёнными исправлениями. Временные изменения конфигурации позволяют усложнить отдельные атаки, но не устраняют ошибки управления памятью.
Для CVE-2026-109618 разработчики PHP предложили необычную временную меру. Администратор может отключить внутреннее ограничение памяти PHP, установив memory_limit=-1 на уровне серверной конфигурации. Подход убирает предсказуемую ошибку выделения памяти, на которой основана подтверждённая цепочка эксплуатации.
Однако отключение лимита не делает сервер безопасным. PHP может исчерпать физическую память или столкнуться с ошибкой выделения памяти по другой причине. Кроме того, неограниченное потребление ресурсов создаёт риск отказа в обслуживании. Для временного режима потребуются ограничения памяти контейнеров или cgroup, желательно с изоляцией отдельных рабочих процессов. Разработчики прямо предупреждают, что RLIMIT_AS и RLIMIT_DATA могут вызвать опасные сбои выделения памяти и не подходят в качестве замены.
Для сайтов без загрузки файлов PHP рекомендует консервативное значение post_max_size, например 8M. Если загрузка необходима, ориентиром может служить 32M, но конкретный предел зависит от задач приложения. Также полезно ограничить число multipart-секций, вложенность входных параметров, количество полей и размер декодированного тела запроса на уровне веб-сервера или обратного прокси.
Для CVE-2026-109619 разработчики рекомендуют отключить механизм отслеживания прогресса загрузки через сессии, установив session.upload_progress.enabled=0, после чего перезапустить рабочие процессы. На PHP 8.5 дополнительной временной мерой служит fatal_error_backtraces=0. Настройки должны применяться до разбора HTTP-запроса. Изменения внутри приложения через ini_set() не заменяют серверную настройку.
После внесения исправлений полезно выполнить повторную инвентаризацию. Проверьте активную версию PHP, фактический конфигурационный файл, все пулы PHP-FPM, контейнеры, сторонние панели управления и встроенные интерпретаторы. Обновление PHP на основной системе не исправляет автоматически PHP внутри стороннего контейнера или приложения.
Для поиска возможных попыток эксплуатации проверьте журналы HTTP-запросов и событий веб-сервера. Особого внимания заслуживают необычные multipart-запросы, ошибки нехватки памяти, повторяющиеся HTTP 500, аварийные завершения рабочих процессов и неожиданный запуск командных интерпретаторов от имени пользователя веб-сервера.
Ни один из перечисленных признаков сам по себе не доказывает взлом. Отсутствие ошибок и аварийных завершений также не гарантирует, что компрометации не было. При серьёзных подозрениях необходимо сохранить журналы и данные для расследования, проверить процессы и файлы приложения, установить источник подозрительных изменений и заменить секреты, к которым потенциально получил доступ атакующий.
Частые вопросы о PHP2Shell
Можно ли взломать через PHP2Shell сайт без формы загрузки файлов?
Да, наличие формы загрузки файлов не является обязательным условием для всех возможных цепочек. Опасные операции обработки HTTP-запросов могут выполняться самим PHP до запуска приложения. Однако конкретная применимость зависит от серверной конфигурации и доступных путей обработки данных.
Защищён ли сайт, если PHP работает через PHP-FPM?
Нет. Для CVE-2026-109618 публично подтверждённая цепочка на mod_php не переносится на PHP-FPM автоматически, но разработчики относят PHP-FPM к затронутым конфигурациям. Оба исправления необходимо установить независимо от способа запуска интерпретатора.
Может ли Cloudflare полностью остановить PHP2Shell?
Cloudflare выпустила специальные защитные правила и сообщила о блокировке атакующего трафика. Но WAF не исправляет повреждение памяти внутри PHP. Неизвестные варианты атаки, ошибки настройки правил и прямой доступ к исходному серверу могут сохранить риск.
Почему обновление WordPress не устраняет уязвимость?
Потому что CVE-2026-109618 и CVE-2026-109619 находятся в интерпретаторе PHP. Обновление WordPress исправляет код CMS, но не заменяет PHP, установленный на сервере.
Можно ли проверить наличие уязвимости обычным удалённым сканером?
Обычный сканер не всегда способен надёжно установить наличие исправления, особенно если поставщик перенёс патч в старую версию PHP. Надёжнее проверить установленные пакеты, бюллетень поставщика и фактически работающий интерпретатор. Запуск эксплойта на рабочем сервере может нарушить обслуживание запросов.
Гарантирует ли уязвимость получение root-доступа?
Нет. Подтверждённая эксплуатация позволяет выполнять код с правами рабочего процесса PHP или веб-сервера. Для получения более высоких привилегий обычно нужны дополнительные ошибки конфигурации или отдельные уязвимости.
Почему PHP2Shell получила оценку 9,2, а не 10 баллов?
Оценка CVSS 4.0 учитывает не только тяжесть последствий, но и сложность атаки, дополнительные условия, необходимые для эксплуатации, и другие параметры. Возможность удалённого выполнения кода без аутентификации не означает автоматического получения максимальной оценки.
Что делать владельцу сайта на виртуальном хостинге без доступа к настройкам PHP?
Нужно запросить у хостинг-провайдера подтверждение установки исправленной версии PHP или соответствующего патча поставщика. Проверьте версию, выбранную для конкретного сайта в панели хостинга, и уточните, распространяется ли обновление на все используемые приложения.
Вывод
PHP2Shell относится к наиболее серьёзным уязвимостям PHP последних лет. Опасность связана не только с высокой оценкой CVSS, но и с уровнем расположения ошибок. Даже хорошо защищённое веб-приложение не способно самостоятельно исправить повреждение памяти внутри интерпретатора, а некоторые цепочки позволяют атаковать сервер до запуска кода сайта.
Администраторам следует в первую очередь установить исправленные версии PHP, проверить реально работающие интерпретаторы и сохранить дополнительные защитные правила WAF. Временные настройки памяти и ограничения HTTP-запросов подходят только для краткосрочного снижения риска, когда обновление пока недоступно.
История PHP2Shell также меняет представление о давно известных ошибках. Уязвимые механизмы могли существовать годами, но современные инструменты анализа помогли превратить сложные дефекты управления памятью в практически работающие цепочки эксплуатации. Для владельцев серверов главный урок прост. Отсутствие известных атак вчера не означает безопасности сегодня, особенно когда ошибка находится в одном из базовых компонентов веб-инфраструктуры.
```
