PHP2Shell: гонка со временем — что уязвимости PHP означают для веб-сайтов, устройств и ваших данных

Две критические уязвимости в PHP, преждевременно сорванное эмбарго и попытки атак еще до официального раскрытия: PHP2Shell затрагивает не только обычные веб-сайты. Уязвимая среда выполнения может быть встроена также в межсетевые экраны, панели управления хостингом и другие устройства. Простыми словами объясняем, что произошло, кому необходимо действовать и что действительно следует предпринять частному пользователю.

20 октября в интернете появились два на первый взгляд непримечательных номера: CVE-2026-109618 и CVE-2026-109619. За ними скрывались две еще не полностью раскрытые уязвимости PHP — технологии, которая обрабатывает формы, выполняет запросы к базам данных и формирует страницы на бесчисленных веб-серверах.

Раскрытие должно было пройти упорядоченно: сначала обновления и заранее подготовленные защитные правила, затем технические подробности. Однако идентификаторы стали известны раньше времени, начала распространяться ошибочная максимальная оценка 10,0, а вечером по ошибке было опубликовано видео с работающей атакой. PHP перенес выпуск обновления на день раньше.

Но для спокойного старта было уже поздно: позднее Amazon обнаружила попытку эксплуатации от 17 октября — за четыре дня до выхода исправления. После раскрытия поставщики зафиксировали быстро растущую волну атак; Reuters со ссылкой на Cloudflare сообщило о миллионах попыток за несколько часов. Речь не идет о миллионах успешных взломов, но эти цифры показывают, насколько быстро критические уязвимости сегодня проверяются автоматизированными системами.

Сама уязвимость находится не на вашем смартфоне. Тем не менее она может затронуть вас через данные, хранящиеся у поставщика услуг, измененные веб-сайты, более убедительный фишинг или сервисы, которые профилактически отключают. Ваше устройство может быть чистым, в то время как ваши данные подвергаются риску на чужом сервере.

Самое важное — вначале

PHP2Shell — название двух ошибок безопасности памяти в ядре PHP. При определенных условиях злоумышленники могут без входа в систему выполнять код на сервере; одна из уязвимостей также способна раскрывать содержимое памяти с токенами сеансов, паролями, API-ключами или учетными данными баз данных. Обе CVE имеют оценку 9,2 по CVSS 4.0.

Исправления присутствуют в основных ветках начиная с PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Для более старых веток дистрибутивы, хостинг-провайдеры или поставщики LTS могут выпускать перенесенные исправления. Одного обновления CMS или плагина недостаточно: решающее значение имеет среда выполнения PHP, которая фактически обрабатывает веб-запросы.

Обычным пользователям не нужно ничего устанавливать на телефон. Операторы должны провести инвентаризацию и обновить веб-сайты, контейнеры, интерфейсы управления и устройства с PHP, а также проверить их на возможные более ранние атаки.

1. Как старая проблема с памятью превратилась в глобальную гонку со временем

2024 год: тревожный сигнал без подтвержденной атаки

История началась еще в 2024 году. Во время внешнего аудита безопасности PHP исследователи заметили первые признаки проблемы, которая позднее проявилась как ошибка при исчерпании памяти. Однако надежного пути от веб-запроса к выполнению кода не существовало, а возможные исправления могли нарушить совместимость или стабильность. Небольшая команда безопасности не смогла быстро прийти к единому решению. Позднее PHP Foundation открыто назвала эту задержку структурным сбоем: процессы принятия решений были слишком тяжеловесными, а ресурсов не хватало.

Лето 2026 года: исследования с применением ИИ превращают теорию в практику

В июле и августе 2026 года Calif, OpenAI и Wiz исследовали ядро PHP классическими методами и с помощью мощных моделей ИИ. 11 августа исследователи сообщили о конкретном пути к удаленному выполнению кода; компания Wiz независимо обнаружила дополнительные варианты и продемонстрировала цепочки атак на реальные PHP-приложения. Людям по-прежнему требовалось воспроизводить результаты, исключать ложные срабатывания и проверять исправления. Однако ИИ сократил время поиска — а вместе с ним и время, которое остается защитникам после раскрытия уязвимости.

17 октября: самая ранняя известная попытка

Позднее Amazon Threat Intelligence обнаружила в телеметрии MadPot попытку эксплуатации от 17 октября. Срабатывание приманки не доказывает успешной компрометации реальных систем, но сдвигает начало периода, который необходимо охватить при форензике. Как злоумышленник получил достаточно сведений так рано, остается неизвестным; надежной атрибуции нет.

20 и 21 октября: эмбарго нарушено, исправление опубликовано

20 октября идентификаторы CVE начали публично распространяться вместе с ошибочной оценкой CVSS 10,0 и случайно опубликованным видео атаки. PHP перенес выпуск на 21 октября, 14:00 UTC. Хостинг-провайдеры, дистрибутивы и поставщики средств защиты параллельно готовили пакеты и фильтры. Cloudflare активировала защитные правила еще до выпуска и объединяла сигналы из запросов и ответов. Тем не менее WAF остается лишь дополнительным барьером: он не исправляет уязвимый код PHP.

Исправленные версии вышли 21 октября; вскоре после этого появились общедоступные инструменты эксплуатации и началось массовое сканирование. Государственные органы, клиники, университеты и компании профилактически отключали сервисы; на некоторое время были недоступны и полицейские службы в Берлине и Бранденбурге. Это не доказывает факт взлома; напротив, такое решение может свидетельствовать о работающем аварийном процессе: лучше контролируемо уйти в офлайн, чем оставаться в сети в скомпрометированном состоянии. PHP2Shell также показывает, что доступные из интернета системы при критических RCE-уязвимостях должны реагировать в течение часов, а не дней.

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

2. Что именно ломается на техническом уровне — без лишнего жаргона

PHP работает в «машинном отделении» веб-сайта: выполняет код WordPress, интернет-магазинов и порталов, обрабатывает ввод и взаимодействует с базами данных. Ошибки находятся ниже уровня CMS. Поэтому даже полностью обновленное приложение может работать поверх уязвимой среды PHP.

CVE-2026-109618: очистка при неполных данных

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

На Apache с mod_php продемонстрирована атака без аутентификации, которая может сработать еще до выполнения кода самого приложения. В таком случае вход в систему, двухфакторная аутентификация или защитный плагин WordPress не помогают. Другие режимы работы PHP также могут быть затронуты; необходимые условия и надежность эксплуатации зависят от SAPI, приложения и конфигурации.

CVE-2026-109619: устаревший указатель сохраняется до следующего запроса

При второй уязвимости после серьезной ошибки сохраняется указатель на уже освобожденную память. Когда тот же рабочий процесс PHP обрабатывает последующий запрос, он повторно использует это устаревшее состояние — возникает use-after-free, то есть обращение к памяти после ее освобождения, либо сохраняется устаревшее глобальное состояние.

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

Удаленное выполнение кода изначально означает запуск кода с правами учетной записи PHP или веб-сервера, а не автоматическое получение root-доступа. Однако такая учетная запись может читать конфигурацию, обращаться к базам данных или внутренним сервисам. Поэтому права на файлы, сегментация сети и принцип минимальных привилегий определяют, насколько далеко сможет распространиться компрометация.

3. Действительно ли затронуто почти 70 процентов интернета?

По данным W3Techs на 23 октября 2026 года, PHP используется на 69,3% веб-сайтов, для которых сервис может определить серверный язык программирования. Среди этих PHP-сайтов 65,3% используют PHP 8, 26,9% — PHP 7 и 7,7% — PHP 5.

Эти цифры описывают распространенность, а не состояние исправлений или число успешных атак. Многие системы были обновлены за считаные часы, дистрибутивы поставляют перенесенные исправления под более старыми номерами версий, а на специализированных устройствах уязвимый путь может быть недоступен из интернета. Поэтому корректный вывод таков: примерно семь из десяти сайтов с определяемым серверным языком используют PHP и должны были проверить свою защиту. Надежно оценить, сколько систем сегодня остаются уязвимыми или уже скомпрометированы, невозможно.

4. Что PHP2Shell означает для частных пользователей

PHP не заражает ваше устройство напрямую

PHP2Shell действует на серверах. Вам не нужно сбрасывать смартфон или устанавливать специальное приложение. Риск для устройства возникает лишь в том случае, если измененный сайт убедит вас загрузить вредоносный файл. Поддерживайте операционную систему, браузер и приложения в актуальном состоянии и пользуйтесь только доверенными источниками. Предлагаемое «обновление PHP2Shell» для вашего устройства почти наверняка является приманкой.

Ваши данные все равно могут пострадать

Когда вы делаете заказ в интернет-магазине, имя, адрес и история покупок могут храниться там длительное время. Если сервер скомпрометирован, эти данные могут пострадать, даже если вы не посещали сайт несколько месяцев. Раскрытие памяти также способно показать токены и ключи доступа, которые не существуют на сервере в виде файлов.

Даже знакомый сайт может быть изменен: домен и значок замка остаются прежними, а внедренный скрипт перехватывает данные для входа или оплаты. HTTPS защищает соединение с сервером, но не целостность самого сервера. Если появляются непривычные платежные окна, перенаправления или загрузки, прекратите операцию и свяжитесь с поставщиком по известному официальному каналу.

После технической атаки часто следует мошенничество

Похищенные сведения делают фишинг убедительнее. Даже сообщение с вашим настоящим именем и правильным номером заказа может быть поддельным. Открывайте важные сервисы через официальное приложение, закладку или адрес, введенный вручную. Признаки захвата учетной записи включают неожиданные уведомления о входе или сбросе пароля, незнакомые сеансы, измененные данные восстановления, а также запросы на push-подтверждение, TAN-коды или двухфакторную аутентификацию, которые вы не инициировали. Не подтверждайте ничего «на всякий случай» — откройте учетную запись напрямую и удалите неизвестные устройства.

Для интернет-банкинга одного пароля или PIN-кода обычно недостаточно благодаря усиленной аутентификации клиента. Однако фишинг может заставить вас подтвердить подлинный запрос авторизации для чужого входа или платежа. Проверяйте получателя, IBAN и сумму; при неизвестной операции связывайтесь с банком через официальное приложение или известный номер телефона.

Что разумно сделать сейчас

Если сервис сообщает только о техническом обслуживании или профилактическом отключении, не нужно без разбора менять пароли или блокировать карты. Используйте официальный альтернативный канал и следите за сообщениями поставщика.

Если поставщик сообщает о возможной утечке учетных данных, измените пароль там и везде, где вы использовали его повторно. Завершите активные сеансы, включите двухфакторную аутентификацию или ключи доступа и в первую очередь защитите учетную запись электронной почты.

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

Ни одно защитное приложение и ни один VPN не могут исправить среду PHP чужого интернет-магазина. Защитное ПО помогает против второй волны атак — вредоносных загрузок, поддельных приложений и известных вредоносных сайтов, — но не гарантирует безопасность данных на чужом сервере.

5. PHP используется также в межсетевых экранах, NAS-системах и других устройствах

PHP встречается не только на веб-сайтах, но и в интерфейсах управления и дополнительных сервисах межсетевых экранов, маршрутизаторов, NAS-систем, панелей управления хостингом, VoIP-систем, видеорегистраторов и промышленных устройств. Продукт затронут только в том случае, если он использует уязвимую версию PHP для обработки доступных веб-запросов. Значение имеют также степень доступности и наличие исправления от производителя.

pfSense: Netgate подтвердила, что уязвимы веб-интерфейс на PHP и captive portal (портал авторизации). Стандартный интерфейс обычно доступен только из локальной сети; captive portal, напротив, намеренно обслуживает недоверенных клиентов. Поэтому один и тот же дефект несет разный риск в зависимости от доступности.

Palo Alto Networks: затронуты определенные версии PAN-OS и Panorama. По данным производителя, проблема касается веб-интерфейса управления, включая XML API, а не плоскости передачи данных или GlobalProtect в целом. До установки исправления доступ к управлению следует разрешать только из доверенных сетей или через контролируемый jump host.

Plesk: клиентские сайты используют собственные обработчики PHP, а интерфейс Plesk — отдельный движок. Если обновить только один уровень, второй можно упустить. Поэтому Plesk выпустила обновления для обоих компонентов.

Cisco и Sophos показывают, почему продукты, облачные сервисы и клиентские установки необходимо оценивать отдельно. Cisco подтвердила уязвимость отдельных семейств продуктов, другие признала незатронутыми и продолжала проверять дополнительные продукты. Sophos заявила, что ее продукты не затронуты, но временно отключила отдельно размещенный устаревший портал MyUTM, поскольку тот использовал уязвимую версию PHP.

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

Что проверить на устройстве дома или в организации

Запишите производителя, модель, версию прошивки и дополнительные пакеты. Найдите на официальном сайте поддержки сведения по обеим CVE и по запросу «PHP2Shell», а обновления устанавливайте только через предусмотренный механизм прошивки или пакетов. Никогда не заменяйте встроенный PHP самостоятельно: специализированные устройства часто содержат изменения производителя и подписанные компоненты.

Отключите удаленное управление со стороны WAN, ненужные пробросы портов и правила UPnP, а также проверьте облачный удаленный доступ. Если внешний доступ необходим, по возможности используйте VPN и открывайте локальный интерфейс только после подключения.

Разделите гостевую, IoT- и управляющую сети, чтобы скомпрометированные устройства не могли обращаться к локальным сервисам управления. Если межсетевой экран, NAS или видеорегистратор больше не получает обновления безопасности, замена часто остается единственным устойчивым решением.

6. Что операторам необходимо сделать прямо сейчас

Шаг 1: определить ответственность и провести инвентаризацию

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

Шаг 2: проверить правильный уровень исправлений

PHP 8.5.12 · PHP 8.4.27 · PHP 8.3.36 · PHP 8.2.35. Для PHP 7.4, 8.0 и 8.1 доступны исправления на уровне исходного кода, перенесенные в эти ветки; определяющим является бюллетень дистрибутива или поставщика LTS.

Дистрибутивы могут переносить исправления в более старые версии пакетов. Например, Ubuntu 24.04 LTS указывает 8.3.6-0ubuntu0.24.04.13 как исправленную версию; cPanel также перенесла исправления в старые пакеты. Поэтому сравнивайте полную версию пакета с бюллетенем дистрибутива или поставщика платформы, а не только с номером исходной версии PHP.

Шаг 3: проверить среду выполнения, которая действительно обрабатывает запросы

Команда php -v обычно показывает только версию командной строки. Веб-сервер может использовать другую установку через PHP-FPM, mod_php или контейнер. Поэтому проверьте пулы FPM, модули веб-сервера, виртуальные хосты и образы:

php -v
php -r 'echo PHP_VERSION, " | ", PHP_SAPI, PHP_EOL;'
systemctl list-units --type=service 'php*-fpm.service'

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

Шаг 4: не пропускать запросы к PHP на системах, которые пока нельзя обновить

Если немедленно установить исправление невозможно, ограничьте доступ доверенными сетями или VPN — либо отключите сервис от сети. Плагин режима обслуживания WordPress не защищает, если атака срабатывает до выполнения кода приложения. Используйте статическую страницу обслуживания или блокируйте доступ на обратном прокси, балансировщике нагрузки либо веб-сервере.

Правила WAF и CDN могут выиграть время, но не являются исправлением. Cloudflare наблюдала изменение шаблонов атак и была вынуждена совместно анализировать запросы и ответы. Убедитесь также, что исходный сервер нельзя напрямую открыть через второй IP-адрес или альтернативное имя хоста.

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

Шаг 5: проверить события как минимум с 17 октября

Сохраните журналы веб-сервера, PHP, прокси, WAF, системы и контейнеров до их ротации. Ищите необычные запросы форм, PHP_SESSION_UPLOAD_PROGRESS, ошибки памяти, неожиданные процессы оболочки, новые файлы, учетные записи, задания cron и исходящие соединения. Успешная атака не обязана завершать рабочий процесс аварийно; и наоборот, единичная ошибка еще не доказывает взлом. Решающее значение имеет общая картина.

Шаг 6: сменить все секреты, доступные PHP

Поскольку содержимое памяти может быть раскрыто, на доступных из интернета системах, которые оставались без исправления, необходимо сменить все секреты, которые мог читать процесс PHP: пароли баз данных, API-, облачные и токены развертывания, учетные данные SMTP или OAuth и ключи сеансов. Сначала устраните или изолируйте уязвимость, а затем создайте новые учетные данные в доверенной среде.

Шаг 7: при признаках компрометации не ограничиваться «уборкой»

При признаках компрометации контролируемо изолируйте систему, сохраните журналы и при необходимости энергозависимые данные, а критические узлы восстановите из доверенных артефактов вместо простого удаления видимых файлов. Проверьте также учетные записи администраторов и баз данных, конвейеры развертывания и связанные системы. Если могли быть затронуты персональные данные, как можно раньше подключите специалистов по конфиденциальности или защите данных; нарушение, подлежащее уведомлению по GDPR, как правило, необходимо сообщить в течение 72 часов.

7. Главный вывод: уязвимости находят быстрее — исправления должны успевать

PHP2Shell показывает, как ИИ сдвигает границу между «теоретически возможным» и «практически эксплуатируемым». Модели способны в большом масштабе анализировать исходный код, трассировки сбоев и различия между исправлениями; в результате сокращается и промежуток между раскрытием и появлением работающего эксплойта.

Ответ заключается не просто в большем количестве ИИ. Командам сопровождения нужны ресурсы и ясные процессы принятия решений; операторам — полные инвентаризации, короткие циклы установки исправлений, изоляция и отработанное восстановление. В Protectstar мы используем ИИ в дополнение к проверке кода и человеческой валидации. Он ускоряет поиск, но не заменяет ответственность.

Заключение

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

Для операторов решающее значение имеют реально активная среда PHP, каждая забытая инстанция, встроенные компоненты, перезапуск старых процессов и проверка событий как минимум с 17 октября. Если исправления нет, изоляция ответственнее дальнейшей эксплуатации. Доступный веб-сайт еще не является доказательством его безопасности.