Новости

Критические уязвимости в PHP: обновите серверы с Битрикс и другими PHP-сайтами

21.10.2026 18:00

21 октября 2026 года PHP выпустил исправления для двух критических уязвимостей: CVE-2026-109618 и CVE-2026-109619. Обе проблемы могут позволить удалённо выполнить код на сервере без авторизации.

Если сайт, интернет-магазин или коробочный Битрикс24 доступен из интернета, обновить серверный PHP необходимо как можно скорее.

Главное: полной временной защиты без обновления нет. Проверьте, какой PHP фактически обслуживает сайт, установите патч от поставщика ОС или обновите PHP через штатные инструменты BitrixVM, затем перезапустите PHP-FPM и протестируйте проект.

Какие версии PHP закрывают уязвимости

Исправления опубликованы в следующих версиях PHP:

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

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

Для PHP 8.1 и более старых веток штатных новых релизов от PHP больше не будет: эти версии сняты с поддержки.

Некоторые поставщики Linux с длительной поддержкой могут выпускать собственные пакеты с бэкпортами исправлений. Поэтому на таких серверах нужно проверять не только номер версии php -v, но и бюллетени безопасности конкретного дистрибутива.

В чём суть CVE-2026-109618 и CVE-2026-109619

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

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

Уязвимости затрагивают веб-конфигурации PHP, включая PHP-FPM, Apache с mod_php, CGI, FrankenPHP и LiteSpeed. В advisory отмечено, что подтверждённый сценарий эксплуатации для mod_php не требует выполнения кода самого приложения: атака может начаться ещё до запуска PHP-кода сайта.

Почему сайты на «1С-Битрикс» и коробочный Битрикс24 под угрозой

Проблема находится не в коде «1С-Битрикс» или Битрикс24, а в серверном интерпретаторе PHP. Поэтому обновление продукта через SiteUpdate не заменяет обновление PHP в операционной системе или BitrixVM.

Риск есть у любого публично доступного PHP-проекта, если уязвимая версия PHP обрабатывает веб-запросы. Это относится к сайтам на «1С-Битрикс: Управление сайтом», коробочным порталам Битрикс24, WordPress, Laravel и самописным приложениям.

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

Сначала подключитесь к серверу по SSH и проверьте версию PHP в командной строке:

php -v

Также проверьте версии установленных пакетов:

rpm -q php php-fpm
rpm -qa | grep -E '^php|^ea-php|^php[0-9]'

Однако версия PHP в консоли может отличаться от версии, обслуживающей сайт. Особенно это актуально для BitrixVM, нескольких PHP-FPM-пулов, Docker-контейнеров и серверов с несколькими установленными ветками PHP.

Чтобы проверить работающий сервис PHP-FPM, выполните:

systemctl status php-fpm --no-pager
php-fpm -v

Если используется несколько версий PHP-FPM, найдите процессы и конфигурации пулов:

ps aux | grep '[p]hp-fpm'
systemctl list-units --type=service | grep -i php

Самый надёжный способ проверить веб-версию — временно создать защищённый от публичного доступа файл с phpinfo(), открыть его с разрешённого IP-адреса и сразу удалить после проверки. Не оставляйте такой файл в публичном каталоге: он раскрывает сведения о серверной конфигурации.

Как обновить PHP в BitrixVM на CentOS Stream 9 и AlmaLinux 9

В актуальном BitrixVM 9.x поддерживаются CentOS Stream 9 и AlmaLinux 9. Для окружения «1С-Битрикс» рекомендуем использовать штатный механизм обновления BitrixVM, а не подключать сторонние PHP-репозитории без проверки совместимости.

Перед обновлением:

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

Обновление через меню BitrixVM

Подключитесь к серверу и откройте штатное меню BitrixVM:

sudo /root/menu.sh

Далее используйте раздел управления серверами пула и выберите пункт «Обновление PHP, MySQL, PostgreSQL». BitrixVM проверит и установит доступные обновления совместимых пакетов из своих репозиториев.

После завершения обновления перезапустите PHP-FPM:

sudo systemctl restart php-fpm

Затем убедитесь, что сервис запущен и использует обновлённую версию:

sudo systemctl status php-fpm --no-pager
php -v
php-fpm -v

Обновление пакетов через DNF

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

sudo dnf check-update

После проверки установите обновления из уже настроенных репозиториев:

sudo dnf update --refresh

Затем перезапустите PHP-FPM:

sudo systemctl restart php-fpm

Не подключайте Remi или другие сторонние репозитории PHP на работающей BitrixVM без предварительной проверки. В документации «1С-Битрикс» указано, что сторонние PHP-пакеты могут конфликтовать с пакетами BitrixEnv и привести к проблемам с зависимостями или обновлениями окружения.

Как подтвердить, что патч установлен

Для стандартных upstream-сборок ориентируйтесь на номер исправленного релиза:

ветка 8.5 — не ниже 8.5.12
ветка 8.4 — не ниже 8.4.27
ветка 8.3 — не ниже 8.3.36
ветка 8.2 — не ниже 8.2.35

Для пакетов из репозиториев Enterprise Linux номер в php -v может быть ниже, если поставщик применил исправление как бэкпорт. В этом случае нужно проверить changelog установленного RPM-пакета и бюллетень безопасности поставщика ОС:

rpm -q --changelog php | head -n 80
rpm -q --changelog php-fpm | head -n 80

Ищите упоминания CVE-2026-109618 и CVE-2026-109619. Если записи нет, не считайте сервер защищённым только по предположению.

Что делать, если обновить PHP сейчас нельзя

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

Отключите отслеживание прогресса загрузки

В конфигурации PHP-FPM или в основном php.ini задайте:

session.upload_progress.enabled = 0

Для пула PHP-FPM настройка должна применяться до обработки запроса:

php_admin_value[session.upload_progress.enabled] = 0

После изменения конфигурации обязательно перезапустите все PHP-FPM-воркеры:

sudo systemctl restart php-fpm

Не используйте для этой меры ini_set() внутри приложения или .user.ini: они применяются слишком поздно и не блокируют подтверждённый путь атаки.

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

Если загрузка файлов не нужна, установите консервативный предел:

post_max_size = 8M

Если загрузка файлов необходима, можно использовать ограничение:

post_max_size = 32M
upload_max_filesize = 24M

Значение upload_max_filesize должно быть ниже post_max_size. Ограничения полезны для уменьшения поверхности атаки и риска отказа в обслуживании, но не заменяют установку патча.

Дополнительная мера для PHP 8.5

Для PHP 8.5 временно отключите трассировки критических ошибок:

fatal_error_backtraces = 0

После изменения перезапустите PHP-FPM. Эта настройка устраняет один из подтверждённых сценариев, но не является полной защитой.

Временно ограничьте multipart-запросы, если сайт не принимает файлы

Если проект не использует загрузку файлов через веб-формы, можно временно блокировать запросы с multipart/form-data на уровне фронтенд-сервера. Это крайняя мера: она отключит загрузку файлов через административную часть, формы обратной связи, интернет-магазин и другие функции, использующие multipart.

Для Nginx:

if ($http_content_type ~* "multipart") {
    return 403;
}

Для Apache с mod_rewrite:

RewriteCond %{HTTP:Content-Type} multipart [NC]
RewriteRule ^ - [F,L]

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

sudo nginx -t && sudo systemctl reload nginx

или:

sudo apachectl configtest && sudo systemctl reload httpd

Что проверить после обновления

веб-версию PHP и статус PHP-FPM;
доступность главной страницы и административного раздела;
авторизацию пользователей;
загрузку файлов, если она используется;
отправку форм и почтовых уведомлений;
работу корзины и оформления заказа для интернет-магазина;
интеграции с CRM, 1С, платёжными и внешними сервисами;
очереди, агенты и задания cron;
логи Nginx, Apache и PHP-FPM после перезапуска.

Вывод

CVE-2026-109618 и CVE-2026-109619 — повод обновить не только код сайта, но и серверную платформу.

Уязвимость расположена ниже уровня CMS: обновление «1С-Битрикс» или Битрикс24 не исправит уязвимый PHP-FPM, Apache с mod_php или иной веб-обработчик.

Проверьте фактическую версию PHP, обновите пакеты штатным способом и перезапустите воркеры.

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

Источники

← Другие новости