Коротко

Ваши системы

Затронуты ли вы?

Если у вас используется PHP, обслуживающий веб-запросы (PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP или LiteSpeed), и его версия старше 8.2.35, 8.3.36, 8.4.27 или 8.5.12, исходите из того, что вы затронуты. Это относится и к приложениям на основе PHP, таким как WordPress, Drupal, Magento и Laravel.

Продукты TR7

Затронут ли TR7?

Нет. В устройствах TR7 нет компонента PHP, обрабатывающего HTTP-запросы, поэтому эти уязвимости не затрагивают продукты TR7. Подробности в разделе Затронут ли TR7?.

Действия

Что делать сейчас

  1. Обновите PHP на серверах веб-приложений и перезапустите все рабочие процессы PHP.
  2. Если вы не можете выполнить обновление сегодня, примените на этих серверах приведённые ниже временные настройки PHP.
  3. До завершения обновления примените основные настройки защиты в TR7 WAF-WAAP; первая из них состоит в переводе ваших PHP-приложений в режим Blocking mode.

Основные сведения

Идентификатор бюллетеняTR7-SA-2026-001
НазваниеPHP2Shell
CVECVE-2026-109618 (удалённое выполнение кода через повреждение памяти при её исчерпании),
CVE-2026-109619 (удалённое выполнение кода через устаревшее глобальное состояние)
Официальные бюллетениОбъявление PHP Security Team
GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
КритичностьCVSS v4.0 9.2, критическая (PHP Security Team)
Требуется аутентификацияНет
Исправленные версииPHP 8.2.35, 8.3.36, 8.4.27, 8.5.12
Старые веткиPHP Security Team опубликовала бэкпорты исправлений в исходном коде для PHP 7.4, 8.0 и 8.1. Дистрибутивы Linux предоставляют собственные исправленные пакеты.
ЭксплуатацияПоступают сообщения о попытках эксплуатации. По состоянию на 22 октября 2026 г. успешная компрометация не была публично подтверждена.
CISA KEVОтсутствует в каталоге по состоянию на 21 октября 2026 г.

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

  • 20 октября 2026 г. Подробности уязвимостей стали публично известны до скоординированного выпуска исправлений.
  • 21 октября 2026 г. Проект PHP выпустил исправленные версии и опубликовал бюллетени GHSA-w8hw-w9fx-j79w и GHSA-6wmf-4rv5-p3rp.
  • 21-22 октября 2026 г. Поступили сообщения о попытках эксплуатации, появился общедоступный PoC-код.

Как работает атака

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

  • CVE-2026-109618 эксплуатирует момент, когда у PHP заканчивается память. Злоумышленники отправляют запросы, которые заставляют PHP расходовать много памяти при разборе данных форм и загружаемых файлов, чтобы PHP остановился в небезопасном состоянии.
  • CVE-2026-109619 оставляет в рабочем процессе PHP устаревшие данные после одного запроса, и второй запрос к тому же рабочему процессу их использует. Один из задокументированных путей использует функцию PHP session upload progress, которая включена по умолчанию и активируется полем формы с именем PHP_SESSION_UPLOAD_PROGRESS.

Поскольку запросы, через которые проводятся эти атаки, в основном являются запросами multipart/form-data (загрузка файлов), запросами с большим телом и повторяющимися запросами, межсетевой экран веб-приложений (WAF) может видеть и ограничивать многие из них. Того, что происходит в памяти PHP, он видеть не может.

Затронут ли TR7?

Эти уязвимости находятся в собственном уровне обработки запросов PHP и затрагивают серверы приложений, на которых работает PHP. В устройствах TR7 нет компонента PHP, обрабатывающего HTTP-запросы, поэтому эти уязвимости не затрагивают продукты TR7.

Что нужно сделать сейчас

Работы выполняются в двух местах: на ваших собственных серверах веб-приложений, где работает PHP, и в TR7 WAF-WAAP. Шаги в каждом разделе пронумерованы отдельно.

На ваших серверах

Шаг 1: Обновите PHP на серверах веб-приложений (единственное полное исправление)

  1. Обновите PHP на серверах, где работает ваше веб-приложение, до версии 8.2.35, 8.3.36, 8.4.27 или 8.5.12 либо установите исправленный пакет вашего дистрибутива Linux. Пакеты дистрибутивов часто сохраняют старый номер версии; проверьте наличие номеров CVE в журнале изменений пакета.
  2. Перезапустите все рабочие процессы PHP (пулы PHP-FPM, Apache, LiteSpeed, долгоживущие рабочие процессы). Запущенные процессы продолжают использовать старый код до перезапуска.
  3. Пересоберите образы контейнеров, содержащие собственный PHP. Обновление хоста не обновляет PHP внутри образа.
  4. PHP 8.1 и более ранние версии больше не получают обновлений от проекта PHP. Запланируйте переход на поддерживаемую ветку.

Шаг 2: Временные настройки PHP на серверах веб-приложений (если вы не можете выполнить обновление сегодня)

Эти настройки задаются в конфигурации PHP на сервере, где работает ваше веб-приложение (php.ini или настройки пула PHP-FPM). Эти меры перечислены PHP Security Team. Они снижают подверженность определённым путям атаки, но не делают установку безопасной.

ПараметрНазначение
session.upload_progress.enabled = 0Устраняет путь атаки CVE-2026-109619 через session upload progress. Перезапустите все рабочие процессы. PHP Security Team рекомендует оставить параметр отключённым и после установки исправлений, если эта функция вам не нужна.
fatal_error_backtraces = 0 (PHP 8.5)Устраняет путь атаки через трассировку стека при фатальной ошибке
post_max_size = 8M (без загрузок) или 32M (с загрузками), при меньшем значении upload_max_filesizeУменьшает объём памяти, который злоумышленник может заставить PHP использовать
memory_limit = -1, заданный через php_admin_valueУстраняет управляемый сбой при достижении лимита памяти. При этом один запрос может занять всю память сервера; используйте ограничения контейнера или cgroup, но никогда RLIMIT_AS или RLIMIT_DATA

В TR7 WAF-WAAP

Если вы можете обновить PHP сразу, это и есть настоящее исправление. Если не можете, то до завершения обновления вы можете защитить свои PHP-приложения от этих атак с помощью настроек безопасности, уже доступных в TR7 WAF-WAAP, без какого-либо обновления TR7. Три настройки из шага 1 составляют основную защиту; дополнительные меры из шага 2 ещё больше сужают поверхность атаки, поэтому выберите те, которые подходят вашему приложению. Применяйте настройки для каждого vService отдельно и сначала опробуйте их на непродуктивном vService.

Шаг 1: Основная защита

1.1 Переведите WAF в режим Blocking mode

WAF, который только ведёт мониторинг, не останавливает атаку. При первом включении WAF запускается в режиме Learning mode; Monitor mode только ведёт запись. Для каждого vService с PHP откройте экран WAF Mode и убедитесь, что WAF находится в режиме Blocking mode.

Внимание: Перед переключением проверьте исключения сигнатур, полученные в режиме обучения для каждого поля. Если число исключений для поля превышает значение Max. owasp exclusions, проверка сигнатур для этого поля отключается.

1.2 Добавьте два пользовательских правила

На экране Signature & Rule Library (WAF → Signature & Rule Library → Add) добавьте два приведённых ниже правила по отдельности. Запустите оба в состоянии Monitor и переведите их в состояние Enabled после просмотра Event Logs. Правила применяются ко всем vService, защищённым WAF.

Правило 1: поле session upload progress

  • Pattern (Regex): PHP_SESSION_UPLOAD_PROGRESS
  • Inspection Scopes: Form и Raw
  • Score: Very High

Перехватывает поле формы, которое активирует путь атаки CVE-2026-109619 через session upload progress. Для приложений, легитимно использующих эту функцию, исключите только те пути загрузки, которым она нужна.

Правило 2: поле формы PHPSESSID

  • Pattern (Regex): ^PHPSESSID$
  • Inspection Scopes: Form
  • Score: Very High

Перехватывает запросы, передающие идентификатор сеанса в поле формы с именем PHPSESSID вместо cookie; некоторые пути атаки используют этот вариант, а в легитимном трафике он встречается редко. Если ваше приложение использует другое имя сеанса (session.name), укажите это имя.

Чтобы правила работали: Правила проверяются в рамках проверок Form и RAW того типа страницы, которому соответствует запрос. В типе страницы без проверки Form тела форм и загрузок файлов не сканируются.

  • Оставьте OWASP check включённым в правиле Any Paths и в типах страниц, имеющих собственную проверку Form или RAW.
  • Добавьте собственную проверку Form и RAW в каждый тип страницы glob с помощью кнопок Add common rule for Form и Add common rule for Raw; не полагайтесь на унаследованные настройки.
1.3 Блокируйте большие и непроверяемые тела запросов

На экране WAF Rules задайте два параметра в проверке RAW:

  1. Установите для Raw Body Size максимальный размер тела, необходимый для данного пути (в байтах; например, 8388608 = 8 МБ на путях без загрузок, 33554432 = 32 МБ на путях загрузки). Диапазон по умолчанию допускает тела размером до 256 МБ.
  2. Переключите параметр неразобранного тела с Allow unparsed body на Block unparsed body. В противном случае тело, которое не помещается в буфер проверки, передаётся в Backend Service без какой-либо проверки содержимого.

Где? WAF проверяет запрос только с настройками того типа страницы, которому соответствует его путь. Задайте эти два параметра в правиле Any Paths, в каждом типе страницы, у которого в столбце Check Fields отображается Raw, и в каждом типе страницы glob; если у типа страницы glob нет проверки RAW, сначала добавьте её с помощью Add common rule for Raw.

Внимание: Raw Body Size действует, когда на экране Checks включён параметр Structure Checks. Сначала протестируйте легитимные загрузки больших файлов. Тела, отправленные без объявленной длины, этим ограничением не измеряются; на путях вне путей загрузки их можно заблокировать согласно п. 2.1.

Шаг 2: Дополнительные меры

Эти меры дополняют основную защиту; выберите те, которые подходят вашему приложению.

2.1 Заблокируйте загрузку файлов там, где она не нужна

Запросы атаки в основном являются запросами multipart/form-data (загрузка файлов). Если файлы принимают лишь несколько путей вашего приложения, заблокируйте multipart-запросы ко всем остальным путям с помощью правила балансировщика нагрузки. Правило состоит из двух условий и действия Block. Все экраны доступны из меню Configuration Menu, которое открывается логотипом TR7 в левом нижнем углу.

A. Создайте условия (Load Balancer → Conditions → Add)

  1. Условие multipart-запроса: Criteria = HTTP header, метод сопоставления Includes, Header Name = Request → Content-Type, Query = multipart/form-data, Case Insensitive включено. Введите Condition Name, например multipart-request, и сохраните кнопкой Add.
  2. Условие путей загрузки: Criteria = Path, метод сопоставления Regex, а в поле Query укажите пути, принимающие файлы (например, ^/(upload|media/upload)). Введите Condition Name, например upload-paths, и сохраните кнопкой Add.

B. Создайте действие Block (Load Balancer → Actions → Add)

  1. Введите Action Name (например, block-multipart), Action Type = Block, Execution Level = On Request, Deny Type = Standard, Status Code = 403.
  2. В поле Conditions выберите multipart-request и !upload-paths в одной группе условий (по умолчанию and). Каждое условие отображается в списке дважды: само условие и его отрицание (NOT), начинающееся с !; !upload-paths означает «не является одним из путей загрузки».
  3. Включите Hit Counter, чтобы подсчитывать заблокированные запросы, и сохраните кнопкой Add.

C. Добавьте действие в vService

  1. На экране Load Balancer → Load Balancer vService List выберите vService и нажмите Edit, выберите действие в поле Actions в разделе Details и нажмите Save.

D. Также заблокируйте тела, отправленные без объявленной длины

  1. Создайте ещё одно условие HTTP header: метод сопоставления Is present, Header Name = Request → Content-Length, Condition Name, например has-length.
  2. Создайте второе действие Block (On Request, Standard, 403). В поле Conditions выберите предопределённое условие If HTTP method is POST, !has-length и !upload-paths в одной группе условий и добавьте действие в поле Actions vService. Условие POST обязательно; без него будут блокироваться и GET-запросы без тела.

Ограничение размера из п. 1.3 не видит реальный размер тела, отправленного без объявленной длины. Это правило охватывает как потоковые (chunked) загрузки HTTP/1.1, так и тела HTTP/2 без объявленной длины на путях вне путей загрузки. Под это правило также попадают POST-запросы без тела и без заголовка Content-Length; сначала опробуйте его на непродуктивном vService.

Проверка: Multipart-запрос (curl -s -o /dev/null -w '%{http_code}\n' -F 'a=b' https://www.example.com/), chunked-запрос HTTP/1.1 (curl -s -o /dev/null -w '%{http_code}\n' --http1.1 -H 'Transfer-Encoding: chunked' -d 'a=b' https://www.example.com/) и запрос HTTP/2 без объявленной длины (printf 'a=b' | curl -s -o /dev/null -w '%{http_code}\n' --http2 -X POST -T - https://www.example.com/) к пути вне путей загрузки должны получить ответ 403, а запросы к вашим путям загрузки должны проходить. Для теста HTTP/1.1 параметр --http1.1 обязателен: curl по умолчанию использует HTTP/2 через https и не отправляет Transfer-Encoding по HTTP/2. Счётчик отображается на вкладке Action Hits панели мониторинга vService.

Внимание: Действие Block без выбранного условия применяется ко всем запросам к vService. Перечислите все пути загрузки полностью и сначала опробуйте правило на непродуктивном vService.

2.2 Ограничьте число POST-запросов от одного клиента

Это правило не остановит целенаправленную атаку: эксплойту может хватить нескольких запросов. Однако оно повышает затраты для автоматизированных инструментов, перебирающих множество целей. Правило подсчитывает POST-запросы с каждого IP-адреса клиента и блокирует POST-запросы клиента, превысившего порог, с кодом 429. Блокировка снимается автоматически, когда счётчик опускается ниже порога.

A. Создайте действие-счётчик (Load Balancer → Actions → Add)

  1. Введите Action Name, Action Type = Advanced Traffic Inspection, Fields to Track = Client IP address, Traffic Tag = например post-rate (3-20 символов; буквы, цифры, -, _), Tracking Period = 1 минута.
  2. В поле Conditions выберите предопределённое условие If HTTP method is POST и сохраните кнопкой Add. Тогда учитываются только POST-запросы.

B. Создайте пороговое условие (Load Balancer → Conditions → Add)

  1. Criteria = Tracking Condition, Tracked Table = post-rate, Tracking Criteria = HTTP requests, а порог задайте с помощью Tracking Operator (например, > 100). Сохраните кнопкой Add.

C. Создайте действие Block (Load Balancer → Actions → Add)

  1. Action Type = Block, Execution Level = On Request, Deny Type = Standard, Status Code = 429.
  2. В поле Conditions выберите пороговое условие из шага 3 и If HTTP method is POST в одной группе условий (по умолчанию and). Без условия POST будут блокироваться и GET-запросы клиента, превысившего порог. Сохраните кнопкой Add.

D. Добавьте действия в vService

  1. В форме Edit vService в разделе Details → Actions выберите действие-счётчик первым, а действие Block вторым и нажмите Save. Действия выполняются в порядке списка.

Проверка: На вкладке Logs & Tracking vService выберите в списке Logs Type таблицу отслеживания действия-счётчика; отображаются счётчики POST-запросов по каждому клиенту. Порог задавайте исходя из нормального трафика вашего приложения: наблюдайте в таблице число POST-запросов в минуту от легитимных клиентов (например, систем, использующих API, или организаций за общим исходящим IP-адресом) и установите порог выше этих значений.

2.3 Переведите защиту L7 DDoS в режим Active

Если защита Bot/DDoS входит в вашу лицензию, функция Source IP Request Protection в разделе L7 DDoS Protection ограничивает общее число запросов, которые один исходный адрес может отправить за определённый период. В отличие от п. 2.2, она учитывает все запросы и не требует дополнительного правила.

  1. В форме Edit vService выберите L7 DDoS & Threat Protection в разделе Details и нажмите Save (если функция не включена). После включения защиты L7 DDoS Protection запускается в режиме Monitor; в этом режиме нарушения лимитов только регистрируются как события.
  2. В разделе Left Monitor Panel → Bot/DDoS Protected vServices → vService → Bot/DDoS Management нажмите ссылку Edit на карточке L7 DDoS Protection.
  3. Установите DDoS Protection = Active и сохраните кнопкой Edit.
  4. На карточке нажмите значок карандаша в блоке Source IP Request Protection. Задайте Time Window (по умолчанию 10 seconds), Request Limit (по умолчанию 1000) и Limit Action (по умолчанию Show Captcha; также можно выбрать Block) в соответствии с трафиком вашего приложения и сохраните кнопкой Edit.

Внимание: Перед переключением в Active некоторое время наблюдайте за событиями в режиме Monitor. Повторите такое же наблюдение при снижении Request Limit.

Проверьте, не были ли вы целью атаки

См. раздел Обнаружение и мониторинг. Сообщения о попытках эксплуатации поступали ещё до публичного раскрытия информации, поэтому проверьте журналы начиная с 17 октября 2026 г.

Что WAF может и чего не может

WAF можетWAF не может
Блокировать известные формы запросов, например поле session upload progressИсправить уязвимый код внутри PHP
Ограничивать размер тела запроса, пути загрузки и частоту запросовИзмерять потребление памяти внутри процесса PHP
Блокировать загрузки на путях, где они не нужныВидеть запросы, которые достигают вашего сервера, минуя его
Регистрировать заблокированные запросы и запросы, ограниченные по частотеОтменить действие кода, который уже выполнился на сервере

Правила WAF дают выиграть время для обновления; долговременным исправлением является обновление PHP. Чтобы эти меры защиты работали, весь трафик к вашим PHP-приложениям должен проходить через TR7 WAF-WAAP.

Обнаружение и мониторинг

В TR7

  • На экране Event Logs каждого vService, защищённого WAF, отфильтруйте записи по своим пользовательским правилам и посмотрите на совпавшее поле и балл.
  • На том же экране просмотрите запросы, заблокированные правилами размера тела и неразобранного тела.
  • Если вы применили дополнительные меры, отслеживайте счётчики правил балансировщика нагрузки на вкладке Action Hits панели мониторинга vService, а клиентов, достигших лимита частоты POST-запросов, в таблице отслеживания на вкладке Logs & Tracking.

На ваших серверах

  • Ищите в журналах ошибок PHP такие ошибки, как Allowed memory size ... exhausted, сбои рабочих процессов и повторяющиеся ответы HTTP 500; обращайте внимание на те, что возникают сразу после крупных запросов multipart/form-data.
  • Проверяйте ответы на наличие необычно больших или некорректных cookie PHPSESSID.
  • Проверяйте корневые каталоги веб-сервера на наличие новых или изменённых файлов, а также ищите неожиданные процессы, запущенные от имени пользователя веб-сервера, новые задания cron и неожиданные исходящие соединения.

Часто задаваемые вопросы

Нет. В устройствах TR7 нет компонента PHP, обрабатывающего HTTP-запросы, поэтому эти уязвимости не затрагивают продукты TR7. См. раздел «Затронут ли TR7?».

Ни один WAF не может обеспечить полную защиту от этих уязвимостей. TR7 WAF-WAAP сокращает поверхность атаки и блокирует известные пути атаки; единственное полное исправление состоит в обновлении PHP.

Используйте против PHP2Shell два пользовательских правила из п. 1.2 раздела о TR7 WAF-WAAP; они сразу применяются ко всем vService, защищённым WAF.

Нет. Уязвимости находятся в среде выполнения PHP. Обновите сам PHP или попросите об этом своего хостинг-провайдера.

Могут. Ограничения размера тела запроса, блокировка загрузок и пользовательские правила могут затронуть легитимные загрузки и формы. Для правил WAF начните в режиме Monitor mode, просмотрите Event Logs, затем переключитесь в Blocking mode. Правила балансировщика нагрузки (2.1, 2.2) сначала опробуйте на непродуктивном vService.

История обновлений

  • 23 октября 2026 г. Первоначальная публикация.

Источники

Нужна помощь с применением этих настроек?

Команда поддержки TR7 может проверить конфигурацию вашего WAF и помочь развернуть эти меры защиты. Обратитесь к своему представителю TR7 или в команду поддержки TR7 по адресу support@tr7.com.

Подробнее о TR7 WAF-WAAP Связаться с TR7 Экстренная поддержка