Исследование. Не является инструкцией по безопасности. Информация актуальна на 28 октября 2026 года.
21 октября 2026 года вышло обновление PHP, которое многие администраторы восприняли как «очередной патч вторника». Через несколько дней CISA подтвердила активную эксплуатацию уязвимостей в дикой природе, а часть сайтов по всему миру — включая крупные репозитории и реестры доменов — на время ушла в офлайн. Разбираюсь, почему два CVE с одинаковой оценкой 9.2 оказались важнее, чем кажется на первый взгляд, и что именно стоит сделать, если обновление ещё не установлено.
Что произошло: два бага в ядре, один патч
Речь идёт о двух уязвимостях, получивших общее название PHP2Shell: CVE-2026-109618 и CVE-2026-109619. Обе оценены в 9.2 по шкале CVSS v4.0 и позволяют неаутентифицированное удалённое выполнение кода (RCE). Официальные исправления вышли 21 октября 2026 года в версиях PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35.
Первая уязвимость (CVE-2026-109618) связана с обработкой нехватки памяти. Когда PHP превышает лимит memory_limit, интерпретатор прерывает запрос через longjmp(), и в этот момент внутренние данные запроса могут быть инициализированы лишь частично. Очистка запроса затем может обратиться к некорректным данным — и если эта память контролируется атакующим, это открывает путь к выполнению кода.
Вторая (CVE-2026-109619) связана с устаревшим глобальным состоянием. Внутреннее состояние запроса может сохраниться после освобождения памяти (например, после фатальной ошибки), и следующий запрос, обработанный тем же рабочим процессом, использует это состояние до нормальной инициализации. Результат — тот же RCE.
Важно, что уязвимости затрагивают ядро PHP, а не конкретную CMS. Под угрозой — все установки, обслуживающие веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Конфигурация mod_php считается наиболее рискованной: эксплуатация возможна ещё до выполнения кода приложения. Затронуты все версии начиная с PHP 5, хотя патчи для уже неподдерживаемых веток (7.4, 8.0, 8.1) выпущены отдельно.
Почему это важнее, чем «ещё один CVE с высоким баллом»
Высокий CVSS — не редкость. Но в этом случае сошлись несколько факторов, которые превращают патч в срочную задачу, а не в пункт для планового обновления.
Во-первых, утечка деталей до выхода патча. Техническая информация о PHP2Shell попала в сеть раньше запланированного скоординированного раскрытия. Из-за этого команда PHP выпустила экстренное обновление, а исследователи предупредили: массовая эксплуатация может начаться в течение 15 минут после публикации патчей. Когда детали уже в сети, а патч только вышел — окно между «узнали» и «обновились» становится критическим.
Во-вторых, подтверждённая эксплуатация. 27 октября 2026 года CISA добавила обе уязвимости в каталог Known Exploited Vulnerabilities (KEV), подтвердив активные атаки. Федеральным агентствам США предписано устранить уязвимости до 29 октября. Это не теоретическая угроза и не «возможна эксплуатация при определённых условиях» — это уже работающий вектор атаки.
В-третьих, масштаб. По разным оценкам, на PHP работает от 75 до 90% российских сайтов. Под потенциальный удар попадают не только «сайты на PHP», но и популярные CMS и фреймворки: WordPress, Drupal, Joomla, OpenCart, 1С-Битрикс, Laravel, Symfony, phpMyAdmin, Nextcloud и другие. При этом обновление самой CMS не закрывает уязвимость — исправлять нужно серверное окружение.
В-четвёртых, предел «временных мер». Отключение upload_progress или ограничение multipart/form-data снижает риск, но не устраняет его полностью. CERT-EU прямо указывает: полное блокирование возможно только установкой обновления. Временные ограничения — это мост до патча, а не альтернатива ему.
Чем это грозит на практике
RCE в ядре PHP означает, что атакующему не нужна учётная запись, не нужен доступ к админке и не нужна уязвимость в конкретном плагине. Один специально сформированный HTTP-запрос может привести к выполнению произвольного кода на сервере.
Последствия для бизнеса укладываются в несколько сценариев:
- Компрометация данных. Доступ к базе, конфигурационным файлам, ключам API и персональным данным пользователей.
- Изменение содержимого сайта. Внедрение вредоносных скриптов, редиректов, фишинговых страниц — с соответствующими репутационными и правовыми рисками.
- Использование сервера как точки входа. Атакующий может закрепиться и использовать инфраструктуру для дальнейших атак — на клиентов, партнёров или корпоративную сеть.
- Простой. Даже без полноценного взлома аварийное отключение сайта для установки патча — это потерянные заявки и трафик.
Отдельно стоит учитывать юридический аспект. Если утечка затронет персональные данные, компания может столкнуться с ответственностью по ст. 13.11 КоАП РФ, а в случае крупных утечек — с оборотными штрафами. Наличие неисправленной критической уязвимости на публичном сервере — это не просто технический долг, а фактор, который может быть учтён при оценке действий оператора персональных данных.
Что делать: от срочного к плановому
Шаг 1. Проверить фактическую версию PHP. Не ту, что указана в панели хостинга, а ту, которую реально обслуживает веб-сервер. Команды php -v и php-fpm -v (или php-fpm8.3 -v) могут показывать разные версии, если CLI и FPM настроены раздельно. Целевые версии — 8.5.12, 8.4.27, 8.3.36, 8.2.35 или новее.
Шаг 2. Обновить серверное окружение. Обновление через пакетный менеджер дистрибутива или панель хостинга — приоритетнее, чем ручная сборка. Если сайт на shared-хостинге и провайдер ещё не обновил PHP, стоит написать в поддержку и уточнить сроки. Крупные российские хостеры уже начали обновление и временно ограничили отдельные функции (например, upload_progress).
Шаг 3. Если обновление невозможно прямо сейчас — закрыть внешний доступ. CERT-EU рекомендует изолировать интернет-приложения от публичных сетей до установки и проверки патча. На практике это может означать временный перевод сайта в режим обслуживания, ограничение доступа по IP или размещение перед приложением WAF с правилами для аномальных multipart/form-data запросов.
Шаг 4. Проверить журналы на признаки эксплуатации. Если сервер был доступен из интернета до установки патча, стоит проверить логи на аномальные запросы, необычные дочерние процессы, признаки записи файлов в неожиданные места и другие индикаторы компрометации. Отсутствие явных симптомов не гарантирует, что атаки не было.
Шаг 5. Пересмотреть подход к срочным обновлениям. PHP2Shell — не первый и не последний случай, когда критический патч выходит вне «регулярного окна». Если в компании нет процедуры экстренного обновления (кто принимает решение, как быстро, как проверяется работоспособность после), каждый такой инцидент будет обрабатываться в ручном режиме и с задержкой.
Что это значит в более широком смысле
PHP2Shell показал не только силу конкретных уязвимостей, но и слабое место в культуре обновлений. Многие компании обновляют CMS, плагины и темы, но оставляют версию PHP на усмотрение хостера — и узнают о проблеме только из новостей. При этом именно версия PHP определяет, будет ли уязвимость в ядре эксплуатируемой.
Второй вывод — про «временные меры». Отключение функции или ограничение типа запросов действительно снижает риск, но только до определённого предела. Если временная мера становится постоянной, риск возвращается — просто с задержкой. Патч остаётся единственным способом закрыть уязвимость, а не отсрочить её.
И третий — про прозрачность. Утечка деталей до выхода патча ускорила атаки, но одновременно ускорила и реакцию: экстренный выпуск, публичные рекомендации, подтверждение эксплуатации со стороны CISA. В таких ситуациях выигрывает не тот, кто «подождёт официальных разъяснений», а тот, у кого есть процедура действий на случай критического патча.
Источники
Нормативные и технические источники приведены по состоянию на 28 октября 2026 года.
- PHP: News Archive — 2026. Security advisory: Critical remote code execution vulnerabilities, update now (PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35).
- CERT-EU. Security Advisory 2026-018: Critical Vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619).
- CISA. Known Exploited Vulnerabilities Catalog — PHP2Shell (CVE-2026-109618, CVE-2026-109619), подтверждение активной эксплуатации, 27.10.2026.
- GitHub Security Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618) и GHSA-6wmf-4rv5-p3rp (CVE-2026-109619).