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

21 октября 2026 года команда PHP выпустила внеплановые обновления безопасности: PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Они закрывают две критические уязвимости — CVE-2026-109618 и CVE-2026-109619. Обе позволяют злоумышленнику без логина и пароля выполнить произвольный код на сервере, то есть фактически получить контроль над сайтом. Обе оценены в 9,2 балла по CVSS v4.0 — это уровень «критический».

Если ваш сайт работает на WordPress, 1С-Битрикс, Joomla, OpenCart, MODX или любой другой PHP-системе, эта новость касается вас напрямую. Ниже — простым языком: что случилось, как проверить свой сайт и что сделать по шагам.

Что произошло

Сначала команда PHP заранее предупредила в рассылке php.announce о готовящемся «критическом выпуске безопасности» и назначила его на среду, 21 октября 2026 года, 14:00 UTC (17:00 по Москве). Такие предупреждения выпускают редко — обычно, когда проблема действительно серьёзная и администраторам нужно подготовиться.

21 октября вышли сами исправления. В официальном бюллетене на php.net описаны две проблемы:

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) — удалённое выполнение кода через повреждение памяти при нехватке памяти (OOM). Если PHP прерывается из-за нехватки памяти в момент, когда внутренние данные запроса ещё не до конца инициализированы, при последующей очистке он может принять «битые» данные за корректные.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) — удалённое выполнение кода через «устаревшее» глобальное состояние (use-after-free). Данные одного запроса могут пережить освобождение памяти, и следующий запрос, обработанный тем же рабочим процессом, успеет их использовать.

22 октября координационный центр CERT/CC опубликовал собственную заметку VU#763488 с тем же описанием: уязвимы версии PHP ниже 8.2.35, 8.3.36, 8.4.27 и 8.5.12, атака выполняется специально сформированным HTTP-запросом, аутентификация не нужна.

Важная деталь из бюллетеня php.net: полноценного обходного решения нет, единственный надёжный путь — обновиться.

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

По данным php.net, под угрозой все установки PHP, которые обслуживают веб-запросы:

• PHP-FPM (самая распространённая схема с nginx);
• Apache с модулем mod_php;
• php-cgi;
• FrankenPHP;
• LiteSpeed.

Наибольший риск команда PHP видит для Apache с mod_php: продемонстрирован эксплойт, при котором атака срабатывает от неавторизованного запроса ещё до того, как начнёт выполняться код самого сайта. Это значит, что не спасают ни свежая версия WordPress, ни «правильные» плагины — уязвим сам интерпретатор.

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

И ещё: PHP 8.2 перестанет получать исправления безопасности 31 декабря 2026 года. Если сайт на 8.2 — переход на 8.3+ стоит запланировать уже сейчас.

Для малого бизнеса в Москве и Зеленограде типичная картина такая: сайт на WordPress или Битрикс, сделанный несколько лет назад, стоит на виртуальном хостинге, и никто не помнит, какая там версия PHP. Именно такие сайты чаще всего и оказываются под ударом при массовом сканировании.

Как проверить свой сайт

1. Узнайте версию PHP.

• В панели хостинга (ISPmanager, cPanel, Plesk, панели Beget, Timeweb, REG.RU и т. п.) обычно есть раздел «Версия PHP» для каждого сайта.
• В WordPress: «Инструменты → Здоровье сайта → Информация → Сервер».
• В 1С-Битрикс: «Настройки → Инструменты → Проверка системы» или «Информация о PHP».
• Если есть доступ по SSH: php -v (но помните, что у сайта может быть другая версия, чем у консоли).

2. Сравните с безопасными версиями. Безопасны: 8.5.12+, 8.4.27+, 8.3.36+, 8.2.35+. Всё, что ниже, — уязвимо, если провайдер не установил бэкпорт.

3. Уточните у провайдера про бэкпорты. Дистрибутивы Linux и LTS-поставщики получили патчи заранее. Поэтому версия вида 8.3.6-ubuntu… может быть уже исправлена, хотя номер формально ниже. Напишите в поддержку хостинга и спросите прямо: «Закрыты ли CVE-2026-109618 и CVE-2026-109619 для моего сайта?»

4. Выясните схему запуска. Если в панели указано «Apache-модуль» или mod_php — это сценарий максимального риска, обновляться нужно в первую очередь.

Что делать: пошаговый план

• Сделайте резервную копию файлов и базы данных. Обновление PHP иногда ломает старые плагины и шаблоны — копия позволит быстро откатиться.
• Обновите PHP до 8.5.12, 8.4.27, 8.3.36 или 8.2.35 (или установите пакет с бэкпортом от дистрибутива). На виртуальном хостинге это часто одна кнопка в панели; на VPS — обновление пакетов и перезапуск PHP-FPM или Apache.
• Перезапустите все рабочие процессы PHP. Уязвимость CVE-2026-109619 связана с состоянием, которое переживает запросы внутри одного процесса, поэтому старые процессы должны быть остановлены.
• Если сайт на PHP 7.4/8.0/8.1 — планируйте переход на поддерживаемую версию. Для WordPress это обычно обновление ядра, темы и плагинов; для Битрикс — обновление платформы и проверка модулей.
• Если обновиться прямо сейчас невозможно, CERT/CC перечисляет меры, снижающие риск по CVE-2026-109618: задать лимиты на размер тела запроса, число переменных и частей multipart на уровне веб-сервера; держать post_max_size низким (8M без загрузки файлов, 32M — с загрузкой), а upload_max_filesize — ниже него. Для PHP 8.5 предлагается fatal_error_backtraces=0. Но это временные меры: php.net прямо пишет, что полных обходных решений нет.
• Проверьте сайт на признаки взлома: новые незнакомые администраторы, изменённые .php-файлы в папках загрузок, подозрительные редиректы, рассылка спама с вашего домена, всплески нагрузки.
• Смените пароли от админки, FTP/SFTP, базы данных и панели хостинга, если есть хоть малейшие сомнения.
• Настройте мониторинг: доступность, изменения файлов, уведомления от хостинга. Следующая подобная уязвимость — вопрос времени.

Как это решаем мы в WeCre8

Скажем честно: большинство сайтов, которые мы делаем сейчас, работают на нашей собственной CMS на Next.js и на нашем хостинге. PHP там не используется, поэтому эти конкретные CVE их не затрагивают. При этом для всех сайтов на нашей CMS и хостинге мы сами следим за бюллетенями безопасности, обновляем зависимости и мониторим работу — клиенту не нужно ничего делать.

Но у многих наших клиентов и тех, кто к нам обращается, есть «исторические» сайты на WordPress или 1С-Битрикс. Именно для них эта новость критична. Здесь мы можем:

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

FAQ

У меня сайт на WordPress, и я обновил все плагины. Я в безопасности?

Нет, если не обновлён сам PHP. Уязвимости находятся в интерпретаторе, а не в WordPress, и для mod_php атака возможна ещё до запуска кода сайта.

Мой хостинг пишет, что у меня PHP 8.3. Этого достаточно?

Важна точная версия: нужна 8.3.36 или новее, либо пакет дистрибутива с бэкпортом. Уточните у поддержки, закрыты ли CVE-2026-109618 и CVE-2026-109619.

Сайт на PHP 7.4, обновлять страшно — всё сломается.

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

Есть ли признаки, что уязвимости уже используют?

В бюллетенях php.net и CERT/CC упоминается продемонстрированный эксплойт для mod_php. Данных о массовых атаках в этих источниках нет, но после публикации деталей сканирование обычно начинается быстро — не откладывайте.

Касается ли это сайтов на вашей CMS?

Нет, они работают на Next.js без PHP. Но у Next.js в октябре были свои уязвимости — о них мы написали отдельно, и наши сайты обновляем в рамках поддержки.

Нужна помощь?

Если у вас сайт на WordPress, Битрикс или другой PHP-системе и вы не уверены, что он обновлён, — напишите нам. Проверим версию PHP, обновим, настроим резервное копирование и мониторинг. Подробнее о поддержке — на странице /services/support.