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

21 октября 2026 года разработчики PHP выпустили срочные исправления двух критических уязвимостей, которые позволяют удалённо выполнить код на сервере без логина и пароля. Под угрозой почти любой сайт на PHP: корпоративные сайты, интернет-магазины, личные кабинеты на 1С-Битрикс, WordPress и самописных системах. Разбираемся, что именно нашли, чем это грозит бизнесу, как обновиться и как снизить риск, если обновление прямо сейчас невозможно.

Содержание

• Что произошло
• Суть уязвимостей простыми словами
• Чем это опасно для сайта и бизнеса
• Кто под угрозой
• Как проверить версию PHP на своём сайте
• Как обновить PHP до исправленной версии
• Что делать, если обновиться сразу нельзя
• Если на сервере PHP 8.1 или старее
• Переход на более новую версию PHP
• Чек-лист для владельца сайта
• Частые вопросы

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

20 октября команда безопасности PHP заранее предупредила о готовящемся срочном выпуске, а на следующий день вышли исправленные версии всех поддерживаемых веток. Обеим уязвимостям присвоена оценка 9,2 по шкале CVSS 4.0, это уровень критической опасности.

Разработчики прямо указывают, что полноценной защиты, кроме обновления, не существует. Временные меры лишь закрывают известные пути атаки.

Суть уязвимостей простыми словами

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

CVE-2026-109618: сбой при нехватке памяти

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

CVE-2026-109619: остатки предыдущего запроса

Один процесс PHP обычно обслуживает много запросов подряд. Выяснилось, что некоторые служебные данные запроса могут пережить его завершение, хотя память под них уже освобождена. Следующий запрос, попавший в тот же процесс, может обратиться к этим устаревшим данным раньше, чем они будут сброшены. Подтверждённый путь атаки проходит через механизм отслеживания хода загрузки файлов в сессиях (session.upload_progress), но разработчики не исключают и других вариантов.

Чем это опасно для сайта и бизнеса

Удалённое выполнение кода означает, что атакующий получает возможность запускать на сервере свои команды с правами веб-сервера. На практике это открывает путь к таким последствиям:

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

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

Кто под угрозой

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

Отдельно стоит обратить внимание на серверы, где PHP установлен из сторонних репозиториев. Например, популярный репозиторий Remi для CentOS, Rocky Linux и AlmaLinux поддерживается энтузиастами, и в день выхода исправлений обновлённых пакетов в нём не было. Владельцам таких серверов пришлось несколько дней защищаться временными мерами.

Как проверить версию PHP на своём сайте

Есть несколько способов, выбирайте доступный вам:

• в панели хостинга: раздел с настройками PHP или информацией о сайте;
• в CMS: в 1С-Битрикс версия видна в разделе Настройки, Инструменты, Проверка системы; в WordPress в разделе Инструменты, Здоровье сайта, Информация;
• на сервере через консоль командой:

php -v

Учтите, что консольный PHP и PHP, который обслуживает сайт, иногда отличаются. Самый надёжный способ узнать версию именно для сайта: временно разместить файл с вызовом phpinfo() и открыть его в браузере. После проверки файл обязательно удалите, так как он раскрывает много сведений о сервере.

Ваша установка защищена, если версия не ниже указанной в таблице для своей ветки:

Как обновить PHP до исправленной версии

Виртуальный хостинг

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

Свой сервер или VPS

Обновление внутри той же ветки (например, с 8.2.34 на 8.2.35) обычно проходит без последствий для сайта: такие выпуски содержат только исправления. Перед обновлением сделайте снимок сервера в панели провайдера или хотя бы резервную копию файлов и баз.

Для систем на базе Rocky Linux, AlmaLinux и других дистрибутивов семейства RHEL:

dnf clean metadata
dnf upgrade -y 'php*'
systemctl restart httpd
php -v

Если PHP работает через PHP-FPM, вместо Apache перезапустите службу FPM. Название службы зависит от сборки, чаще всего это php-fpm.

Для Debian и Ubuntu:

apt update
apt install --only-upgrade 'php*'
systemctl restart apache2

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

Серверы на BitrixVM

На виртуальной машине 1С-Битрикс пакеты можно обновить через меню BitrixVM, пункт обновления сервера. Учтите, что этот пункт обновляет не только PHP, но и остальные компоненты: MySQL, nginx, redis. Если нужно обновить только PHP внутри текущей ветки, удобнее воспользоваться командами из примера выше.

Что делать, если обновиться сразу нельзя

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

Отключить отслеживание хода загрузки файлов

Это основная мера против CVE-2026-109619. Функция показывает индикатор загрузки файла через сессию и почти никогда не используется: ни 1С-Битриксу, ни WordPress она не нужна. Настройку нужно задать на уровне сервера, а не из кода сайта. Изменение через ini_set() или файл .user.ini не помогает, так как к моменту их чтения запрос уже разобран.

session.upload_progress.enabled = 0

Ограничить размер запросов

Против CVE-2026-109618 помогает уменьшение максимального размера запроса. Ориентиры такие: 8 МБ для сайтов, где файлы не загружаются, и 32 МБ, если загрузка нужна. Предельный размер одного файла должен быть меньше размера всего запроса. Если сайт получает большие объёмы данных, например через импорт каталога или парсер, лимит подбирается с учётом реальных потребностей.

post_max_size = 32M
upload_max_filesize = 10M

Дополнительно имеет смысл ограничить размер тела запроса, количество заголовков и полей формы на уровне веб-сервера или прокси (nginx, Apache). Эти ограничения должны действовать и для запросов без указанной длины.

Пример файла с временной защитой

На серверах семейства RHEL удобно вынести все временные настройки в отдельный файл, чтобы потом легко его найти и удалить. Имя начинается с zz, чтобы файл подключался последним и его значения имели приоритет:

cat > /etc/php.d/zz-cve-2026-109618.ini <<'EOF'
session.upload_progress.enabled = 0
post_max_size = 32M
upload_max_filesize = 10M
EOF
apachectl -t && systemctl restart httpd
php -i | grep -E 'upload_progress.enabled|post_max_size|upload_max_filesize'

Другие меры из рекомендаций разработчиков

Как вернуть настройки после обновления

После установки исправленной версии ограничения по размеру запросов можно снять, а отключение session.upload_progress оставить: функция не нужна большинству сайтов, и выключенной она только сокращает поверхность атаки.

sed -i '/post_max_size\|upload_max_filesize/d' /etc/php.d/zz-cve-2026-109618.ini
apachectl -t && systemctl restart httpd

После этого проверьте загрузку файлов в административной панели сайта.

Если на сервере PHP 8.1 или старее

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

Варианты действий:

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

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

Переход на более новую версию PHP

Обновление внутри ветки закрывает текущие уязвимости, но у каждой ветки есть срок жизни. Ветка 8.2 получает исправления безопасности только до 31 декабря 2026 года, после этого новые уязвимости в ней закрываться не будут. Поэтому владельцам сайтов на 8.2 стоит запланировать переход уже сейчас.

Подготовка к переходу

1. Сделайте полную резервную копию: снимок сервера, файлы сайта, дамп всех баз данных.
2. Проверьте требования CMS. Для 1С-Битрикс важна версия главного модуля, для WordPress версия ядра, тем и плагинов. Посмотрите, заявлена ли поддержка нужной ветки PHP у используемых решений из маркетплейса.
3. Обновите CMS и модули до актуальных версий ещё на старой ветке PHP.
4. Включите запись предупреждений об устаревших функциях в журнал и несколько дней понаблюдайте за ним: он подскажет, какой код может перестать работать.
5. По возможности проверьте сайт на тестовой копии сервера с новой версией PHP.

Как переключить версию на сервере

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

dnf module reset -y php
dnf module enable -y php:remi-8.3
dnf distro-sync -y 'php*'
systemctl restart httpd
php -v

После смены ветки проверьте, что на месте остались все нужные расширения и собственные файлы настроек в каталоге /etc/php.d/:

php -m
ls /etc/php.d/

Проверка после перехода

• главная страница, каталог, карточки товаров или услуг открываются без ошибок;
• работает вход в административную панель и сохранение изменений;
• формы отправляют заявки, письма доходят;
• работают загрузка файлов, поиск, корзина и оплата, если они есть;
• выполняются задания по расписанию: обмен с 1С, импорт, парсеры, рассылки;
• в журнале ошибок веб-сервера нет новых фатальных ошибок.

Если что-то пошло не так

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

На рабочем сервере также стоит проверить, не включён ли отладчик Xdebug. Он нужен только при разработке, замедляет сайт и увеличивает поверхность атаки:

php -m | grep -i xdebug

Чек-лист для владельца сайта

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

Мой сайт на 1С-Битрикс или WordPress, это уязвимость CMS?

Нет. Ошибка находится в самом PHP, поэтому уязвим любой сайт на нём, независимо от CMS. Обновление CMS эту проблему не решает, нужно обновить именно PHP.

Если у сайта нет форм загрузки файлов, он в безопасности?

Нет. Атака выполняется на этапе разбора запроса, ещё до запуска кода сайта. Специальный запрос можно отправить на любой адрес, который обрабатывает PHP, даже если на сайте нет ни одной формы.

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

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

Сломается ли сайт после обновления с 8.2.34 на 8.2.35?

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

Чем переход на новую ветку отличается от обновления внутри ветки?

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

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

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

Касается ли это сайтов на виртуальном хостинге?

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