PHP2Shell: Критическая уязвимость PHP (CVE-2026-109618 и CVE-2026-109619)

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

Краткое резюме

21 октября 2026 года проект PHP выпустил обновления безопасности для двух критических уязвимостей в ядре PHP: CVE-2026-109618 и CVE-2026-109619, известных под общим названием PHP2Shell. Обе получили статус «критические», каждая с оценкой 9,2 из 10 по CVSS v4.0, и могут позволить атакующему выполнить код на вашем сервере без каких-либо учётных данных — неаутентифицированное удалённое выполнение кода PHP, сокращённо RCE. Уязвимость PHP 2026 года входит в число самых серьёзных за историю языка.

Затронуты все версии PHP от 5.4 до 8.5.11 включительно — фактически любая установка PHP, обрабатывающая веб-запросы: WordPress, Joomla, Drupal, TYPO3 или небольшое собственное приложение. Уязвимость находится в ядре PHP, а не в CMS или плагине.

Исправлены PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Более старые ветки (8.1 и ниже, включая PHP 7.x) официальных релизов больше не получают. Федеральное ведомство Германии по информационной безопасности (BSI) опубликовало предупреждение о кибербезопасности с требованием немедленных действий; NCSC Великобритании, CERT-EU и Киберцентр Канады выпустили аналогичные предупреждения.

Уязвимые и исправленные версии PHP

Что такое PHP2Shell?

Уязвимость PHP2Shell состоит из двух частей: PHP2Shell — собирательное название двух ошибок в ядре PHP. Обе являются ошибками памяти типа use-after-free (CWE-416): PHP продолжает использовать внутреннее состояние после того, как соответствующая память уже освобождена. Название намеренно отсылает к Log4Shell — критической уязвимости Java 2021 года: и здесь проблема не в отдельном приложении, а в компоненте, на котором построено почти всё.

Сначала ключевые термины:

• Remote Code Execution (RCE): PHP в итоге выполняет на вашем сервере код, контролируемый атакующим, — без логина, без действий пользователя.
• Out-of-Memory (OOM): PHP прерывает запрос при достижении настроенного лимита памяти (memory_limit).
• Повреждение памяти (memory corruption): класс ошибок, при которых содержимое памяти становится недействительным, а программа позже интерпретирует его неверно — техническая основа многих RCE-эксплойтов.

CVE-2026-109618: RCE через повреждение при нехватке памяти

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

Результат: один специально сформированный HTTP-запрос может скомпрометировать воркер PHP уже при обработке запроса — до того, как выполнится хоть одна строка вашего прикладного кода. На Apache с mod_php полное удалённое выполнение кода было продемонстрировано с настройками по умолчанию; на PHP-FPM RCE подтверждён через пути кода на уровне приложения.

CVE-2026-109619: RCE через устаревшее глобальное состояние

Воркеры PHP (процессы mod_php, воркеры FPM) обрабатывают много запросов подряд. Между двумя запросами внутреннее состояние должно корректно сбрасываться. С этой уязвимостью фатальная ошибка — например, из-за исчерпания памяти — может прервать запрос так, что глобальное состояние продолжит указывать на память старого запроса, давно освобождённую. Следующий запрос того же воркера использует это устаревшее состояние до того, как обычная инициализация его заменит.

Подтверждённые пути включают ранние диагностики INI (mod_php применяет конфигурацию .htaccess и php_value до фактического старта запроса), функцию отслеживания прогресса загрузки сессии (session.upload_progress.enabled включена по умолчанию) и в PHP 8.5 опцию fatal_error_backtraces. Proof of concept был продемонстрирован против реального приложения на Apache с mod_php.

Утечка памяти по образцу Heartbleed

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

Кто затронут?

Все установки PHP, обрабатывающие веб-запросы:

• PHP-FPM (обычно за Nginx или Apache)
• Apache с mod_php
• php-cgi (конфигурации CGI/FastCGI)
• FrankenPHP
• LiteSpeed (LSAPI)

Apache mod_php был оценён как наиболее критичный случай по двум причинам: продемонстрированный эксплойт вызывает уязвимость до выполнения прикладного кода, и mod_php разделяет адресное пространство напрямую с веб-сервером.

Важно: эта уязвимость PHP-сервера находится в ядре PHP. WordPress, Joomla, Drupal, TYPO3, Magento, Shopware или ваш собственный скрипт не являются причиной — но любое приложение на уязвимом PHP-runtime в принципе атакуемо, вплоть до тривиального скрипта, который лишь выводит текст. Wiz Research продемонстрировала неаутентифицированный RCE против официальных контейнерных образов WordPress, Drupal и Joomla.

Как был обнаружен PHP2Shell?

История примечательна тем, что фронтирные ИИ-модели впервые сыграли решающую роль в скоординированном раскрытии уязвимости такого масштаба:

• Ещё в 2024 разработчик ядра PHP при работе над находками первого внешнего аудита безопасности (OSTIF/Quarkslab, финансируется Sovereign Tech Agency) обнаружил первые признаки проблемы OOM — но конкретный путь эксплуатации оставался теоретическим.
• 11 августа 2026 компания Calif (исследователь Ryan A, известный как lcfr_hax, в рамках программы «Patch the Planet») сообщила проекту PHP об безусловном удалённом выполнении кода. OpenAI независимо сообщила ту же первопричину; Wiz Research последовала 24 августа, а OpenAI передала дополнительные векторы атак 18 сентября.
• Лежащие в основе ошибки существовали в коде более десятилетия. Цепочка эксплуатации считалась настолько сложной, что находилась на грани возможного для исследователей-людей — фронтирные модели снизили этот барьер. OpenAI описывает детали в своей статье о скоординированной публикации.
• 20 октября идентификаторы CVE утекли раньше времени — с неверным CVSS 10,0 и неверной датой релиза. Случайно опубликованное Calif видео с PoC и нарушение эмбарго со стороны Chainguard ускорили публикацию; PHP перенёс релиз на день раньше.

Эксплуатируется ли PHP2Shell уже сейчас?

Источники немного расходятся, поэтому с указанием даты (22 октября 2026):

• AWS наблюдала попытки эксплуатации уже с 17 октября — за четыре дня до публичного раскрытия (Datadog Security Labs).
• Cloudflare видела атакующий трафик к клиентам в окне утечки, включая мутирующие payload’ы, пытавшиеся обойти её правила WAF.
• Bitdefender и Киберцентр Канады на момент публикации сообщали об отсутствии подтверждённой массовой эксплуатации, но подчёркивают, что ситуация может быстро измениться — рабочий PoC распространяется.

Затронут ли я PHP2Shell? — проверка PHP2Shell

Прежде чем что-то менять, проверьте PHP2Shell — конкретно: выясните, какую версию PHP реально использует ваш сайт. Это не всегда так тривиально, как кажется.

Шаг 1: проверить версию PHP (CLI)

На сервере с SSH-доступом:

php -v

или альтернативно:

php -r 'echo PHP_VERSION, PHP_EOL;'

Вывод показывает версию PHP CLI, например PHP 8.3.35 (cli). Если она ниже исправленных версий (8.2.35, 8.3.36, 8.4.27, 8.5.12), требуются действия.

Шаг 2: определить реально используемую версию

Важно: версия CLI не обязана совпадать с той, что Apache или PHP-FPM используют для вашего сайта. На сервере могут параллельно стоять несколько версий PHP.

Для PHP-FPM сначала проверьте, какие FPM-сервисы запущены:

systemctl list-units --type=service | grep -i fpm

Типичные сервисы называются php8.3-fpm, php8.4-fpm или php-fpm. Соответствующую версию выдаёт бинарник:

php-fpm8.4 -v

Какой пул обслуживает какой сайт, определяется в конфигурации пула (Debian/Ubuntu: /etc/php/*/fpm/pool.d/) и конфигурации веб-сервера (в Nginx — сокет fastcgi_pass, в Apache — строки proxy:fcgi: или SetHandler виртуального хоста).

Для Apache с mod_php:

apache2ctl -M | grep php    # Debian/Ubuntu
apachectl -M | grep php     # Fedora/RHEL

Если вывод показывает php8_module (или php_module), используется mod_php — пакет обычно называется libapache2-mod-php8.x:

dpkg -l | grep libapache2-mod-php   # Debian/Ubuntu
rpm -q php                          # Fedora/RHEL-подобные

Шаг 3: дополнительные признаки — и их пределы

• HTTP-заголовки: некоторые серверы отправляют X-Powered-By: PHP/8.3.5. Его можно увидеть через curl -I https://ваш-домен.tld или dev tools браузера. Внимание: заголовок часто отключён или перезаписывается веб-сервером/прокси — его отсутствие не значит «безопасно», а содержимое не обязано совпадать с версией CGI/FPM. Это намёк, не доказательство.
• phpinfo(): файл info.php с <?php phpinfo(); в корне сайта показывает точную версию и конфигурацию. Но: phpinfo() многое раскрывает атакующим о вашей системе. Создавайте такой файл только кратковременно для диагностики и сразу же удаляйте либо блокируйте доступ — публичный phpinfo() не долгосрочное решение.
• Docker: docker exec <контейнер> php -v показывает версию внутри запущенного контейнера — версия хоста ничего не говорит об образе.

Осторожно: ловушка бэкпортов

Дистрибутивы Linux часто бэкпортируют исправления безопасности в существующие версии пакетов. php -v может показывать 8.3.10, хотя пакет уже содержит патч PHP2Shell. И наоборот: неизменный номер upstream не значит автоматически «не пропатчено», а новый номер upstream из стороннего репозитория не значит автоматически «полностью пропатчено».

Поэтому дополнительно проверяйте changelog пакета или advisory вашего дистрибьютора:

apt changelog php8.4-fpm        # Debian/Ubuntu
apt policy php8.4-fpm           # установленная vs. доступная версия
rpm -q --changelog php | less   # Fedora/RHEL

Релевантные источники — Debian Security Advisories (DSA), Ubuntu Security Notices (USN) или errata вашего корпоративного дистрибьютора.

Установка обновления безопасности PHP: исправление PHP2Shell

Полной альтернативы обновлению PHP2Shell нет — как формулирует сам проект PHP («no complete mitigations, updating is the only safe choice»). Затем прочитайте раздел для вашей конфигурации и не забудьте: перезапустить PHP-FPM или веб-сервер, иначе старые воркеры продолжат работать. Кратко об уязвимости PHP — что делать: проверить версию, установить патч, перезапустить сервисы, прочитать логи на предмет следов атаки.

Debian / Ubuntu

sudo apt update
sudo apt upgrade

Затем проверьте установленную версию пакета (apt policy php8.4-fpm, при необходимости скорректируйте имя) и загляните в changelog (см. замечание о бэкпортах выше). PHP-пакеты в Debian/Ubuntu часто приходят из security-репозитория или — для более новых версий — из известного репозитория Sury (packages.sury.org), который оперативно публикует пропатченные сборки.

Fedora / системы типа RHEL

sudo dnf upgrade php\*
sudo dnf list php --showduplicates   # проверить доступные версии

Здесь действует то же: сверьте версию пакета и changelog (rpm -q --changelog php) с errata дистрибьютора. При использовании Remi’s Repo или module streams учитывайте источник.

Перезапуск PHP-FPM

После обновления перезапуск обязателен, иначе старые воркер-процессы продолжат работать:

sudo systemctl restart php8.4-fpm   # скорректируйте имя под вашу версию

Затем проверьте, что сервис работает на новой версии:

systemctl status php8.4-fpm
php-fpm8.4 -v

Apache mod_php

С mod_php PHP работает внутри процесса Apache — не поможет обновить PHP, если Apache продолжает работать со старой библиотекой:

sudo systemctl restart apache2   # Debian/Ubuntu
sudo systemctl restart httpd     # Fedora/RHEL

Затем протестируйте сайт и проверьте логи (journalctl -u apache2, /var/log/apache2/error.log).

Управляемый хостинг (Plesk, cPanel, панели хостеров)

На shared-хостинге или управляемых серверах у вас обычно нет root-доступа — и он не нужен:

1. Проверьте, какая версия PHP назначена каждому домену (Plesk: «Настройки PHP», cPanel: «MultiPHP Manager», у многих хостеров — в клиентской панели).
2. Переключитесь на пропатченную версию, если доступна (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 или новее).
3. Свяжитесь с хостером, если предлагаются только уязвимые версии — серьёзные провайдеры патчат свои платформы централизованно и сообщают об этом; при сомнениях спросите про статус PHP2Shell.
4. Для WordPress дополнительно в админке: Инструменты → Здоровье сайта → Информация → Сервер показывает версию PHP, которую видит WordPress.

PHP2Shell и Docker: контейнеры, образы, платформы

IRC-Security.de

Cybersecurity Artikel und Tutorials

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

Насколько я уязвим с Docker?

Коротко: так же уязвим, как и без Docker, что касается исходной уязвимости. Если PHP внутри образа уязвим, HTTP-запрос может скомпрометировать воркер PHP внутри контейнера — сеть ведь и есть смысл этого контейнера.

Изоляция помогает только на втором шаге: код сначала выполняется «лишь» внутри контейнера, с пользователем контейнера, смонтированными томами и секретами в переменных окружения. Это ограничивает ущерб — но контейнер с доступом к базе данных, каталогом загрузок и API-ключами всё равно очень привлекателен для атакующих. PHP2Shell внутри контейнера — критическое событие, а не «вдвое безобиднее».

Какие образы затронуты?

Всё, что содержит PHP. Типичные кандидаты:

• базовые образы php:* (php:8.3-fpm, php:8.4-apache, php:8.5-cli, …) и всё, что на них построено (FROM php:… в вашем Dockerfile)
• образы со встроенным PHP: wordpress:*, nextcloud:*, drupal:*, joomla:*, matomo:*, mediawiki:* и многие другие
• образы FrankenPHP (dunglas/frankenphp:*)
• собственные сборки, включая multi-stage со COPY --from=php…

Найти базы PHP в проекте:

grep -rnE '^\s*FROM\s+\S*(php|frankenphp)' . --include='Dockerfile*'
grep -rnE 'image:\s*\S*(php|wordpress|nextcloud|drupal|joomla|frankenphp)' . --include='*compose*.y*ml'

Что конкретно нужно сделать?

1. Переключиться на пропатченные теги. Официальные образы PHP на Docker Hub уже обновлены (теги вида php:8.3.36-fpm-bookworm, php:8.4.27-apache, php:8.5.12-fpm-alpine; плавающие теги php:8.3, php:8.4 и др. тоже указывают на исправленные сборки). В Dockerfile вместо php:8.3-fpm лучше зафиксировать php:8.3.36-fpm-bookworm.
2. Пересобрать собственные образы — с --pull. Без --pull кэш сборки может переиспользовать старый уязвимый базовый образ:

docker compose build --pull
docker compose up -d --force-recreate

3. Образы из Hub без собственной сборки — просто заново загрузить и пересоздать контейнеры:

docker compose pull
docker compose up -d --force-recreate

4. Не забыть не только веб-контейнер: воркеры очередей, cron-контейнеры, планировщики — всё, что использует тот же образ PHP.
5. Проверить внутри запущенного контейнера:

docker exec <имя_контейнера> php -v

6. Учесть digest-пины: кто фиксирует образы через @sha256:…, должен вручную поднять digest до пропатченной сборки — пины не подтягивают обновления безопасности автоматически.
7. После этого удалить старые уязвимые образы, чтобы ничего случайно из них не запустилось.

Возьмут ли провайдеры обновление на себя?

Частично — и именно здесь рождается большинство неверных предположений:

• Docker Official Images и Docker Hardened Images уже обновлены Docker Inc. до пропатченных версий PHP. Но это значит лишь: образ в registry новый — ваш запущенный контейнер остаётся на старой сборке, пока вы его не пересоздадите.
• Образы приложений (wordpress, nextcloud и др.) пересобираются их командами мейнтейнеров с новым PHP — pull и recreate остаются за вами.
• Управляемые платформы / PaaS обычно патчат свой собственный runtime централизованно. Произошло ли это и когда, скажет только advisory или status-страница провайдера — ваши собственные контейнерные образы, развёрнутые там, остаются вашей зоной ответственности.
• Автообновители (например, Watchtower) могут заново загружать образы из Hub и пересоздавать контейнеры — но они не могут починить локально собранные образы. Для Dockerfile с FROM php:… нужен rebuild, в идеале автоматизированный через CI или Dependabot/Renovate.

Coolify конкретно

Coolify — особый случай, потому что сам Coolify написан на PHP (Laravel) — платформа была уязвима по всем линиям v4, независимо от приложений, которые вы через неё развёртываете:

• Обновление с v4.4: в дашборде через Settings → Update → Check now → Update.
• Более старые линии v4: по SSH официальным патч-скриптом (curl -fsSL https://cdn.coollabs.io/coolify/patch.sh | sudo bash), который устанавливает соответствующий security-релиз вашей линии и пересоздаёт только контейнер Coolify.
• Coolify Cloud уже пропатчен — там ничего делать не нужно.
• Coolify превентивно отключила 58 PHP-шаблонов сервисов, пока не проверено, какие образы содержат исправление.
• Важно: обновление Coolify патчит только сам Coolify. Ваши развёрнутые контейнеры приложений остаются уязвимыми, пока вы их не пересоберёте/не передеплоите — в Coolify по каждому приложению запускайте redeploy со свежей сборкой.

Детали — в официальной документации Coolify и в связанном GitHub-ишью.

Dokploy, CapRover, Easypanel, Dokku, Portainer и др.

Тот же принцип, что и у Coolify, в два этапа:

1. Проверить сам инструмент: работает ли платформа или один из её основных контейнеров на PHP? Тогда читайте advisory проекта и устанавливайте обновление инструмента.
2. Развёрнутые через него приложения: остаются вашей задачей — пересоберите или заново загрузите образы и передеплойте приложения.

Для Kubernetes аналогично: соберите образ с пропатченным PHP, затем перезапустите rollout (kubectl rollout restart), чтобы все поды подтянули новую версию, и при необходимости проверьте digest запущенных подов. Если нужен контекст по образам, контейнерам и Docker Compose, смотрите статью об основах Docker.

Временные меры, если патч сразу невозможен

Если обновление временно невозможно, официальные advisory говорят, что следующие меры уменьшают поверхность атаки — но не защищают полностью и не заменяют обновление безопасности PHP:

• установить memory_limit=-1 так, чтобы приложения не могли это переопределить (например, php_admin_value в пуле FPM или конфигурации Apache) — убирает контролируемый OOM-триггер, но не все пути
• низкий post_max_size (например, 8M, если загрузки не нужны), держать upload_max_filesize ниже
• session.upload_progress.enabled=0 — закрывает путь upload-progress у CVE-2026-109619, но не всю уязвимость
• лимиты запросов на reverse proxy/веб-сервере (размер тела, количество заголовков и multipart-частей)

PHP 7.x, 8.0 и 8.1: что делать с версиями end-of-life?

Старые версии PHP не «безопасны, потому что старые» — наоборот: уязвимости восходят к PHP 5.4, а PHP 8.1 и старше больше не получают официальных релизов от проекта PHP.

Ваши реалистичные варианты:

1. Проверить бэкпорты дистрибутива/вендора: команда безопасности PHP предоставила исходные бэкпорты для 7.4, 8.0 и 8.1, и LTS-провайдеры (Debian LTS, Ubuntu с Extended Security Maintenance, RHEL, специализированные PHP-LTS-провайдеры) собирают из них пакеты. Решающее значение имеет версия пакета в changelog, а не номер upstream.
2. Мигрировать на поддерживаемую версию (8.2+). Это правильный долгосрочный ответ: кто эксплуатирует PHP 7.x в продакшене, и так работает без обновлений безопасности — PHP2Shell лишь делает это особенно заметным.
3. Временно применить меры выше — осознанно как заплатку, а не решение.

Мог ли мой сервер уже быть скомпрометирован?

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

В логах веб-сервера/PHP (access.log, error.log, лог FPM, syslog/journald):

• необычные или необычно большие HTTP POST-запросы, особенно с multipart/form-data
• частые ошибки PHP out-of-memory («Allowed memory size exhausted») в районе инициализации запроса
• заметный всплеск ошибок HTTP 500
• падающие или постоянно перезапускающиеся воркеры PHP-FPM или Apache (segfault’ы, «child exited»)

В системе:

• новые или неожиданно изменённые PHP-файлы в корне сайта и в каталогах загрузок (wp-content/uploads и др.) — PHP-файлы в папках загрузок почти всегда тревожный знак
• веб-шеллы: файлы, передающие параметры запроса в system, shell_exec, passthru, eval и т. п.
• неизвестные cron-задачи (crontab -l для всех пользователей, /etc/cron.*) и неизвестные учётные записи (/etc/passwd, last, auth.log)
• процессы PHP/веб-сервера, неожиданно запускающие шеллы, интерпретаторы (bash, python) или загрузчики (curl, wget) — видно, например, в списке процессов, audit-логах или EDR
• в WordPress: необычные изменения плагинов, тем, wp-config.php, новые учётные записи администраторов

При конкретных находках: изолируйте систему (отсоедините сеть, не стирайте и не переустанавливайте сразу), сохраните летучие данные и образы и проведите форензик-анализ — самостоятельно или через провайдера. Полезный вход в мышление и методику — статья о пентестах в Linux и IT-форензике на IRC-Security.de (на немецком); о гигиене обновлений в целом — материал об управлении патчами в Linux (на немецком).

Затронут ли WordPress PHP2Shell? (а также Joomla, Drupal, TYPO3)

И да, и нет. Ищете ли вы PHP2Shell WordPress, PHP2Shell Joomla, PHP2Shell Drupal или TYPO3 — ответ один и тот же, и ему нужна точность:

• CMS не является причиной. Уязвимость находится в ядре PHP, а не в ядре WordPress, не в плагинах и не в теме.
• Но: WordPress работает на PHP. Если ваш WordPress работает на уязвимой версии PHP, уязвимость PHP WordPress реальна — Wiz продемонстрировала неаутентифицированный RCE против официальных образов WordPress, Drupal и Joomla.
• Обновление WordPress не поможет. Обновления ядра, тем или плагинов не патчат PHP-runtime. Только обновление безопасности PHP (или бэкпорт дистрибутива) закрывает дыру.

Как проверить версию оператору WordPress:

• В админке: Инструменты → Здоровье сайта → Информация → Сервер → версия PHP
• В панели хостинга провайдера (Plesk «Настройки PHP», cPanel «MultiPHP Manager» и т. п.)
• Спросить поддержку хостера, если предлагаются только старые версии
• Кто запускает WordPress через Docker-образ wordpress:*: PHP там встроен → загрузите обновлённый образ и пересоздайте контейнер (см. раздел Docker)

Более общие паттерны атак — например, как классифицируются уязвимости веб-приложений — разбирает статья об OWASP Top 10; сравнение с классическими инъекциями вроде SQL-инъекций показывает, почему PHP2Shell играет в другой лиге: приложение здесь не может быть защитным слоем, потому что атака бьёт до его запуска.

Может ли файрвол или WAF предотвратить PHP2Shell?

Web Application Firewall может помочь, но это не замена обновлению:

• Cloudflare включила правила PHP2Shell для всех клиентов (включая бесплатный план) и применила для этого новую «Full Transaction Detection» — правила, оценивающие запрос и ответ одной транзакции вместе, потому что один запрос не всегда отличает эксплойт от легитимного трафика. Другие провайдеры (Azure WAF, Google Cloud Armor, AWS WAF, Imunify360, Sucuri и др.) последовали со своими правилами.
• Блокировка запросов на вышестоящей границе (WAF, reverse proxy) останавливает атаку до того, как она достигнет уязвимого парсера — реальный выигрыш защиты, пока правила покрывают варианты payload.
• Но: эксплойты мутируют (Cloudflare наблюдала именно это), остаются внутренние пути атаки и каналы не-HTTP(S), а утечка памяти вообще не обязана иметь блокируемую форму запроса.

Итог: WAF — да, как дополнительный слой (defense in depth), а не как исправление. Кто хочет углубиться в reverse proxy и шлюзы: основы API Gateway с Kong и Nginx.

FAQ: PHP2Shell

Источники и полезные ссылки

Официальные источники и advisory:

• Анонс релизов безопасности PHP (php.net)
• GHSA-w8hw-w9fx-j79w – RCE via OOM corruption (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp – RCE via stale global state (CVE-2026-109619)
• The PHP Foundation: Today’s PHP Security Release
• php2shell.com – обзорная страница исследователей

Органы власти:

• Предупреждение BSI о кибербезопасности: PHP – критические уязвимости угрожают веб-приложениям по всему миру (на немецком)
• CERT-EU Advisory 2026-018: Critical Vulnerabilities in PHP
• NCSC (Великобритания): Critical security issue affecting PHP
• Canadian Centre for Cyber Security: AL26-026
• NCSC-NL: оперативная информация по инциденту PHP2Shell (GitHub)

Исследования и обнаружение:

• Wiz Research: PHP2Shell – AI uncovers critical RCE vulnerabilities
• OpenAI: Patch the Planet – global response coordination
• Datadog Security Labs: PHP2Shell – detection, analysis, and remediation
• Cloudflare: Deploying protections against php2shell

Docker и платформы:

• Docker: Security Update on PHP2Shell – Impact for Docker Customers
• Coolify Docs: PHP Security Advisory 2026 (PHP2Shell)
• Coolify GitHub Issue #12266: Update Coolify now for PHP2Shell

Углубление на IRC-Coding.de и IRC-Security.de:

• OWASP Top 10: угрозы веб-приложений
• SQL-инъекции: риски, защита и лучшие практики
• Docker: основы, образы, Dockerfile и Compose
• Учебник Bash в Linux для начинающих
• Популярные языки программирования: обзор (включая PHP)
• IRC-Security.de: управление патчами и автоматические обновления Linux (на немецком)
• IRC-Security.de: Kali Linux, пентесты и IT-форензика (на немецком)

Похожая статья о PHP2Shell на IRC-Mania.de (на немецком):

• PHP2Shell: WordPress, Docker, Coolify и домашние серверы — проверьте и защитите их сейчас

PHP2Shell с точки зрения ИИ на BotServ.de:

• Русский: PHP2Shell – критическая уязвимость PHP и роль ИИ
• Deutsch: PHP2Shell – Kritische PHP-Sicherheitslücke und die neue Rolle der KI
• English: PHP2Shell – Critical PHP Vulnerability and AI’s Role
• Español: PHP2Shell – Vulnerabilidad crítica y el rol de la IA

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert