Уязвимости в PHP: как это случилось и что делать владельцам сайтов

21 октября 2026 года разработчики PHP выпустили внеплановые версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Они закрывают две критические уязвимости — CVE-2026-109618 и CVE-2026-109619, вместе их называют PHP2Shell. Обе позволяют выполнить чужой код на сервере без логина и пароля, у каждой оценка 9,2 из 10 по CVSS 4.0.

Если сайт, личный кабинет или корпоративный портал работает на PHP, задача на сегодня одна: проверить версию интерпретатора и обновить его. Обновление CMS, плагинов или самого приложения здесь не помогает — дыра сидит уровнем ниже, в ядре языка.

Ситуацию осложняют две детали. Описание уязвимостей и рабочий эксплойт попали в открытый доступ раньше, чем вышли исправления. А ветки PHP 8.1 и старше официальных патчей не получат вовсе — а на них до сих пор крутится немало legacy-систем.

Как это случилось: хронология

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

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

О двух уязвимостях простыми словами

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

CVE-2026-109618 — повреждение памяти при её нехватке. Когда процессу PHP не хватает оперативной памяти, интерпретатор аварийно прерывает работу. Если это случилось в момент, когда данные запроса подготовлены лишь наполовину, код очистки принимает недостроенные структуры за корректные. Через эту путаницу можно добиться выполнения своего кода.

CVE-2026-109619 — «чужое» состояние от прошлого запроса. PHP хранит часть служебных данных глобально. После обработки запроса память освобождается, но ссылка на неё остаётся — и следующий запрос, попавший в тот же рабочий процесс, может воспользоваться устаревшими данными. Один из подтверждённых путей атаки идёт через механизм отслеживания прогресса загрузки файлов в сессии (session.upload_progress), на PHP 8.5 — ещё и через трассировку фатальных ошибок.

В журнале изменений PHP обе правки записаны одной строкой: защита от повреждения состояния при аварийном выходе. Короткая запись не значит мелкую проблему. Удалённое выполнение кода — это полный контроль над сайтом и доступ ко всему, что видит веб-сервер: базе данных, файлам, ключам интеграций.

Чьи сайты под угрозой

Под риском любая установка PHP, которая обслуживает веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Неважно, на чём собран сайт — 1С-Битрикс, WordPress, Laravel, Symfony или самописный код. CERT-EU отдельно предупреждает: уязвимыми могут оказаться и коммерческие продукты, которые используют PHP «под капотом», даже если вы об этом не знаете.

Риск зависит и от того, как PHP подключён к веб-серверу. Самый высокий — у Apache с mod_php: для него разработчики показали эксплойт, который срабатывает ещё до выполнения кода приложения. Для PHP-FPM полного эксплойта не публиковали, но анализ исходников считает его уязвимым. Ждать доказательств для FPM — плохая стратегия: атакующие уже работают по свежим описаниям.

Если сайт на виртуальном хостинге, обновление обычно делает хостер. Крупные провайдеры (SiteGround, InMotion) сообщили, что закрыли уязвимости в первые сутки. На собственном VPS, выделенном сервере, в Kubernetes или Docker ответственность на вас или на вашем подрядчике.

Что делать владельцу сайта: план на 48 часов

Главное действие — обновить PHP до исправленной версии и перезапустить все рабочие процессы. Всё остальное либо готовит обновление, либо страхует от последствий.

1. Определите ответственного. Хостер, подрядчик по поддержке или своя ИТ-команда — у каждой системы должен быть конкретный человек, который отчитается о версии.

2. Составьте список всех систем на PHP. Не только основной сайт: личные кабинеты, внутренние порталы, API, тестовые стенды, старые лендинги. Забытые тестовые копии обычно обновляют последними, а взламывают первыми.

3. Узнайте версию той сборки PHP, которая отвечает на веб-запросы. На одном сервере консольный PHP и PHP-FPM могут быть разных версий.

4. Обновите до 8.5.12, 8.4.27, 8.3.36 или 8.2.35 — через пакеты дистрибутива или панель хостинга. В Docker пересоберите образы и проверьте версию внутри контейнера.

5. 5. Перезапустите все воркеры PHP-FPM и Apache. Без перезапуска сервер продолжит работать на старом коде.

6. 6. Для PHP 8.1 и ниже включите временные меры и бэкпорт (разделы ниже), параллельно оцените миграцию.

7. 7. Проверьте сервер на признаки взлома за период с 20 октября и сохраните отчёт о проделанной работе.

порядок действий · 6 шагов, 1 развилка

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

Если обновиться прямо сейчас нельзя

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

Против CVE-2026-109619:

• выставить session.upload_progress.enabled = 0 в php.ini, конфигурации пула FPM или веб-сервера — там, где настройка применяется до разбора запроса; ini_set() и .user.ini для этого не подходят;

• на PHP 8.5 дополнительно выставить fatal_error_backtraces = 0;

• убрать устаревшие и невалидные настройки, которые на каждом запросе выводят предупреждения до инициализации; скрыть их через display_errors недостаточно.

• Против CVE-2026-109618:

• держать небольшой post_max_size: 8M, если сайт не принимает файлы, 32M — если принимает; upload_max_filesize ниже него;

• ограничить размер и сложность запросов на уровне nginx, прокси или WAF: размер тела, число полей и частей multipart, число заголовков;

• снять ограничение memory_limit внутри PHP можно только вместе с лимитом памяти на уровне контейнера или cgroup — иначе один запрос положит сервер. Это задача для администратора, не для правки «на глаз».

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

Сайт на PHP 8.1 или старше: самый тяжёлый случай

Для веток 8.1, 8.0 и 7.4 официального релиза не будет. Команда безопасности PHP выложила в репозиторий php-src только минимальные исправления исходников — их нужно собрать самостоятельно. Это временная мера, а не поддерживаемая версия: номер версии после сборки не меняется, и проверить, стоит ли патч, можно только по коммиту в выводе php -i.

Реалистичных путей три:

1. Пакеты от дистрибутива или LTS-вендора. Дистрибутивы Linux и коммерческие поставщики продлённой поддержки получили патчи заранее и могут выпустить свои бэкпорты. Уточните у вендора, а не надейтесь на автообновление. Отдельно: популярный репозиторий remirepo в день релиза обновлений не получил.

2. Сборка из веток безопасности php-src. Требует компетенций в сборке PHP и регрессионного тестирования. Подходит как мост на несколько недель.

3. Миграция на PHP 8.4 или 8.5. Единственное решение, которое не придётся повторять. Ветка 8.2 перестаёт получать патчи 31 декабря 2026 года, так что переезд на неё — отсрочка на два месяца.

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

Как понять, что сайт уже взломали

Обновление закрывает дверь, но не выгоняет тех, кто успел войти. Эксплойт был публичным минимум за несколько часов до патча, а атаки watchTowr фиксирует с 22 октября. Поэтому после обновления стоит проверить сервер за период с 20 октября.

На что смотреть в первую очередь:

• новые или изменённые PHP-файлы в каталогах загрузок, кэша и временных файлов — там их быть не должно; сравните с репозиторием или резервной копией;

• незнакомые задачи в cron и новые системные пользователи;

• новые администраторы в CMS или изменённые права у существующих;

• исходящие соединения с веб-сервера на неизвестные адреса, рост нагрузки на CPU без роста трафика (типичный признак майнера);

• аномалии в логах веб-сервера: всплеск крупных multipart-запросов и ошибок нехватки памяти PHP;

• жалобы и сигналы извне: редиректы на сторонние сайты, предупреждения браузеров и Яндекс.Вебмастера о заражении.

Если хоть один признак подтвердился — сайт считается скомпрометированным. Правильный порядок: изолировать сервер, сохранить логи, сменить все пароли и ключи (база данных, API, SMTP, платёжные шлюзы), развернуть систему с чистого образа, а не «вычищать» вредоносные файлы вручную. Если на сайте есть персональные данные клиентов, подключите юристов: утечку может потребоваться уведомить в Роскомнадзор.

Что поручить подрядчику: готовый текст задачи

Собственнику не нужно разбираться в настройках PHP-FPM. Нужно поставить задачу так, чтобы её нельзя было закрыть формально. Текст ниже можно отправить хостеру, подрядчику по поддержке или внутренней ИТ-команде как есть.

Тема: Срочно — уязвимости PHP CVE-2026-109618 и CVE-2026-109619 (PHP2Shell)

Прошу до [дата, время]:

1. Составить список всех серверов и контейнеров с PHP, которые
    обрабатывают веб-запросы (продакшн, тест, админки, API).
2. По каждому указать текущую версию именно веб-сборки PHP
    (php-fpm -v / mod_php), а не только CLI.
3. Обновить до 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 или выше.
    Перезапустить все воркеры.
4. Для версий 8.1 и ниже — описать, чем закрыта уязвимость
    (пакет вендора, бэкпорт с номером коммита, временные меры)
    и дать план миграции со сроками.
5. До завершения обновления — отключить session.upload_progress
    и ограничить размер запросов на прокси.
6. Проверить серверы на признаки компрометации с 20 октября
    (новые PHP-файлы, cron, пользователи, исходящие соединения).

В отчёте: таблица «сервер — версия до — версия после — дата»,
результат проверки на компрометацию, открытые риски.

Принимайте работу по отчёту, а не по фразе «всё обновили». Самая частая ошибка — обновлённый CLI при старом PHP-FPM: в консоли администратор видит свежую версию, а сайт продолжает работать на уязвимой. Если своей команды нет или задачу некому поставить, этот объём закрывает техническая поддержка ПО iFellow, а регулярный контроль версий и зависимостей — практика DevSecOps.

Частые вопросы

Нужно ли обновлять 1С-Битрикс или WordPress?

Нет, уязвимости в самом PHP, а не в CMS. WordPress.org подтвердил, что отдельного обновления движка не будет. Исправление одно — новая версия PHP на сервере.

Как узнать версию PHP своего сайта?

Спросить хостера или подрядчика, посмотреть в панели хостинга или в разделе «Проверка системы» админки CMS. Важна версия, которая обслуживает сайт, а не та, что выводит консоль сервера.

Сайт на виртуальном хостинге — я в безопасности?

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

Достаточно ли временных мер из бюллетеня?

Нет. Разработчики PHP прямо называют обновление единственным полным решением. Временные меры перекрывают только известные пути атаки.

Сайт продолжает работать нормально. Значит, его не взломали? Не значит. Злоумышленнику выгоднее оставаться незаметным: красть данные, рассылать спам, майнить. Проверка на признаки компрометации нужна даже при стабильной работе.

Мы на PHP 8.2 и уже обновились до 8.2.35. Что дальше? Планировать переход на 8.4 или 8.5: патчи безопасности для ветки 8.2 закончатся 31 декабря 2026 года.