Критические уязвимости PHP: угрожают ли они вашему сайту и что делать прямо сейчас

21 октября 2026 года команда безопасности PHP (PHP Security Team) выпустила исправления двух критических уязвимостей в самом PHP — CVE-2026-109618 и CVE-2026-109619. Обе получили 9,2 балла по шкале CVSS v4.0 и при определённых условиях позволяют злоумышленнику выполнить код на сервере без авторизации. Исправления вошли в версии PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35.

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

Если хотя бы на один вопрос вы ответили «не знаю», читайте дальше: каждый следующий раздел закрывает один из этих пробелов.

Что такое CVE-2026-109618 и CVE-2026-109619

Это две независимые ошибки в работе ядра PHP с памятью. При определённых условиях они позволяют неавторизованному злоумышленнику выполнить свой код на сервере. Команда PHP заранее предупредила о выпуске 20 октября, а исправления опубликовала 21 октября 2026 года в 14:00 UTC (17:00 по Москве). В отраслевых публикациях пару уязвимостей также называют «PHP2Shell».

Три термина, которые стоит знать. CVE — публичный идентификатор конкретной уязвимости. CVSS — шкала опасности от 0 до 10; всё, что выше 9,0, считается критическим. Удалённое выполнение кода (RCE) означает, что злоумышленник может запустить свой код на вашем сервере из любой точки интернета.

Насколько это опасно для вашего сайта

Достаточно опасно, чтобы обновиться сегодня. По данным PHP Security Team, под угрозой любая установка PHP, которая обрабатывает веб-запросы: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP и LiteSpeed. Наибольший риск — у mod_php: для него продемонстрирована атака, при которой один запрос без авторизации срабатывает ещё до запуска кода приложения.

Если атака удастся, возможны такие последствия:

• выполнение постороннего кода на сервере;
• изменение файлов сайта или внедрение вредоносного содержимого;
• установка бэкдоров и вредоносного ПО для последующих атак;
• утечка данных клиентов, заказов и обращений из базы данных;
• сбои, падение производительности или пометки об опасности в поисковых системах.

Эксплуатируются ли уязвимости уже сейчас?

Ситуация на 23 октября 2026 года такая. В открытом доступе появилось несколько эксплойтов (proof of concept), но, по оценке Rapid7, каждый из них работает только при определённом сочетании операционной системы, версии PHP и веб-сервера. Rapid7 ожидает эксплуатации «в дикой природе», хотя в собственных тестах получил рабочий эксплойт лишь в узких лабораторных условиях; Канадский центр кибербезопасности активной эксплуатации пока не выявил и предупреждает, что ситуация может быстро измениться. Иными словами, не ждите новостей о массовых взломах — обновляйтесь сейчас.

Это не значит, что все сайты на PHP уже взломаны. Успех атаки зависит от версии PHP, настроек сервера и наличия патча.

Какие версии PHP затронуты

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

PHP 8.1 и более старые версии больше не получают обновлений от проекта PHP. Из-за серьёзности уязвимостей команда безопасности выпустила минимальные исходные патчи (бэкпорты) для PHP 7.4, 8.0 и 8.1 — для тех, кто собирает PHP самостоятельно. Многие дистрибутивы Linux и поставщики долгосрочной поддержки выпускают собственные исправленные пакеты. Но такие патчи закрывают только эти две уязвимости и не возвращают старую ветку в число поддерживаемых.

Частая ловушка: когда дистрибутив переносит исправление в свой пакет, номер версии нередко остаётся прежним. Сервер может показывать «8.3.x» и быть защищённым — или нет. Ориентируйтесь на журнал изменений пакета или на сообщение хостинга, а не только на номер версии.

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

Дополнение от 23 октября: session upload progress

23 октября 2026 года PHP Security Team опубликовала информационное уведомление: до следующего планового релиза рекомендуется установить session.upload_progress.enabled=0. Этот параметр уже упоминался как временная мера для CVE-2026-109619; если вы включили его тогда, просто оставьте как есть. Новая проблема (CVE-2026-115560) возникает только при необычном сочетании настроек и кода приложения, поэтому её исправят в обычном цикле выпусков.

WordPress, 1С-Битрикс, Joomla: затронут ли мой сайт?

Ошибка не в самой CMS — но сайт под угрозой, если не обновлена среда выполнения PHP, на которой он работает. Обновление WordPress, модулей 1С-Битрикс, расширений Joomla или MODX эту уязвимость не закрывает.

Представьте PHP как фундамент дома, а CMS — как всё, что построено сверху. Свежий ремонт на втором этаже не устранит трещину в фундаменте. Поэтому задач две, и они разные:

Если сайт работает на 1С-Битрикс, перед сменой ветки PHP сверьтесь с требованиями к версии PHP в документации «1С-Битрикс» и проверьте совместимость сторонних модулей. Если сервер развёрнут на «1С-Битрикс: Веб-окружение» (BitrixVM), обновление PHP выполняется средствами этого окружения или пакетного менеджера — следуйте официальной документации. Для обновления безопасности в пределах той же ветки смена версии модулей обычно не требуется.

Как узнать версию PHP

Проще всего — через панель управления хостингом или админку CMS. Названия пунктов меню могут немного отличаться в зависимости от провайдера и версии панели.

• cPanel: в разделе «Программное обеспечение» откройте MultiPHP Manager (или Select PHP Version) — там видна ветка PHP для каждого домена.
• Plesk: в разделе «Сайты и домены» откройте «Настройки PHP» нужного домена — там указаны версия и обработчик PHP (FPM, CGI и т. д.).
• ISPmanager: версия PHP обычно задаётся в настройках сайта в разделе «Сайты»; точные названия зависят от версии панели.
• WordPress: Инструменты → Здоровье сайта → Информация → Сервер. «Здоровье сайта» также предупредит, если версия PHP устарела.
• 1С-Битрикс: раздел «Проверка системы» в административной панели показывает версию PHP и соответствие требованиям.
• Командная строка: php -v, для FPM — php-fpm -v (в некоторых дистрибутивах php-fpm8.3 -v). CLI и веб-сервер могут использовать разные бинарные файлы PHP, поэтому проверьте оба.

Как обновить версию PHP: пошаговая инструкция с иллюстрациями

На виртуальном хостинге версию PHP обычно можно сменить в пару кликов: в cPanel — через MultiPHP Manager, в Plesk — в «Настройках PHP» домена. Но сначала разделим две операции, которые часто путают:

• Обновление безопасности в пределах ветки (например, 8.3.35 → 8.3.36). Именно оно закрывает эти уязвимости. На виртуальном и управляемом хостинге его выполняет провайдер на сервере — выбирать в панели обычно ничего не нужно.
• Переход на другую ветку (например, 8.1 → 8.3). Так вы уходите с версии, которая больше не поддерживается. Ветку вы выбираете сами в панели, и нужна короткая проверка совместимости.

Какую ветку выбрать? Самую новую из официально поддерживаемых, которую предлагает ваш хостинг. На 23 октября 2026 года поддерживаются 8.2, 8.3, 8.4 и 8.5. Поскольку поддержка PHP 8.2 завершится 31 декабря 2026 года, ветка 8.3 или новее даст вам больше времени. Если вы переходите с 8.1 или более старой версии, проходить каждую промежуточную ветку не нужно — важно, чтобы плагины, модули и шаблон поддерживали целевую версию.

Подготовка: три быстрых шага

1. Сделайте бэкап. Сохраните файлы и базу данных вместе — инструментом резервного копирования в панели или плагином.
2. Проверьте совместимость. Посмотрите минимальную версию PHP и дату последнего обновления у каждого плагина или модуля. Компоненты, которые годами не обновлялись, чаще всего и ломаются.
3. Сначала обновите CMS. Приведите ядро, шаблон и расширения к актуальным версиям, а уже потом меняйте ветку PHP. По возможности отрепетируйте переход на тестовой копии сайта.

Смена версии PHP в cPanel

1. Войдите в cPanel и в разделе «Программное обеспечение» откройте MultiPHP Manager.
2. Отметьте галочкой домен, для которого нужно сменить версию (1).
3. Выберите целевую версию в выпадающем списке, например PHP 8.3 (2).
4. Нажмите «Применить» (3). Обычно изменения вступают в силу за несколько секунд.

На некоторых серверах вместо этого раздела есть Select PHP Version (PHP Selector от CloudLinux). Принцип тот же: выбираете версию и сохраняете. Расширения PHP там настраиваются отдельно для каждой версии, поэтому после переключения проверьте, что нужные сайту расширения (например, intl, imagick, zip) включены и в новой версии.

Смена версии PHP в Plesk

1. Откройте «Сайты и домены», найдите свой домен и нажмите PHP (в некоторых версиях — «Настройки PHP») (1).
2. В списке «Версия PHP» выберите нужный релиз (2). Обработчик PHP (FPM, CGI и т. д.) без особой причины не меняйте.
3. Сохраните кнопкой «Применить» или «ОК» (3).

Проверка новой версии в WordPress

Убедитесь, что изменение действительно применилось к сайту. Если используете плагин кеширования, сначала очистите кеш.

1. В консоли откройте Инструменты → Здоровье сайта (1).
2. Перейдите на вкладку «Информация» (2).
3. Разверните раздел «Сервер» и посмотрите строку «Версия PHP» (3). Для ветки 8.3 исправление от 21 октября есть в версии 8.3.36 и выше.

Если у вас собственный VPS или сервер

На своём сервере PHP обновляется через пакетный менеджер операционной системы. Команды ниже — примеры; названия пакетов зависят от дистрибутива и используемого репозитория PHP.

# Узнать текущую версию (CLI)
php -v

# Debian / Ubuntu — обновление безопасности в пределах ветки
sudo apt update
sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common
sudo systemctl restart php8.3-fpm

# RHEL / AlmaLinux / Rocky
sudo dnf upgrade "php*"
sudo systemctl restart php-fpm

# Если используется Apache mod_php, перезапустите и веб-сервер
sudo systemctl restart apache2   # в RHEL-подобных системах: httpd

Не пропускайте перезапуск: пока старые воркеры PHP остаются в памяти, патч не работает. Убедитесь, что ваш репозиторий действительно содержит исправления от 21 октября, — для этого посмотрите журнал изменений пакета (в Debian/Ubuntu, например, apt changelog php8.3-fpm). Для перехода на другую ветку новую версию устанавливают параллельно и переключают на неё веб-сервер или пул FPM; детали зависят от дистрибутива.

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

Белый экран или ошибка «500 Internal Server Error» после обновления — ситуация поправимая. Но первым порывом не должен быть откат на старую версию PHP: если она не исправлена, вы снова откроете дверь злоумышленникам. Действуйте в таком порядке:

1. Найдите причину. Журнал ошибок PHP или файл debug.log в WordPress обычно уже в первых строках называет проблемный плагин или шаблон.
2. Отключите виновника. Нет доступа к админке? Переименуйте папку плагина через файловый менеджер (например, plugin-name → plugin-name-off) — WordPress перестанет его загружать.
3. Обновите или замените компонент. Установите свежую версию от разработчика или перейдите на аналог, который поддерживает новую версию PHP.
4. При серьёзной поломке восстановите бэкап. Верните резервную копию, сделанную до обновления, — но оставьте новую версию PHP и решайте проблему на тестовой копии.

План действий: защищаем сайт шаг за шагом

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

1. Определите версию PHP — ветку и, если возможно, точный релиз.
2. Проверьте сообщения хостинга — страницу статуса, почту или поддержку.
3. Убедитесь, что исправление установлено — 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 или новее либо письменное подтверждение исправленного пакета.
4. Сделайте свежий бэкап и проверьте восстановление.
5. Проведите короткую проверку совместимости — обязательно при смене ветки, обычно не нужно при обновлении внутри ветки.
6. Установите обновление под контролем — в спокойное время, с перезапуском PHP-FPM или веб-сервера.
7. Проверьте работу сайта по чек-листу ниже.
8. Поищите следы взлома — недавно изменённые файлы, новых администраторов, подозрительные запросы в логах доступа, неожиданные исходящие соединения.

Обновление безопасности в пределах одной ветки не требует недельного тестирования. Проверка совместимости не должна становиться причиной откладывать критический патч на несколько дней.

Временные меры для администраторов серверов

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

• Для CVE-2026-109619: установите session.upload_progress.enabled=0 там, где приложения не смогут это переопределить (php.ini, пул FPM или конфигурация сервера), и перезапустите все воркеры. Не полагайтесь на ini_set() или .user.ini. В PHP 8.5 параметр fatal_error_backtraces=0 дополнительно закрывает один из подтверждённых путей.
• Для CVE-2026-109618: уменьшите post_max_size (8M, если загрузка файлов не нужна, 32M — если нужна) и держите upload_max_filesize ниже этого значения. Ограничьте размер запроса, число полей и заголовков на уровне веб-сервера или прокси.
• Скрывать ошибки через display_errors или @ бесполезно. Фатальные ошибки и тайм-ауты, которые может вызвать атакующий, нужно устранить.

Чек-лист после обновления

Подозрение на взлом: что делать

Патч закрывает дверь, но не выгоняет тех, кто уже успел войти. Если вы видите незнакомые файлы, неизвестных администраторов, спам-страницы или редиректы, действуйте как при инциденте:

• Сохраните логи и сделайте снимок сервера до любых изменений — они понадобятся, чтобы понять, что произошло.
• Смените все пароли (панель хостинга, база данных, администраторы CMS, SFTP) и перевыпустите API-ключи и секреты, хранящиеся на сервере.
• Восстановите чистую резервную копию, сделанную до предполагаемого взлома, и обновите PHP до того, как сайт снова станет доступен.
• Если могли пострадать персональные данные, проверьте свои обязанности по законодательству. Для операторов персональных данных в России 152-ФЗ предусматривает уведомление Роскомнадзора об инциденте с утечкой в течение 24 часов, а о результатах расследования — в течение 72 часов. В других странах действуют свои правила; при сомнениях проконсультируйтесь с юристом.

Кто отвечает за обновление: хостинг или вы?

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

Это типичное распределение; точные границы определяют договор и тариф. Если сомневаетесь, задайте хостингу вопросы:

• Содержит ли PHP на моём сервере исправления безопасности от 21 октября 2026 года и когда они были установлены?
• Поддерживается ли ещё моя ветка PHP? Если нет — когда и как лучше перейти?
• Перезапускались ли воркеры PHP после обновления?
• Как часто делаются бэкапы, сколько хранятся и как запросить восстановление?

Чем опасны устаревшие версии PHP

Версия PHP с завершённой поддержкой (end of life) не получает официальных исправлений для новых уязвимостей. Даже если сегодня для неё выпустили разовый патч, следующая уязвимость может так и остаться открытой.

Модель поддержки PHP проста: два года активной поддержки, затем два года — только критические исправления безопасности, после чего ветка уходит на покой. Поддержка PHP 8.2 завершится 31 декабря 2026 года. Версия 8.2.35 защищает от этих двух уязвимостей, но переход на 8.3 или новее стоит запланировать в ближайшие два месяца.

Бэкпорты от хостинг-провайдеров и дистрибутивов — ценная временная мера. Но они закрывают только конкретные уязвимости, а не остальные известные проблемы, не дают прироста производительности и не решают растущую несовместимость с современными модулями. Надёжное решение — поддерживаемая ветка.

Как выбрать хостинг, который серьёзно относится к безопасности

Подобные инциденты показывают: процессы безопасности у хостинга так же важны, как цена и объём диска. Сравнивая провайдеров, спросите:

Как тарифы хостинга Atak Domain соответствуют этим критериям

Эти критерии можно сопоставить с тарифами веб-хостинга Atak Domain. Данные ниже взяты из описания возможностей на странице продукта и не являются заявлением о мерах в связи с этим конкретным инцидентом.

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

Затрагивает ли эта уязвимость PHP мой сайт?

Если сайт работает на PHP (WordPress, 1С-Битрикс, Joomla, MODX и т. д.) и PHP на сервере ещё не содержит исправлений от 21 октября 2026 года — да. Версии PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 или исправленный пакет провайдера закрывают обе уязвимости. Риск не означает, что сайт уже взломан.

Нужно ли обновлять PHP немедленно?

Да. PHP Security Team призывает обновиться немедленно. Обновление безопасности в пределах ветки (например, с 8.3.35 до 8.3.36) редко вызывает проблемы совместимости. На виртуальном хостинге его устанавливает провайдер — ваша задача убедиться, что это сделано.

Если WordPress обновлён, PHP тоже в безопасности?

Нет. Обновления WordPress, шаблонов и плагинов не исправляют среду выполнения PHP. PHP нужно обновлять на сервере отдельно. Это разные уровни, и у каждого свои обновления.

Обновит ли хостинг PHP автоматически?

На виртуальном и управляемом хостинге — как правило, да, но сроки и объём работ у провайдеров разные. На неуправляемом VPS или выделенном сервере это ваша задача. Надёжнее всего получить от хостинга письменное подтверждение.

Может ли смена версии PHP сломать сайт?

Обновление внутри ветки — редко. Переход на другую ветку (например, с 8.1 на 8.3) может нарушить работу старых плагинов или модулей. Сделайте бэкап, по возможности проверьте всё на тестовой копии и пройдите чек-лист после обновления.

PHP 8.2 ещё безопасен?

PHP 8.2.35 закрывает эти две уязвимости. Однако поддержка PHP 8.2 завершится 31 декабря 2026 года, и после этого новые уязвимости исправляться не будут. Запланируйте переход на 8.3 или новее в ближайшие недели.

Защитит ли SSL-сертификат?

Нет. SSL шифрует трафик между браузером и сервером, но не исправляет ошибку в PHP на этом сервере. Вредоносный запрос может прийти и по защищённому соединению. WAF и антивирусный сканер снижают риск, но не заменяют обновление.

Нужно ли отключать сайт?

Как правило, нет. Главное — обновить PHP и убедиться, что исправление установлено. Если у вас критичный сервер, который пока нельзя обновить (особенно с mod_php), имеет смысл ограничить к нему доступ до обновления. Решение зависит от вашей оценки рисков.

Что делать владельцу VPS?

Обновите PHP из репозитория безопасности дистрибутива (или соберите релиз от 21 октября из исходников), перезапустите PHP-FPM и веб-сервер, затем проверьте результат через php -v и журнал изменений пакета. Если используется несколько версий PHP или контейнеров, проверьте каждую.

Итог: сначала обновите, потом проверьте

CVE-2026-109618 и CVE-2026-109619 — редкий случай уязвимостей в самом PHP, которые могут привести к удалённому выполнению кода. Хорошая новость: исправления уже вышли для всех поддерживаемых веток.

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

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

Источники

• PHP: Security advisory — Critical remote code execution vulnerabilities (21.10.2026)
• PHP: Informational advisory — Session upload progress (23.10.2026)
• PHP: Supported Versions
• Rapid7: анализ CVE-2026-109618 и CVE-2026-109619
• Canadian Centre for Cyber Security: Alert AL26-026
• GitHub Security Advisory GHSA-w8hw-w9fx-j79w · GHSA-6wmf-4rv5-p3rp