Критические уязвимости в PHP 5.4 - PHP 8.5

Критические уязвимости в PHP 5.4 - PHP 8.5, время обновляться...

Сегодня

21 октября 2026 года в экосистеме PHP развернулась классическая драма: информация о критических уязвимостях под кодовым именем php2shell утекла в сеть раньше срока, нарушив эмбарго. Команде PHP пришлось экстренно выкатывать патчи.

Уязвимости получили запредельный рейтинг опасности — CVSS 9.2 (Critical). Атакующий может выполнить произвольный код на сервере (RCE) без авторизации, просто отправив специально сформированный multipart POST-запрос. Cloudflare и ИБ-компании уже фиксируют волну сканирований и попыток эксплуатации.

В этой статье разберём, в чём суть проблемы, почему классические WAF и плагины безопасности бессильны, и дадим готовые инструкции: как обновиться в 1 команду на свежих версиях и как пропатчить легаси (PHP 5.6, 7.4, 8.0, 8.1), которые разработчики языка давно списали в архив.

Речь идёт о связке из двух уязвимостей: CVE-2026-109618 и CVE-2026-109619.

OOM Corruption (CVE-2026-109618): Когда на сервер загружается форма (multipart/form-data), парсер PHP начинает обрабатывать части запроса. Если в запросе передать сотни тысяч заголовков или специально упакованные поля, PHP исчерпывает memory_limit. В этот момент ядро вызывает аварийный выход (zend_bailout), но память очищается некорректно — структуры данных ещё не успели полностью инициализироваться. Происходит Use-After-Free (UAF), приводящий к выполнению чужого кода.
Загрязнение глобального состояния воркера (CVE-2026-109619): В архитектуре PHP-FPM воркер обслуживает множество запросов подряд. Когда один запрос аварийно завершается, глобальное состояние (обработчики ошибок, объекты, сессии) остаётся в «подвешенном» состоянии. Следующий входящий запрос читает «висячие» указатели чужой памяти. Идеальным потребителем этой уязвимости оказался встроенный механизм отслеживания загрузки файлов (session.upload_progress).

Самое неприятное: уязвимость срабатывает на этапе парсинга HTTP-запроса самим интерпретатором, то есть ДО того, как начнёт выполняться код вашего фреймворка или CMS. Никакие middleware Laravel, фильтры WordPress или WAF-правила внутри приложения вас не защитят.

Все веб-серверы на PHP: PHP-FPM, Apache mod_php, FrankenPHP, LiteSpeed.
Популярные CMS: OpenCart, WordPress, Bitrix, Drupal, Magento и любые самописные системы.
Панели управления серверами: HestiaCP, FastPanel, cPanel, ISPmanager — уязвимы как сайты клиентов, так и внутренние процессы самих панелей.

Если ваши сайты работают на поддерживаемых версиях, вам повезло. Официальные исправления уже вышли: 8.5.12, 8.4.27, 8.3.36, 8.2.35.

Популярные репозитории (включая deb.sury.org для Ubuntu/Debian) выпустили пакеты в первые же часы.

sudo apt update

sudo apt install --only-upgrade "php8.*" php-fpm

sudo systemctl restart "php*-fpm"

Проверьте результат:

php -v

Должна быть одна из версий: 8.2.35, 8.3.36, 8.4.27 или 8.5.12

В HestiaCP работают два независимых PHP:

PHP для сайтов клиентов (в /etc/php/...).
Внутренний PHP панели (hestia-php в /usr/local/hestia/php/).

Даже если вы обновите системный PHP для сайтов, панель управления может оставаться уязвимой. Пока официальный пакет hestia-php обновляется, обязательно примените экспресс-настройку:

Откройте /usr/local/hestia/php/lib/php.ini (или etc/php.ini) и добавьте в конец:

memory_limit = -1
session.upload_progress.enabled = 0
post_max_size = 16M

Затем перезапустите панель:

sudo systemctl restart hestia

Это главная головная боль рунета. Тысячи интернет-магазинов (особенно на OpenCart 1.5/2.x/3.x или старых темах WordPress) намертво привязаны к PHP 5.6 или 7.4. Обновить версию интерпретатора «в лоб» нельзя — сайт просто ляжет с фатальными ошибками синтаксиса и модулей.

При этом официальные мейнтейнеры закрыли эти ветки (End of Life) и не выпускают для них deb/rpm-пакеты.

Здесь есть два пути: быстрый харденинг (купить время) и настоящий патч (скомпилировать безопасный бинарник).

Харденинг не устраняет баг в коде, но ломает цепочку эксплуатации эксплойта: убирает лимит памяти на этапе multipart-парсинга (исключая триггер OOM) и наглухо отключает upload_progress.

Мы упаковали это в открытый скрипт, который автоматически находит все пулы PHP-FPM и конфиг HestiaCP:

curl -fsSL https://raw.githubusercontent.com/Anton-Barinov/php2shell-patches/main/harden/apply-hardening.sh | sudo bash

Что делает скрипт:

Создаёт резервные копии конфигов.
Прописывает в каждый пул FPM: session.upload_progress.enabled = 0, memory_limit = -1, ограничивает post_max_size.
Защищает конфиг панели HestiaCP.
Мягко перезапускает службы.

Чтобы закрыть уязвимость на фундаментальном уровне, старые версии нужно пересобрать с патчем.

В открытом репозитории Anton-Barinov/php2shell-patches собраны готовые бэкпорты двух видов:

minimal (официальный подход PHP Group) — при возникновении ошибки немедленно завершает воркер через _exit(1) и принудительно выключает session.upload_progress.
enhanced-universal (комьюнити-версия) — решает проблему UAF в корне (заменяет сырые указатели счетчиков на zend_long). При этом прогресс-бар загрузки файлов и большие формы продолжают работать, что критично для административных панелей OpenCart и загрузки каталогов товаров.

Чтобы не сломать системный пакетный менеджер, мы собираем патченный PHP в изолированную директорию /opt/php-7.4-patched.

Установите зависимости сборки:

sudo apt update
sudo apt install -y build-essential autoconf bison re2c pkg-config \
libxml2-dev libssl-dev libcurl4-openssl-dev libsqlite3-dev \
libonig-dev libzip-dev git curl

Склонируйте репозиторий с патчами:

git clone https://github.com/Anton-Barinov/php2shell-patches.git
cd php2shell-patches

Запустите автоматическую сборку:

Для PHP 7.4 (рекомендуется enhanced-патч):

sudo ./build/build-patched-php.sh 7.4.33 patches/php-7.4-enhanced-universal.patch /opt/php-7.4-patched

Либо для древнего PHP 5.6:

sudo ./build/build-patched-php.sh 5.6.40 patches/php-5.6-enhanced-universal.patch /opt/php-5.6-patched

Для PHP 7.4 (рекомендуется enhanced-патч):

sudo ./build/build-patched-php.sh 7.4.33 patches/php-7.4-enhanced-universal.patch /opt/php-7.4-patched

Либо для древнего PHP 5.6:

sudo ./build/build-patched-php.sh 5.6.40 patches/php-5.6-enhanced-universal.patch /opt/php-5.6-patched

Скрипт сам скачает официальный тарбол с php.net, применит патч, сконфигурирует сборку с поддержкой FPM и скомпилирует бинарник.

/opt/php-7.4-patched/bin/php -v
/opt/php-7.4-patched/bin/php -m

Переключение сайтов: После успешной сборки достаточно в конфигурации нужного пула PHP-FPM или шаблоне панели управления подменить путь к бинарнику на /opt/php-7.4-patched/sbin/php-fpm. Старый системный PHP при этом остаётся нетронутым — у вас всегда есть моментальный откат назад.

Проверить версии PHP на всех серверах (php -v и список FPM-сокетов).

Все версии 8.2+ обновить через apt upgrade.

Если используется HestiaCP — защитить внутренний hestia-php (через скрипт или вручную в php.ini).

Если есть сайты на 5.6, 7.4, 8.0, 8.1 — как минимум применить экстренный apply-hardening.sh.

На боевых легаси-проектах запланировать сборку патча из репозитория.

Открытый репозиторий с патчами и скриптами автоматизации: github.com/Anton-Barinov/php2shell-patches

Исполнители по теме можно найти в разделе - Обновление сайта и модулей под PHP 8

Комментарии (0)

Ещё никто не оставил комментариев к записи.

Написать новый комментарий (для ответа пользуйтесь ссылкой под нужным комментарием)

Корзина покупок

Критические уязвимости в PHP 5.4 - PHP 8.5

В чём суть уязвимости (на пальцах)

Кого это касается?

Сценарий 1. У вас актуальный PHP (8.2, 8.3, 8.4, 8.5)

Как обновиться (Ubuntu / Debian):

Сценарий 2. Если у вас HestiaCP (важный нюанс!)

Сценарий 3. Легаси-стек: PHP 5.6, 7.4, 8.0, 8.1 (EOL)

Вариант А. Быстрый харденинг (если нужно защититься прямо сейчас за 2 минуты)

Вариант Б. Установка патча на PHP 7.4, 8.0, 8.1 и 5.6 (полное решение)

Инструкция по сборке изолированного патченного PHP (на примере 7.4):

Чек-лист для любого администратора сервера с сайтами на сегодня:

Ссылки и материалы: