Введите URL своего сайта или сайта, который вам разрешено тестировать. Изучите признаки PHP, версии и ответы на формы, чтобы оценить риски PHP2Shell и определить дальнейшие меры.
2
Уязвимости ядра PHP
9.2
Оценка CVSS v4.0 (критическая)
4
Исправленные основные ветки 8.2–8.5
Обзор уязвимостей
PHP2Shell объединяет две уязвимости безопасности памяти ядра PHP: CVE-2026-109618 и CVE-2026-109619, обе с оценкой CVSS v4.0 9.2. Они могут позволить удалённое выполнение кода без аутентификации; последствия зависят от версии, развёртывания и пути атаки.
Повреждение памяти при обработке её нехватки может привести к удалённому выполнению кода без аутентификации. Обновите PHP или установите исправления поставщика.
ПодробнееУстаревшее глобальное состояние запроса может повторно использоваться следующим запросом в том же рабочем процессе, вызывая ошибки безопасности памяти и удалённое выполнение кода.
ПодробнееПроверьте фактическую веб-среду PHP, полную версию пакета и уведомление поставщика, затем перезапустите рабочие процессы. Временные меры не заменяют исправления.
ПодробнееПроверьте PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed и другие PHP-среды, обслуживающие веб-запросы. По данным PHP, mod_php несёт наибольший риск: атака продемонстрирована до запуска кода приложения. Простые страницы и безопасный код не исключают угрозу.
Обновление WordPress, Drupal, фреймворка или плагина не обязательно обновляет PHP. Проверьте версию для каждого сайта, пулы FPM, образы контейнеров, узлы и PHP, встроенный в панели или устройства. Официальные исправленные версии выпущены 21 октября 2026 года.
Что проверяется
Изучите признаки PHP в публичных ответах.
Заголовки дают подсказки, но не доказывают наличие исправления.
Сравните коды состояния с контрольными запросами.
Сопоставьте полные версии пакетов с уведомлениями поставщика.
Убедитесь, что все рабочие веб-процессы обновлены и перезапущены.
Сначала выполните базовый GET, затем отправьте URL-кодированную и multipart-форму для каждого из трёх методов. Изучайте каждый ответ до следующего запроса. Обычные запросы сравнивают поведение без нагрузок для выполнения кода или исчерпания памяти.
| Порядок | Метод | Содержимое запроса | На что обратить внимание |
|---|---|---|---|
| 01 | GET | Без тела запроса | Доступность, перенаправления, открытая версия PHP и заголовки ответа. |
| 02 | POST | application/x-www-form-urlencoded | Одно обычное текстовое поле как контроль для POST. |
| 03 | POST | multipart/form-data | Одно текстовое поле для сравнения с контрольным POST, без файлов и полей прогресса загрузки. |
| 04 | PUT | application/x-www-form-urlencoded | Одно обычное текстовое поле для наблюдения за обработкой PUT по этому пути. |
| 05 | PUT | multipart/form-data | Сравните с URL-кодированным PUT, чтобы выявить различия из-за типа содержимого. |
| 06 | PATCH | application/x-www-form-urlencoded | Одно обычное текстовое поле как контроль для PATCH. |
| 07 | PATCH | multipart/form-data | Сравните с контрольным PATCH, не делая выводов обо всех методах только по POST. |
Указания PHP в X-Powered-By или Server и cookies вроде PHPSESSID — лишь признаки среды. Они могут быть скрыты, изменены или настроены произвольно. Cookie также не доказывает, что PHP разобрал тело запроса.
Проверки охватывают только указанный URL и путь. Другие маршруты, правила CDN и доступные напрямую серверы могут вести себя иначе. Не переносите результат главной страницы на весь сайт. Проверяйте только разрешённые пути, подходящие для запросов форм.
Как понимать результаты
Публичные ответы дают лишь часть данных. Версии могут быть скрыты или изменены, а старые сборки могут содержать бэкпорты. Проверяйте фактическую среду и не принимайте недостаток данных за безопасность.
Типичные ошибки оценкиОткрытая версия не ниже порога исправления своей ветки — полезный признак, но прокси может менять заголовки. Убедитесь на сервере, что все экземпляры загрузили исправленный код.
В первую очередь проверяйте версии ниже официального порога, учитывая бэкпорты дистрибутива или LTS-поставщика. Если их статус неизвестен, отмечайте необходимость проверки, а не подтверждённое удалённое выполнение кода.
Успех контрольного запроса при multipart 4xx может указывать на ограничение типа содержимого. Два ответа 405 могут означать лишь неподдерживаемый метод. По одним кодам нельзя отличить отказ CDN, веб-сервера или приложения.
Скрытые версии, кэш прокси, нестандартные cookies, ошибки подключения и тайм-ауты ограничивают оценку. Отмечайте недостаток данных или невозможность оценки вместо зелёного заключения о безопасности.
Порядок проверки
Укажите адрес своего или разрешённого для тестирования сайта вместе с проверяемым путём.
Начните с базового GET, затем по одному сравните ответы на URL-кодированные и multipart-запросы POST, PUT и PATCH.
Оцените коды состояния и признаки версии, затем сверьте исправления с фактической средой PHP и уведомлениями поставщика.
Проверка на сервере
Внешние проверки дают подсказки, но исправления нужно подтвердить на хосте, в контейнерах или панели хостинга. Зафиксируйте среду, источник пакета, исправленную версию и состояние процессов после обновления.
Проверьте PHP сайта, модуль веб-сервера или пул FPM. Учтите параллельные версии, сайты, контейнеры и узлы балансировки. php -v показывает только текущую CLI-версию, которая может отличаться от веб-среды. Не публикуйте страницу phpinfo для этой проверки.
php -vУзнайте версию установленного пакета и сравните её целиком с уведомлением дистрибутива. Пакет Ubuntu 24.04 8.3.6-0ubuntu0.24.04.13 уже исправлен; строка PHP 8.3.6 скрывает сведения о бэкпорте. Выберите подходящий пример и замените имя пакета.
dpkg-query -W php8.3-fpm
rpm -q php-fpmИспользуйте исправленную основную версию, последующий выпуск безопасности той же ветки или подтверждённый бэкпорт. PHP в панелях, устройствах и контейнерах обновляйте через поставщиков. Для PHP 8.1 и старше обычная поддержка завершена: проверьте LTS-исправления или мигрируйте. Также предоставлены минимальные исходные бэкпорты для 7.4, 8.0 и 8.1.
Убедитесь в перезапуске PHP-FPM, Apache и других процессов, а также замене контейнеров и узлов. Обновлённые файлы на диске не гарантируют замену старых процессов. Необычные запросы, нехватка памяти и сбои помогают расследованию, но отсутствие этих записей не доказывает отсутствие воздействия.
Скрипт поочерёдно отправляет один GET, затем URL-кодированные и multipart-формы методами POST, PUT и PATCH. Используются только текстовые поля, без файлов и полей прогресса загрузки. Запускайте его только на разрешённых путях для тестовых форм: обычный запрос тоже может запускать действия приложения.
#!/usr/bin/env bash
# PHP2Shell HTTP observations: 7 sequential requests, no exploit payload.
set -u
URL="${1:-https://example.com/}"
case "$URL" in
http://*|https://*) ;;
*) printf 'ERROR=HTTP(S)_URL_REQUIRED\n' >&2; exit 2 ;;
esac
if ! command -v curl >/dev/null 2>&1 || ! command -v awk >/dev/null 2>&1; then
printf 'ERROR=CURL_AND_AWK_REQUIRED\n' >&2
exit 127
fi
probe() {
printf '\n[%s/7] %s %s\n' "$1" "$2" "$3"
local method="$2"
shift 3
curl -q --globoff --proto '=http,https' --silent --show-error \
--connect-timeout 5 --max-time 15 --request "$method" \
--dump-header - --output /dev/null \
--write-out '\nHTTP_CODE=%{http_code} TOTAL_SECONDS=%{time_total}\n' \
"$@" --url "$URL" |
awk '{
sub(/\r$/, "")
line = tolower($0)
if ($0 ~ /^HTTP\// || line ~ /^(server|x-powered-by|content-type):/ || $0 ~ /^HTTP_CODE=/) {
print
} else if (line ~ /^set-cookie:[ \t]*phpsessid[ \t]*=/) {
print "PHPSESSID=present; value hidden"
}
}'
local curl_status="${PIPESTATUS[0]}"
if [ "$curl_status" -ne 0 ]; then
printf 'CURL_EXIT=%s\n' "$curl_status"
FAILED=1
fi
}
FAILED=0
probe 1 GET baseline
probe 2 POST urlencoded --data-raw 'php2shell_check=1'
probe 3 POST multipart --form-string 'php2shell_check=1'
probe 4 PUT urlencoded --data-raw 'php2shell_check=1'
probe 5 PUT multipart --form-string 'php2shell_check=1'
probe 6 PATCH urlencoded --data-raw 'php2shell_check=1'
probe 7 PATCH multipart --form-string 'php2shell_check=1'
exit "$FAILED"Используйте Bash в Linux/macOS либо WSL или Git Bash в Windows. Сохраните файл php2shell-self-check.sh и выполните команду ниже с разрешённым тестовым URL. Не вставляйте Bash-скрипт напрямую в PowerShell.
bash php2shell-self-check.sh https://example.com/test.phpОжидание соединения ограничено 5 секундами, весь запрос — 15 секундами. Скрипт игнорирует личные настройки curl, проверяет TLS, не следует перенаправлениям и не повторяет запросы. При 3xx проверьте разрешение на конечный URL, затем запустите проверку для него. PHPSESSID отмечается только как присутствующий; значения cookie и тела ответов не выводятся.
HTTP_CODE — статус ответа, TOTAL_SECONDS — общее время. Ненулевой CURL_EXIT означает ошибку передачи; остальные проверки продолжаются. Ненулевой код завершения скрипта указывает на проблему входных данных, зависимостей или передачи. HTTP 4xx/5xx записываются штатно; код завершения не оценивает уязвимости и исправления.
Server или X-Powered-By могут быть скрыты или устареть. Проверьте PHP, который действительно обслуживает сайт: первые официально исправленные версии соответствующих веток — 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Бэкпорты поставщика подтверждайте по полной версии пакета и уведомлению о безопасности.
Если для одного метода urlencoded возвращает 2xx или 3xx, а multipart — 403 или 406, это показывает лишь разницу ответов. Это не подтверждает блокировку WAF или отказ до передачи запроса в PHP.
Ответ 2xx или 3xx на multipart означает только получение успешного ответа или перенаправления. Он не доказывает, что тело достигло PHP и было разобрано, и не определяет наличие уязвимости.
Одинаковые ответы 405 не доказывают исправление. Отсутствие признаков PHP не доказывает, что PHP не используется. Cookie PHPSESSID также не определяет, был ли разобран multipart и какой слой сформировал ответ.
PHP указывает, что полное исправление даёт только обновление. Настройки ниже уменьшают риск отдельных известных путей, но не делают неисправленную среду безопасной. Перед изменениями учтите требования приложения и официальные рекомендации.
Официальные исправленные версии
Сравнивайте версии в рамках одной ветки: порог 8.3 не определяет статус 8.4. Не считайте предварительные выпуски и неизвестные ветки исправленными. Проверяйте бэкпорты и собственные сборки по полной версии пакета, журналам сборки и уведомлениям поставщика.
Согласно уведомлению BaoTa от 2026-10-21, в панели доступны некоторые выпуски PHP с исправлениями безопасности. Актуальный список версий проверяйте в магазине ПО вашей панели.
Прочитать уведомление BaoTa об обновленииПеред обновлением сохраните резервные копии сайта, баз данных и конфигурации и выберите подходящее время обслуживания.
Войдите в BaoTa Panel, откройте Магазин ПО → Установлено, найдите версию PHP, которую использует сайт, и откройте её страницу управления.
Проверьте обновления на странице управления PHP и по инструкции установите указанный выше исправленный выпуск своей ветки или более поздний выпуск безопасности той же ветки.
После обновления перезапустите соответствующую службу PHP и убедитесь, что все рабочие процессы перезагружены. Проверьте фактическую версию PHP сайта, доступ к страницам, загрузку файлов, подключение к базе данных и другие функции.
Если установлено несколько версий PHP, проверьте каждую используемую версию. При установке другой версии также убедитесь, что сайт переключён на исправленную среду PHP.
Частые вопросы
Различайте признаки версии, коды состояния и бэкпорты, чтобы не переоценивать результаты.
PHP2Shell — это две уязвимости ядра PHP, CVE-2026-109618 и CVE-2026-109619, допускающие удалённое выполнение кода без аутентификации. Проверьте все неисправленные PHP-среды для веб-запросов, даже если код приложения безопасен.
Нет. Эти коды могут возникать из-за аутентификации, неподдерживаемого метода, ограничения размера или прокси. Отказ multipart описывает только текущий путь и не доказывает исправление PHP или блокировку всех атак.
Не обязательно. Показ версии может быть отключён, а CDN, обратный прокси или статическая главная страница могут скрывать серверную технологию. Отсутствие признаков означает недостаток данных: проверьте реальную среду сервера.
Основные исправления доступны в PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Используйте исправленный или более поздний безопасный выпуск своей ветки. Старые версии могут иметь бэкпорты: сверяйте полную версию пакета с уведомлениями поставщика. Для PHP 8.1 и старше обычная поддержка завершена. После обновления перезапустите процессы.
Методы могут проходить разные маршруты и фильтры. Начиная с PHP 8.4 приложения могут использовать request_parse_body() для multipart не только в POST. Это не означает автоматический разбор PUT или PATCH всеми приложениями. По POST нельзя судить о защите других методов или путей.
Отметьте среду PHP и исправления как неподтверждённые. POST 200 означает ответ, а 405 — отказ метода на некотором уровне. Так могут отвечать статические страницы, другие среды и PHP со скрытыми признаками. Проверьте среду на сервере, не объявляя безопасность или подтверждённую уязвимость.
Источники об уязвимостях и исправлениях проверены 2026-10-22. Внешние наблюдения ограничены; при принятии мер следуйте актуальным уведомлениям PHP и поставщиков.
Проверяйте публичные ответы по одному, оценивайте данные и подтверждайте исправления в реальной среде сервера.