---
title: "PHP2Shell: причины и руководство по устранению"
description: "Узнайте об ошибках жизненного цикла PHP2Shell, обновлениях среды выполнения, временных средствах устранения проблем, выборе исправлений и проверке с помощью активного пути запроса Web."
language: "ru"
url: "https://keendigit.com/ru/insights/php2shell-remediation-guide"
author: "KeenDigit"
published: "2026-10-22"
---

# PHP2Shell: причины и руководство по устранению

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

**Источники проверены по состоянию на 22 октября 2026 г.** **Аудитория: PHP операторы приложений, специалисты по обеспечению безопасности и инженеры, поддерживающие пользовательские сборки PHP.**

В этой статье кратко описаны причина, масштаб воздействия, формальный процесс восстановления, временные меры по устранению и официальное исправление уязвимости PHP2Shell. Основной текст цитируется с использованием таких номеров, как [S1](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-1); все ссылки на источники указаны в приложении в конце текста. Фрагмент конфигурации представляет собой шаблон развертывания, который необходимо настроить в зависимости от фактической версии, возможностей бизнеса и отношений наследования конфигурации.

## TL;DR: Этапы ремонта и рекомендации

1. **Обновите среду выполнения PHP**: обновите соответствующую ветку как минимум до **8.2.35, 8.3.36, 8.4.27 или 8.5.12**. Для пакетов распространения используйте полную версию пакета, которая, как подтверждает поставщик, исправляет оба CVE. [S1](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-1)[S10](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-10)
2. **Замените все старые процессы**: перезапустите или перезапустите каждый PHP worker, службу хостинга и контейнер после обновления и подтвердите, что старые экземпляры завершились.
3. **Проверьте фактический путь запроса Web**: проверьте Web SAPI, полную версию пакета и работающий экземпляр. Проверка `php -v` сама по себе не означает, что действующая служба исправлена.
4. **Запустите регрессионную проверку бизнеса и восстановите нормальный бюджет ресурсов.**: проверьте вход в систему, обработку сеансов, загрузку, импорт и обработку ошибок. Если ограничение памяти PHP было временно удалено, восстановите соответствующий конечный бюджет после исправления.
5. **Если немедленное обновление невозможно.**: ограничьте ненадежный трафик до того, как он достигнет PHP. Оцените отключение процесса загрузки и фатальные обратные трассировки PHP 8.5, как описано в разделе 5. Меры по устранению последствий конфигурации и правила WAF имеют ограниченный охват и не могут заменить обновление. [S1](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-3)

## 1. Обзор уязвимостей и оценка рисков

PHP2Shell в этой статье относится к двум уязвимостям уровня Critical, официально раскрытым PHP 21 октября 2026 года. Обе связаны с памятью и управлением жизненным циклом запросов ядра PHP, что создает риск удаленного выполнения кода без аутентификации. [S1](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-3)

| Проект                                | CVE-2026-109618                                                                                                | CVE-2026-109619                                                                                   |
| ------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| официальное название                  | RCE via OOM corruption                                                                                         | RCE via stale global state                                                                        |
| основные проблемы                     | Недостаток памяти вызывает ненормальный переход, оставляя состояние, в котором инициализация еще не завершена. | Глобальное состояние, остающееся в рабочем состоянии, указывает на освобожденную память запросов. |
| Типичное время возникновения          | Процесс инициализации, выполнения или очистки текущего запроса.                                                | Предыдущий запрос покидает статус, а последующие запросы потребляют его заранее.                  |
| Является ли OOM необходимым условием? | Относится к основному механизму срабатывания уязвимости.                                                       | Нет; также могут быть задействованы другие фатальные ошибки и очистка после диагностики.          |
| Направление фундаментального ремонта  | Безопасная обработка сбоев распределения и завершения запросов                                                 | Исправлена государственная собственность, время очистки и ранняя инициализация.                   |
| Требования к утилизации               | должен быть отремонтирован                                                                                     | надо ремонтировать одновременно                                                                   |

Основание: два официальных бюллетеня по безопасности и исправления. [S2](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-3)[S4](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-4)

### 1.1 Общие сведения о затронутых развертываниях

PHP официально считает **all PHP, обрабатывающим запросы Web**, подверженными риску, включая PHP-FPM, Apache mod\_php, php-cgi, FrankenPHP и LiteSpeed. Продемонстрированная атака mod\_php может произойти до запуска кода приложения, поэтому проверки входа в систему, промежуточное ПО платформы и проверка загрузки приложения не могут охватить этот путь. [S1](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-1)

Необходимо различать «развертывание необходимо исправить» и «определенная цепочка атак полностью доказана». Объявление CVE-2026-109618: FPM выйдет из дочернего процесса после сбоя запуска запроса, блокируя соответствующий путь очистки mod\_php после сбоя запуска; однако путь OOM после успешного запуска все еще находится под угрозой. В объявлении также отмечается, что полный эксплойт FPM для этого CVE еще не был продемонстрирован. Это ограничение не может использоваться для вывода о том, что FPM безопасен, особенно CVE-2026-109619 нельзя игнорировать. [S2](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-3)

Непосредственные границы разрешений для успешной эксплуатации зависят от личности процесса, на котором размещен PHP, и ресурсов, к которым он имеет доступ. Как правило, внимание следует уделять коду веб-сайта, каталогу загрузки, учетным данным базы данных, токенам обслуживания и возможностям доступа к внутренней сети; «удаленное выполнение кода» не означает естественное получение root-прав. Решение о последствиях здесь основано на модели разрешений процесса, а фактическое влияние необходимо оценивать в сочетании с разрешениями на развертывание.

Обычные одноразовые сценарии CLI не имеют одинаковой записи HTTP; но процессы, которые в течение длительного времени обрабатывают внешние задачи в CLI или встроенном режиме, все равно должны быть включены в инвентаризацию среды выполнения и жизненного цикла. Обновляются только зависимости CMS, framework или Composer, а базовый движок PHP не заменяется автоматически.

## 2. Анализ причин

### 2.1 Сначала разберитесь в двух жизненных циклах.

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

Следовательно, движок должен поддерживать два ограничения:

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

Эти два ограничения соответствуют основным режимам сбоя двух групп уязвимостей. Следующий процесс представляет собой описание механизма, объединяющего объявления и компиляцию исправлений. Это не означает, что каждое развертывание имеет один и тот же доступный путь. [S2](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-3)[S5](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-5)

### 2.2 CVE-2026-109618: OOM прервал незавершенное обновление статуса.

Старая реализация использует нелокальный переход типа `longjmp()` для обработки OOM, а соответствующий путь выходит из текущего контекста выполнения через `zend_bailout()`. Опасность заключается в том, что часть кода C могла опубликовать новый объект, массив или статус запроса для другого кода, но еще не завершила всю инициализацию полей; в настоящее время любой сбой распределения в соответствующий момент времени может привести к пропуску обычных шагов закрытия. [S2](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-2)

Процесс отказа можно разбить на четыре этапа:

1. Создайте или обновите внутреннюю структуру запроса и сделайте ее доступной.
2. Последующее выделение памяти завершается сбоем и срабатывает OOM.
3. Поток выполнения переходит от текущей функции, и код, первоначально использовавшийся для завершения инициализации или восстановления состояния, не выполняется.
4. Очистка запроса продолжает обработку этих структур и рассматривает недопустимое содержимое как допустимые поля или адреса.

Проблема не в том, что нехватка памяти всегда вызывает RCE. Скорее, исчерпание памяти **изменяет поток управления и нарушает предположения движка о допустимых структурах**. Неудачное распределение не обязательно должно напрямую затрагивать структуру, которая в конечном итоге будет прочитана неправильно. [S2](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-2)

#### Почему запросы меньшего размера также могут исчерпать память

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

Проблемы с multipart, перечисленные в официальном объявлении, включают в себя: пробел в проверке начального размера, когда доступная длина объявления отсутствует, количество заголовков для одной части недостаточно ограничено, а пустые элементы управления файлами по-прежнему создают метаданные, а вложенные имена еще больше увеличивают рабочую нагрузку на массив. Собственная раскрутка, декодирование или переназначение ввода приложения также может быть источником OOM. [S2](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-2)

Из этого можно сделать два защитных вывода:

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

#### Почему аутентификация приложения может быть слишком запоздалой

В mod\_php тело запроса может автоматически анализироваться на этапе инициализации запроса; даже если запуск завершится неудачно, очистка связанного запроса все равно будет выполнена. Таким образом, подтвержденные пути атаки могут возникать до кода приложения. Чтобы уменьшить риск на этом этапе, необходимо установить ограничения на обратный прокси-сервер, сервер Web или другую границу, которая предшествует обработке запроса PHP. [S1](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-2)

### 2.3 CVE-2026-109619: память запросов освобождена, глобальная ссылка все еще жива.

Эта проблема связана со статусом ошибки, сеанса, объекта или расширения: поле хранится в рабочем месте долгосрочного доступа, но данные, на которые ссылается это поле, принадлежат одному запросу. Пока ссылка не будет должным образом очищена перед освобождением кучи запросов, последующие запросы могут столкнуться с зависающим состоянием, образуя использование после освобождения. [S3](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-3)

Официальный анализ делит условия эксплуатации на «производителей» и «потребителей»:

| роль или состояние                | смысл                                                                                                                                   | Последствия для защиты                                                                     |
| --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| государственный продюсер          | Поместите состояние, принадлежащее этому запросу, в место, к которому можно будет получить доступ позже.                                | Чтобы проверить, завершена ли соответствующая очистка после аварийного выхода              |
| Статус остается                   | Он не был очищен или был очищен, а затем снова заполнен в результате поздней операции.                                                  | Простой однократной очистки на более раннем этапе выключения может оказаться недостаточно. |
| повторное использование работника | Тот же работник продолжает обрабатывать последующие запросы                                                                             | Несколько рабочих — это просто разница в планировании, а не гарантия безопасности памяти.  |
| продвинутый потребитель           | Считайте, освободите или определите остаточное значение до того, как соответствующее состояние будет инициализировано в обычном режиме. | Перед инициализацией необходимо проверить INI, сеанс и другие пути.                        |

Эти условия необходимо соблюдать в совокупности; любой журнал ошибок сам по себе не доказывает, что уязвимость была успешно использована. [S3](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-3)

#### OOM не требуется в качестве обязательного условия.

Фатальные ошибки могут прервать публикацию и восстановление парного состояния. Сбои компиляции или синтаксического анализа, неперехваченные ошибки, сбои `require` и тайм-ауты выполнения могут оставить определенные состояния позади. Нефатальная диагностика на поздних стадиях очистки также может повторно заполнить информацию об ошибках, которая уже была удалена. [S3](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-3)

Таким образом, изменение `memory_limit` на неограниченный не закрывает этот набор уязвимостей.

#### «Перед инициализацией» нужно рассматривать отдельно.

Сроки появления двух типов подтвержденных потребителей различны:

- **Ранняя диагностика INI**: Некоторые конфигурации, применяемые по запросу, выдают предупреждение, уведомление или прекращение поддержки до нормальной инициализации исполнителя, а диагностическая обработка может получить доступ к старому состоянию ошибки.
- **Ход загрузки сеанса**: сеанс может быть обработан заранее в процессе разбора тела запроса, но обычный модуль `RINIT` еще не завершен; нельзя сделать вывод, что путь не существует, поскольку приложение не вызывает явно `session_start()`. [S3](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-3)

Не все конфигурации INI имеют одинаковое время возникновения риска. Конфигурацию уровня каталога mod\_php и `PHP_VALUE`/`PHP_ADMIN_VALUE`, передаваемую внешним интерфейсом FPM, следует отличать от обычной стартовой конфигурации `php.ini`, FPM pool и FPM `.user.ini`. Последние имеют разное время настройки и не могут вместе называться одними и теми же ранними потребителями. [S3](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-3)

Отключение `display_errors`, `log_errors`, уменьшение `error_reporting` или использование `@` влияет только на видимость диагностики; к соответствующему внутреннему состоянию можно было получить доступ до принятия решения о выводе журнала. [S3](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-3)

## 3. Ремонт версии и выбор патча

### 3.1 Официальное базовое исправление исходной ветки

| Текущая ветка PHP         | Первая версия, включающая это официальное исправление. | Предложения                                                                                                                     |
| ------------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
| 8.2                       | 8.2.35                                                 | Обновите эту версию или последующую версию, содержащую те же исправления.                                                       |
| 8.3                       | 8.3.36                                                 | То же, что и выше                                                                                                               |
| 8.4                       | 8.4.27                                                 | То же, что и выше                                                                                                               |
| 8.5                       | 8.5.12                                                 | То же, что и выше                                                                                                               |
| 8.1 и более ранние версии | Общая поддержка разведки и добычи закончилась          | Расставить приоритеты миграции в поддерживаемые филиалы; краткосрочный контрольный выпуск или резервная копия производителя LTS |

Версия и статус поддержки основаны на официальном объявлении PHP, а базовая дата — 22 октября 2026 г. [S1](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-1).

Это **пороговые значения исправлений для конкретных ветвей**. Их нельзя заменить заявлением о том, что каждая версия ниже 8.5.12 уязвима: такие версии, как 8.2.35 и 8.4.27 в других ветках, уже содержат исправления.

### 3.2 Проверьте полную версию дистрибутива.

Дистрибутивы часто добавляют исправления безопасности на основе более старых версий. При приемке также следует проверить версию выпуска, источник репозитория, полную версию пакета и бюллетень безопасности.

Например, версия пакета исправлений Ubuntu 24.04 LTS, указанная для Ubuntu USN-8948-1:

```text
8.3.6-0ubuntu0.24.04.13
```

Его основной частью по-прежнему является `8.3.6`, но полная версия этого дистрибутива включена в это объявление об исправлении. Этот вывод применим только к соответствующему дистрибутиву и источнику пакета и не может быть распространен на любую сборку, которая также отображает `8.3.6`. [S10](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-10)

### 3.3 Выбор правильного патча

| сцена                                                        | Приоритетный план                                                                                                     | Ключевые моменты для принятия                                                                |
| ------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| Использование дистрибутива пакета PHP                        | Установите обновления безопасности, выпущенные производителем.                                                        | Объявление охватывает как CVE; полная версия пакета верна                                    |
| Используйте официальный контейнер PHP или собственный образ. | Обновите базовую среду выполнения, перестройте и разверните                                                           | Запущенный экземпляр использует новый образ; все старые копии закрываются                    |
| Самокомпилируемые поддерживаемые ветки                       | Используйте официальную версию безопасности этой ветки или полный официальный набор патчей.                           | Сопоставление ветвей, завершение зависимостей, совместимость расширений и передача регрессии |
| В зависимости от 7.4, 8.0, 8.1                               | Приоритизация поддержки поставщиков; при необходимости оценить официальную ветку исходного кода чрезвычайной ситуации | Выявляйте изменения в поведении и планируйте переход на поддерживаемые версии.               |

Официальные патчи были выпущены, и реальные исправления должны начинаться с этих патчей. Фрагменты кода в разделе 6 предназначены для иллюстрации основных моментов проектирования и проверки и не представляют собой законченное исправление, которое можно применять независимо. [S1](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-1)[S4](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-4)[S6](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-6)

## 4. Формальный процесс ремонта

### 4.1 Инвентаризация среды выполнения, которая фактически обрабатывает запросы.

Рекомендуется сформировать краткий регистр, в котором будет фиксироваться как минимум:

- Введите доменное имя или службу, обратный прокси-сервер, PHP SAPI.
- Ветка PHP, полная версия пакета или дайджест образа, исходный код сборки.
- FPM pool, фактическая сервисная единица, контейнер или Pod, количество реплик.
- Расширения, основная конфигурация и дополнительные файлы конфигурации загружены.
- Существуют ли другие версии PHP, старые копии развертывания или исходные порталы, к которым можно получить прямой доступ?

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

### 4.2 Выберите и разверните правильное обновление.

Подтвердите версию исправления согласно разделу 3, предпочтительно используя существующий доверенный источник пакета или контролируемую цепочку сборки. Область обновления должна включать компонент, который фактически содержит запрос, например пакет FPM, модуль Apache PHP, двоичный файл CGI или сборку службы, в которую встроен PHP.

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

### 4.3 Перезапустите или перезапустите работающие экземпляры.

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

Для mod\_php перезапустите процесс Apache, в котором размещен модуль. Службы, встраивающие PHP, требуют замены процесса хостинга. Для FPM очистка OPcache не заменяет обновление среды выполнения и удаление старых рабочих процессов.

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

### 4.4 Проверка с помощью реальных запросов Web

Рекомендуется объединить следующие доказательства, а не полагаться исключительно на одну команду версии:

| доказательства                                                          | Что можно доказать                            | Не могу ничего доказать в одиночку            |
| ----------------------------------------------------------------------- | --------------------------------------------- | --------------------------------------------- |
| Менеджер пакетов или метаданные изображения                             | Исходники установки и полные сборки           | Трафик переключен на этот экземпляр           |
| Статус процесса и развертывания                                         | рабочий или контейнер завершает замену        | К нему должен быть подведен внешний вход.     |
| Ограниченный доступ к диагностическим результатам через реальный портал | Актуальный Web SAPI и рабочая конфигурация    | Охватывает ли резервная копия выпуска два CVE |
| Объявление поставщика или полная запись исправлений                     | Это исправление ошибки включено в эту сборку. | Все реплики развернуты                        |

`PHP_VERSION`, `PHP_SAPI`, загруженные файлы конфигурации и аварийные конфигурации можно проверить с помощью существующих внутренних диагностических возможностей или временных диагностических порталов с контролируемым доступом. Убедитесь, что запрос не возвращается напрямую CDN или кэшем страниц; удалите временную диагностическую запись после завершения.

`php -v` обычно указывает только двоичный файл CLI, выбранный в данный момент оболочкой; такие команды, как `php-fpm -i`, не эквивалентны проверке существующего рабочего процесса, получающего трафик. Не размещайте полную страницу `phpinfo()` в общедоступной сети в течение длительного времени.

### 4.5 Регрессионные проверки бизнеса и удаление аварийных настроек

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

Если `memory_limit=-1` установлен временно, ограниченный бюджет, соответствующий возможностям бизнеса, будет восстановлен после вступления в силу официального обновления; если установлен `pm.max_requests=1`, конфигурация жизненного цикла с оценкой мощности будет восстановлена ​​после подтверждения ремонта. Ограничения на размер входных данных и контроль доступа к источникам могут быть сохранены в соответствии с потребностями бизнеса.

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

## 5. Меры по смягчению последствий, когда немедленная модернизация невозможна.

Этот раздел предназначен для краткосрочного снижения воздействия или повышения доступности. Каждая мера охватывает только определенный путь, и комбинация нескольких мер не эквивалентна полному ремонту. [S1](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-3)

### 5.1 Установите приоритет управления дорожным движением перед PHP

Если служба это позволяет, временно ограничьте конфиденциальные конечные точки доверенными источниками или включите контроль доступа до PHP. Для рабочих нагрузок отправки ограничьте размер тела запроса, количество полей, количество частей, заголовки на каждую часть и глубину вложенности. Службы, которым не требуется multipart, могут отклонить его на внешнем интерфейсе. [S2](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-2)

Эти ограничения распространяются на все входы в PHP. Только перехват URL с именем «upload» приведет к пропуску других записей, которые все еще автоматически анализируются PHP в теле запроса. В таких случаях, как передача фрагментов, отсутствие доступной заявленной длины и т. д., ограничение должно основываться на фактическом размере чтения; приложение также должно иметь собственный бюджет размера вывода при повторном распаковке или расширении содержимого.

### 5.2 FPM pool Шаблон конфигурации

Поместите следующие настройки в раздел конфигурации **FPM pool, который фактически обслуживает запросы**, а не дословно в `php.ini`. Значения 8M и 4M являются примерами корректировки рабочей нагрузки. Оставьте место для полей формы и составных границ при ограничении всего запроса POST. [S11](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-12)

```ini
; Temporary mitigation: evaluate capacity before applying.
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off
```

Только **PHP 8.5**, плюс:

```ini
php_admin_flag[fatal_error_backtraces] = off
```

Функции и границы каждого из них следующие:

| Конфигурация                                   | ожидаемый эффект                                                                | Описание ограничений, которые необходимо сохранить                                                                                         |
| ---------------------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| `memory_limit=-1`                              | Удалите предсказуемое условие срабатывания верхнего предела памяти запроса PHP. | Это не предотвращает основной сбой распределения; отмена исходного бюджета может увеличить риск нехватки памяти и прерывания обслуживания. |
| Меньший `post_max_size`                        | Уменьшить размер данных, поступающих в процесс синтаксического анализа          | Нефиксированный парсер имеет известный пробел; усиление памяти невозможно предотвратить самостоятельно                                     |
| `upload_max_filesize < post_max_size`          | Ограничьте размер одного файла и зарезервируйте служебное пространство запроса. | Не ограничивает все поля, метаданные или выделения в приложении.                                                                           |
| Закрыть ход загрузки                           | Заблокировать подтвержденный путь, связанный с сеансом                          | Не распространяется на другие варианты глобального состояния.                                                                              |
| PHP 8.5 закрыть фатальную обратную трассировку | Блокировать подтвержденных производителей связанного статуса                    | Не охватывает другие пути, такие как сеанс                                                                                                 |

Границы мер взяты из официального объявления; синтаксис пула и семантику конфигурации уровня управления см. в руководстве PHP. [S1](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-11)

Настройки `php_admin_*` уровня управления не могут быть переопределены приложениями через `ini_set()`. Все входящие конфигурации пула, уровня каталога и внешнего интерфейса по-прежнему следует проверять, чтобы убедиться, что значения фактических запросов соответствуют ожиданиям. После внесения изменений перестройте всех рабочих, чтобы существующие процессы не сохраняли старое состояние.

Если вы решите изменить `php.ini` напрямую, синтаксис следует изменить на:

```ini
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = Off
```

В отличие от `php_admin_value` в пуле, простая установка `memory_limit=-1` в `php.ini` не мешает приложению снова его модифицировать. Следует проверить структуру, код приложения и другие конфигурации, чтобы убедиться, что они сбросили ограниченное значение; если требуется принудительное применение, используйте настройки уровня управления, соответствующие текущему SAPI, и проверьте фактическое действующее значение. [S11](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-12)

Добавьте `fatal_error_backtraces = Off` только для PHP 8.5. Не используйте `ini_set()` уровня приложения в качестве обходного пути для отключения процесса загрузки и не полагайтесь на FPM `.user.ini`, чтобы он вступил в силу перед анализом запроса. [S1](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-1)[S3](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-3)

### 5.3 Управляйте расходами на удаление ограничений памяти PHP

`memory_limit=-1` — это временное средство устранения проблем для незафиксированных сред, которое не следует копировать в качестве долгосрочной конфигурации по умолчанию. Когда приложение или запрос выходят из-под контроля, они могут использовать больше памяти хоста. Поэтому перед использованием следует оценить количество параллельных операций, пиковую нагрузку на одного работника и общую мощность службы, а также установить ограничения на входные данные переднего плана. [S2](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-2)

Ограничения памяти контейнера или контрольной группы могут обеспечивать границы доступности, но не гарантируют, что выделение никогда не будет неудачным; весь контейнер, мастер и все работники также могут быть прекращены при срабатывании ограничения. Степень детализации изоляции и стратегии завершения необходимо оценивать в сочетании с развертыванием, и их нельзя назвать полной защитой для этих двух CVE. [S2](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-2)

Не заменяйте вышеуказанные стратегии `RLIMIT_AS`, `RLIMIT_DATA` или соответствующими ограничениями адресного пространства процесса; они могут напрямую привести к сбою базового распределения на все еще проблематичном пути OOM. [S2](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-2)

### 5.4 Nginx Пример конфигурации

Применимо к развертыванию, в котором Nginx перенаправляет запросы на PHP-FPM. Его можно установить на уровне конфигурации фактического хостинга:

```nginx
client_max_body_size 8m;
fastcgi_request_buffering on;
```

`client_max_body_size` ограничивает размер тела запроса; `fastcgi_request_buffering on` позволяет Nginx сначала прочитать полное тело запроса, а затем отправить его на серверную часть FastCGI. Вступит ли он в силу в определенном `server` или `location`, необходимо проверить в сочетании с существующими отношениями наследования и покрытия. [S13](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-13)[S14](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-14)

**Только когда бизнесу не нужна multipart**, вы можете добавить правило отклонения к соответствующему служебному входу:

```nginx
if ($http_content_type ~* "multipart/form-data") {
    return 403;
}
```

Это простой шаблон ограничения входа с использованием `if` и `return`, а не общее правило фильтрации для уязвимостей парсера. Перед развертыванием проверьте синтаксис конфигурации и обычные запросы, а также проверьте, перенаправляет ли пользовательский `error_page` запросы 403 на PHP. Сопоставление строк не дает полных гарантий относительно всех различий синтаксического анализа. [S15](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-15)

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

### 5.5 Дополнительное смягчение: один запрос на каждого работника FPM.

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

```ini
pm.max_requests = 1
```

И перестроить существующий рабочий. Он блокирует описанную цепочку перекрестных запросов на уровне повторного использования работника, но увеличивает накладные расходы на создание и инициализацию процесса; в то же время он не может исправить один и тот же запрос OOM и проблемы очистки CVE-2026-109618. Если значение меньше, но больше 1, окно повторного использования запроса все равно существует. [S3](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-11)

### Ограничения покрытия 5.6 WAF и Cloudflare

Cloudflare объявил о мерах по развертыванию защиты от PHP2Shell, включая план Free. При использовании его услуг следует проверить, проходит ли реальный трафик через прокси, действуют ли правила защиты и можно ли напрямую обойти исходный сайт; для платных планов вам также необходимо проверить конфигурацию и исключения соответствующих управляемых правил. [S16](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-16)

Некоторые из обнаружений, описанных производителем, используют ответные сигналы, поэтому все средства защиты нельзя интерпретировать как «каждая атака блокируется до достижения PHP». WAF может помочь уменьшить воздействие и предоставить наблюдательную информацию, но постоянные обновления до PHP по-прежнему необходимы. [S16](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-16)

### 5.7 Почему общих мер недостаточно

| меры или суждения                                                   | недостатки                                                                                                                                             |
| ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Закрывать только `file_uploads`                                     | Невозможно охватить всю многочастную обработку и применить собственный путь OOM.                                                                       |
| Установка `enable_post_data_reading=Off`                            | Изменить поведение автоматического заполнения POST/FILES; тело запроса по-прежнему может быть прочитано приложением и может нарушить нормальную работу |
| Отключите отображение ошибок, зарегистрируйтесь или используйте `@` | Внутренняя диагностическая обработка все еще может получить доступ к состоянию висячего состояния.                                                     |
| Увеличить количество рабочих                                        | Не создавайте безопасный механизм очистки состояния и не исключайте повторное использование одного рабочего процесса.                                  |
| Настройте только `disable_functions` или `open_basedir`.            | Эти ограничения не устраняют повреждение памяти уровня механизма C.                                                                                    |
| Проверяйте версию или одну копию только один раз                    | Невозможно доказать, что все входы и запущенные экземпляры были заменены.                                                                              |
| Журналы исключений не видны                                         | Он не может доказать, что уязвимости не существует или что она не использовалась ранее.                                                                |

Среди них основу конфигурации и механизма уязвимостей PHP можно найти в [S2](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-3)[S12](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-12); Суждения о границах охвата, принятия и разрешений основаны на предложениях по реализации, выдвинутых этими механизмами.

## 6. Идеи реализации и обзорные моменты официального патча

### 6.1 Использовать полные исправления для правильной ветки.

Представительное официальное представление для PHP 8.5:

```text
31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout
```

Коммит явно связывает два CVE, как для настройки механизма выхода OOM, так и для фиксации глобального состояния, к которому можно получить доступ на этапе инициализации. Отправьте страницу с полным описанием различий, см. [S4](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-5). Другие ветки должны использовать свои собственные официальные выпуски безопасности или соответствующие исправления, и нельзя предполагать, что изменения в 8.5 могут быть напрямую применены к любой более старой версии.

### 6.2 OOM Восстановление: сначала восстановите обрабатываемое состояние, а затем завершите запрос.

Формальная реализация вводит два уровня мягкой и жесткой обработки OOM: при достижении мягкого предела записывается состояние ожидания и выполняется контролируемый выход в безопасном месте, таком как VM; интерфейс отказоустойчивого распределения позволяет вызывающему объекту явно обработать сбой. Для выделений, которые не могут напрямую возвращать сбой, если ожидается превышение более высокого жесткого порога, процесс будет немедленно прекращен, чтобы избежать продолжения обработки запросов в небезопасном промежуточном состоянии. [S2](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-2)[S5](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-5)

Ниже приведен фрагмент кода ключа в файле diff 8.5, который используется для обозначения ожидающего OOM:

```c
EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);
```

Обработка прерываний VM и другие безопасные места впоследствии вызывают `zend_handle_delayed_oom()`. В контексте выполнения пользовательского кода используется контролируемый путь развертывания; жесткий путь OOM вызывает `_exit(137)`. [S5](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-5)

С точки зрения проектирования важными изменениями являются: **избегает произвольного пересечения стека вызовов C, когда структура находится в промежуточном состоянии, и помещает выход в местоположение**, которое может поддерживать ограничения состояния. После срабатывания мягкого ограничения для завершения процесса может потребоваться дополнительная память, поэтому новый мягкий порог нельзя понимать как абсолютный верхний предел общего объема памяти процесса.

Это также нельзя резюмировать как «PHP удалил все `zend_bailout()`». Патч по-прежнему использует соответствующие механизмы в определенных контекстах; фиксировано только время опасного выхода и сопутствующее управление состоянием. [S5](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-5)

### 6.3 Обновить вызывающие объекты распределения и выполнить многочастный анализ вместе

Если вы измените функцию распределения только на «возврат NULL в случае сбоя», а исходный вызывающий объект по-прежнему предполагает, что всегда возвращается действительный указатель, вы введете новые обращения к нулевому указателю или неполную очистку. Интерфейс отказоустойчивого распределения в патче необходимо пересмотреть вместе с проверкой вызывающего абонента и распространением исключений. [S5](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-5)

Исправления, связанные с несколькими частями, также включают выполнение совокупных проверок на основе фактического объема чтения, сокращение обработки бесполезных или повторяющихся заголовков, а также принятие согласованной логики выхода и очистки, когда OOM находится в ожидании. Эти изменения не только уменьшают усиление ресурсов, но и обеспечивают соответствие синтаксического анализатора новому протоколу OOM. [S5](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-5)

Для команд, которые поддерживают свои собственные ветки, рекомендуется, чтобы в центре внимания проверки кода были следующие вопросы:

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

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

### 6.4 Исправление перекрестных запросов: инициализация раньше, окончательная очистка позже.

Соответствующий CVE-2026-109619 патч одновременно корректирует несколько границ жизненного цикла. В качестве примера для файлов и операций, перечисленных ниже, взят официальный diff PHP 8.5. [S5](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-5)

| местоположение                                          | изменить направление                                                                                 | Проблема решена                                                                                         |
| ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| `Zend/zend_execute_API.c` и т. д.                       | Сброс состояния исполнителя, такого как ошибки, исключения, обработчики, объекты и т. д.             | После завершения запроса остаются старые ссылки, к которым можно получить доступ при следующем запросе. |
| Путь запуска `main/main.c`                              | Вызовите `php_basic_early_rinit()` до активации SAPI.                                                | Когда возникает ранний потребитель, соответствующее базовое состояние еще не инициализировано.          |
| Закрыть путь `main/main.c`                              | Уничтожьте HTTP globals и пометьте его как неопределенный.                                           | Освобожденное значение по-прежнему считается действительным объектом.                                   |
| прежде чем куча запросов будет окончательно освобождена | Еще раз очистите последнее сообщение об ошибке.                                                      | Диагностика поздней очистки повторно заполняет статус ошибки                                            |
| `ext/session/session.c`                                 | прогресс загрузки. Ранний путь инициализируется первыми глобальными переменными сеанса.              | Обычный модуль RINIT ранее обращался к старому состоянию                                                |
| Код, связанный с сериализацией                          | Ограничьте синтаксический анализ классов и обратные вызовы пользователей на ранней стадии обработки. | Выполнить дополнительный пользовательский код, если инициализация не завершена                          |

Например, последовательность запуска включает в себя:

```c
zend_activate();
php_basic_early_rinit();
sapi_activate();
```

После уничтожения HTTP globals добавьте метку сбоя статуса:

```c
zval_ptr_dtor(&PG(http_globals)[i]);
ZVAL_UNDEF(&PG(http_globals)[i]);
```

Эти отрывки иллюстрируют два принципа: **инициализировать перед самым ранним возможным потребителем и выполнить окончательную очистку после последней операции, которая может воссоздать состояние.** Сброс указателя только во время обычного RINIT или более раннего этапа завершения работы может привести к пропуску более раннего или более позднего доступа. [S5](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-5)

### 6.5 Почему не рекомендуется делать свой "однострочный ремонт"?

Замена всех `zend_bailout()` на `_exit()` или просто добавление проверки нулевого указателя в определенной записи охватила бы большое количество различных контекстов выполнения. Они могут опускать другие поля состояния или изменять уничтожение, расширенные обратные вызовы, хостинг процессов и семантику завершения запроса.

Для поддерживаемых версий приоритет имеют уже выпущенные полные исправления. При миграции собственных ветвей необходимо записывать источник исправлений, применимые базовые показатели, обработку конфликтов и изменения поведения, а также использовать соответствующие варианты использования восходящей регрессии и проверку этого бизнес-процесса. Предложения здесь основаны на анализе области применения патча в распределителе, VM, сеансах и изменениях жизненного цикла запросов. [S4](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-5)

## 7. Аварийный резервный порт PHP 7.4, 8.0, 8.1.

PHP официально предоставляет минимальный резервный исходный код трех старых веток в зависимости от серьезности. Названия ветвей:

```text
PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619
```

Ссылки на ветки см. в [S7](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-7)[S8](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-8)[S9](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-9). Это экстренные поставки для устранения этой уязвимости, которые не означают возврата к обычной поддержке старой ветки и не заменяют другие обновления безопасности. [S1](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-1)

### 7.1 В качестве примера возьмем резервный порт PHP 8.1.

Соответствующие материалы для PHP 8.1:

```text
1d7dec178a094e6e75b229ce22754045f8c6070a
```

Его стратегия предполагает отказоустойчивость: вызов `_exit(1)` после вывода диагностики по соответствующему пути OOM, включая глобальный статус и другие соответствующие исправления; при этом внутренне отключая соответствующую обработку процесса загрузки сеанса. Соответствующую отправку исходного кода см. в [S6](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-6).

Это поведенческое отличие от более полной конструкции OOM с задержкой в поддерживаемой ветке. Тот факт, что конфигурация по-прежнему показывает, что процесс загрузки включен, не означает, что поведение внутренней обработки после этого обратного переноса останется неизменным.

### 7.2 Цена, которую необходимо принять при развертывании.

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

Поэтому пользователям старых версий следует рассмотреть по порядку:

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

«Минимальный резервный порт» здесь описывает область совместимости и реализации, выбранную официальным лицом, и не должен автоматически интерпретироваться как «известные неполные исправления уязвимостей». Судить следует исходя из исходного кода соответствующей ветки и заявления производителя, а не удалять поддерживающие изменения самостоятельно. [S1](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-1)[S6](https://keendigit.com/ru/insights/php2shell-remediation-guide#source-6)

## 8. Критерии приемки и последующие проверки

В качестве основы для выполнения данного ремонта рекомендуется использовать следующие результаты:

| Приемка предметов            | Стандарты завершения                                                                                                                                                           |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| покрытие уязвимостей         | В объявлении сборки или поставщика явно исправлены CVE-2026-109618 и CVE-2026-109619.                                                                                          |
| Охват развертывания          | Все порталы, пул, службы и реплики используют исправленную среду выполнения.                                                                                                   |
| Процесс вступает в силу      | Старый рабочий, старый хост-процесс и старый контейнер завершаются.                                                                                                            |
| Проверка подлинности запроса | Подтвержденный SAPI, созданный и настроенный с использованием фактической ссылки Web для устранения неправильного направления кэша.                                            |
| доступность бизнеса          | Ключевые функции, такие как сеанс, загрузка, импорт и обработка ошибок, вернулись в нормальном режиме.                                                                         |
| Прекращение временных мер    | Конфигурации с неограниченной памятью и экстремальной переработкой рабочих ресурсов были восстановлены в соответствии с планом емкости или имеют явную причину для сохранения. |
| Свидетельства изменений      | Запишите версию пакета или дайджест образа, объем обновления, время завершения и результаты проверки.                                                                          |

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

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

## Приложение: Цитируемые источники и ссылки

Все ссылки на источники собраны ниже. Рекомендации, исправления и рекомендации поставщиков отражают проверки по состоянию на **22 октября 2026 г.**; последующие развертывания должны проверять наличие обновлений поставщиков. Пронумерованные цитаты в тексте относятся к этим статьям.

### S1 — официальный бюллетень по безопасности PHP и версия для восстановления

- Источник: Проект PHP, 21 октября 2026 г.
- Цель: объем рисков, четыре официальные версии ремонта, официальные временные меры и инструкции по аварийному резервному копированию для старых филиалов.
- Источник: [PHP 2026 This security bulletin](https://www.php.net/archive/2026.php#2026-10-21-5) находится в архиве ежегодных бюллетеней.

### S2 — CVE-2026-109618 Официальный технический бюллетень

- Источник: php/php-src GitHub Security Advisory, 21 октября 2026 г.
- Идентификация: GHSA-w8hw-w9fx-j79w.
- Цель: граница покрытия для OOM, многочастное усиление, разница SAPI и смягчение.
- Источник: [RCE via OOM corruption](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)

### S3 — CVE-2026-109619 Официальный технический бюллетень

- Источник: php/php-src GitHub Security Advisory, 21 октября 2026 г.
- Идентификация: GHSA-6wmf-4rv5-p3rp.
- Цель: состояние зависания перекрестных запросов, производители и потребители, ранняя инициализация, смягчение последствий конфигурации.
- Источник: [RCE via stale global state](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)

### S4 — официальное исправление PHP 8.5

- Источник: php/php-src.
- Отправить: `31c0ea7d7ff1d1fccb6492e52dab544011628065`.
- Цель: Подтвердить официальную заявку на исправление двух уязвимостей одновременно и объяснить общее направление изменений.
- Источник: [Avoid state corruption via bailout](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065)

### S5 — PHP 8.5 Официально восстановленный и полный дифференциал

- Источник: отличие от того же официального материала.
- Цель: проверить конкретную реализацию распределителя, VM, HTTP globals, сеанса, сериализации и жизненного цикла запроса.
- Источник: [official complete diff](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065.diff)

### S6 — PHP 8.1 официальный аварийный резервный порт

- Источник: php/php-src.
- Отправить: `1d7dec178a094e6e75b229ce22754045f8c6070a`.
- Цель: Проверить быстрый выход из старых веток и загрузить изменения поведения прогресса.
- Источник: [PHP 8.1 Emergency backport submission](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a)
- Источник: [corresponds to complete diff](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a.diff)

### S7 — официальная ветка аварийного резервного копирования PHP 7.4.

- Источник: php/php-src, PHP ветки исходного кода, перечисленные в официальном бюллетене безопасности.
- Источник: [PHP-7.4-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619)

### S8 — официальная ветка аварийного резервного копирования PHP 8.0.

- Источник: php/php-src, PHP ветки исходного кода, перечисленные в официальном бюллетене безопасности.
- Источник: [PHP-8.0-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619)

### S9 — официальная ветка аварийного резервного копирования PHP 8.1.

- Источник: php/php-src, PHP ветки исходного кода, перечисленные в официальном бюллетене безопасности.
- Источник: [PHP-8.1-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619)

### S10 — Ubuntu Бюллетень безопасности USN-8948-1

- Источник: Canonical / Ubuntu, 21 октября 2026 г.
- Цель: Выпустить бэкпорт и примеры полных версий пакетов.
- Источник: [USN-8948-1: PHP vulnerabilities](https://ubuntu.com/security/notices/USN-8948-1)

### S11 — PHP-FPM Configuration Руководство

- Источник: официальный документ PHP.
- Цель: семантика конфигурации, такая как `php_admin_value`, `php_admin_flag`, `pm.max_requests` и т. д.
- Источник: [PHP-FPM Configuration](https://www.php.net/manual/en/install.fpm.configuration.php)

### S12 — PHP Руководство по настройке ядра INI

- Источник: официальный документ PHP.
- Цель: определение и объем тела запроса, загрузки, памяти и автоматической конфигурации чтения POST.
- Источник: [Description of core php.ini directives](https://www.php.net/manual/en/ini.core.php)

### S13 — Nginx предел размера тела запроса

- Источник: официальный документ Nginx.
- Назначение: Значение `client_max_body_size` и доступные уровни конфигурации.
- Источник: [ngx\_http\_core\_module / client\_max\_body\_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size)

### S14 — Буфер запроса Nginx FastCGI

- Источник: официальный документ Nginx.
- Цель: последовательность обработки и функция `fastcgi_request_buffering`.
- Источник: [ngx\_http\_fastcgi\_module / fastcgi\_request\_buffering](https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_request_buffering)

### S15 — Nginx Состояние и инструкции по возврату

- Источник: официальный документ Nginx.
- Цель: синтаксис конфигурации `if` и `return`.
- Источник: [ngx\_http\_rewrite\_module](https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#if)

### S16 — Cloudflare PHP2Shell Инструкции по защите

- Источник: официальный блог Cloudflare.
- Цель: описание области развертывания WAF, структуры плана Free и механизма обнаружения.
- Источник: [Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)

## Консультация по обеспечению безопасности

Нужна помощь в обновлении ваших систем PHP? Мы можем оценить риск, спланировать обновление и проверить работающее приложение.

[Обсудить обновления безопасности](<https://keendigit.com/ru/contact?service=security-remediation#form>)

[Исходная страница](<https://keendigit.com/ru/insights/php2shell-remediation-guide>) · [Индекс содержания](<https://keendigit.com/ru/llms.txt>)

KeenDigit LLC · Идентификатор регистрации в Вайоминге: 2026-002106155

[Уточните у государственного секретаря штата Вайоминг.](<https://wyobiz.wyo.gov/Business/filingSearch.aspx>)

© 2026 KeenDigit LLC · Шеридан, Вайоминг, США · Все права защищены.