Размер шрифта

Цвет фона и шрифта

Изображения

Озвучивание текста

Обычная версия сайта

+375 44 767 92 77
г. Минск, пр-т Партизанский, д. 178, пом. 307
info@bk-media.by
Пн. – Вс.: с 9:00 до 21:00

Экстренное обновление PHP: Как закрыть критические RCE-уязвимости на сервере

Битрикс 24

21 октября 2026

В PHP обнаружены две критические уязвимости (RCE), которые позволяют злоумышленникам выполнить произвольный код на вашем сервере без какой-либо авторизации. Стандартное обновление CMS в этом случае не поможет — патчить нужно сам интерпретатор на уровне операционной системы. Мы подготовили подробную пошаговую инструкцию по безопасному обновлению PHP (включая BitrixVM и кастомные сборки), а также список временных компенсационных мер, которые помогут защитить проект, если обновить сервер прямо сейчас нет возможности.

Экстренное обновление PHP: Как закрыть критические RCE-уязвимости на сервере

Разработчики PHP выпустили срочные патчи, закрывающие две критические уязвимости. Данные бреши позволяют злоумышленникам выполнить произвольный код (RCE) на сервере без какой-либо авторизации.

Ключевой момент: Проблема находится на уровне внешнего серверного компонента самого языка PHP. Это значит, что стандартное обновление вашей CMS (например, штатный SiteUpdate в 1С-Битрикс) вас не спасет. Обновлять необходимо интерпретатор на уровне операционной системы сервера.

Безопасные целевые версии

Убедитесь, что вы устанавливаете следующие (или более новые) релизы:

8.5.x → 8.5.12
8.4.x → 8.4.27
8.3.x → 8.3.36
8.2.x → 8.2.35

Примечание: Для устаревших веток (7.4, 8.0, 8.1) команда PHP предоставила исправления на уровне исходного кода, однако наличие готовых пакетов в репозиториях полностью зависит от вашего вендора.

Пошаговый алгоритм обновления

Данная инструкция покрывает стандартные рабочие окружения: BitrixVM, серверы под управлением панелей ISPmanager, а также кастомные связки Nginx + PHP-FPM на базе Linux.

1 Резервное копирование и подготовка

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

Базы данных (MySQL).
Файловой системы сайта.
Конфигураций сервера (папки /etc/php.d/, /etc/httpd/, /etc/nginx/).

2 Подключение и проверка доступности пакетов

Подключитесь к боевому серверу по SSH (например, через встроенный терминал macOS). Пакеты появляются в зеркалах не одновременно, поэтому нужно проверить, отдал ли ваш репозиторий исправленную версию.

Для серверов CentOS/BitrixVM/AlmaLinux:

yum clean all && yum check-update | grep php

Для серверов Debian/Ubuntu:

apt-get update && apt-get --just-print upgrade | grep php

3 Загрузка и установка обновления

Выполните установку свежих версий пакетов PHP вместе со всеми необходимыми зависимостями.

В среде BitrixVM команда будет выглядеть так:

yum upgrade "php*" -y

4 Перезапуск служб

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

Для связки с Apache (mod_php):

systemctl restart httpd.service

Для связки Nginx + PHP-FPM:

systemctl restart php-fpm.service

Убедитесь, что вы перезапускаете нужный сервис. Если вы используете ISPmanager, название службы может отличаться (например, php82-php-fpm).

5 Верификация версии и QA-тестирование

Убедитесь, что сайт использует пропатченную сборку. Создайте временный файл с phpinfo();, обратитесь к нему через браузер и проверьте версию.

Проведите ручное тестирование критических узлов:

Проверка авторизации и работы форм.
Загрузка медиафайлов.
Оплата и API: Обязательно проведите тестовые транзакции через подключенные платежные системы (Webpay, bePaid, Stripe) — обновление может затронуть работу cURL или SSL, на которые опираются шлюзы.

Компенсационные меры (если обновить прямо сейчас нельзя)

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

1. Настройка WAF (Web Application Firewall)

Это первый рубеж обороны. В Cloudflare стоит перевести WAF в режим блокировки аномалий. В локальном ModSecurity активируйте OWASP Core Rule Set с уровнем паранойи не ниже 2.

2. Изоляция и отключение функций в php.ini

Отредактируйте файл php.ini (или конфиг пула FPM), чтобы ограничить возможности интерпретатора.

Отключение системных вызовов:

disable_functions = exec, system, passthru, shell_exec, proc_open, popen, show_source

Жесткая изоляция файловой системы:

open_basedir = "/var/www/ваш_сайт/:/tmp/"

3. Ограничения на уровне Nginx

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

location ~* ^/(upload|images|bitrix/cache)/.*\.php$ {
    deny all;
}

4. Жесткое ограничение привилегий (Least Privilege)

Убедитесь, что пул PHP-FPM работает от пользователя с минимально возможными правами (например, www-data или bitrix). У пользователя веб-сервера не должно быть прав на запись в директории с исходным кодом CMS (кроме папок кэша, сессий и загрузок).

5. Сетевая изоляция административных панелей

Спрячьте административную часть за базовой авторизацией (HTTP Basic Auth) или ограничьте доступ по белому списку IP.

location ^~ /bitrix/admin/ {
    allow 192.168.1.100; # Ваш рабочий IP
    deny all;
    
    fastcgi_pass unix:/var/run/php/php-fpm.sock;
    # ... остальные параметры fastcgi
}

Важно: Эти меры покупают вам время. Продвинутые злоумышленники могут найти способы обхода ограничений. Запланируйте окно даунтайма для полноценного обновления PHP при первой же возможности.

📚 Использованные материалы:
Статья подготовлена с опорой на публикацию Хабра: Критическое обновление PHP: инструкция для владельцев коробочного Битрикс24 и сайтов на «1С-Битрикс» .