Почему сейчас особенно важно обновить PHP?

Обновление PHP сейчас до актуальной, официальной целевой версии, рекомендованной командой PHP - это  крайне важная мера, чтобы защитить ваш бизнес от остановки, кражи клиентских баз данных.



21 октября 2026 года разработчики языка PHP выпустили экстренные обновления безопасности. Они закрывают две уязвимости наивысшего уровня опасности (CVE-2026-109618 и CVE-2026-109619). Эксперты присвоили им критическую оценку — 9.2 из 10 по международной шкале рисков CVSS v4.0. Это означает, что уязвимости максимально просты для использования хакерами и несут разрушительные последствия.

Чем это грозит вашему бизнесу прямо сейчас?

Особенность этих уязвимостей в том, что хакеру не нужно знать логины или пароли (он действует как «неаутентифицированный злоумышленник»). Роботы-сканеры ищут уязвимые сайты автоматически. Если ваш PHP не обновлен, последствия будут следующими:

• Полный контроль над сайтом: преступники могут удаленно загрузить на ваш сервер любой вредоносный код. Сайт может начать показывать рекламу мошенников, воровать банковские карты клиентов или полностью заблокироваться с требованием выкупа.
• Кража коммерческих тайн и баз данных: хакеры получают прямой доступ к файлам конфигурации и базам данных. История заказов, адреса, телефоны и пароли ваших клиентов могут оказаться в открытых данных.
• Отключение сторонних сервисов (API): злоумышленники крадут ваши API-ключи. Это значит, что они смогут от вашего имени управлять CRM-системой, платежными шлюзами, сервисами рассылок или службами доставки, что приведет к мгновенным финансовым потерям.

Под угрозой все установки PHP, обрабатывающие веб-запросы, включая PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed.

Что делать тем, у кого сайт на Битрикс?

Когда информация об уязвимостях появилась, в бизнес-сообществе у некоторых возникло ложное представление, будто проблема кроется в системе «1С-Битрикс». Это опасное заблуждение, которое важно прояснить.

Причина ложной тревоги исключительно в скорости реакции: команда «1С-Битрикс» одной из первых в русскоязычном интернете проявила максимальную заботу о безопасности своих клиентов. Специалисты оперативно уведомили своих пользователей, чтобы бизнес мог защитить свои ресурсы.
Однако некоторые пользователи истолковали эти уведомления неверно. Увидев в одном предложении слова «критическая уязвимость» и «Битрикс», они автоматически связали проблему с кодом самой CMS.

Как обстоят дела на самом деле?

В собственном программном коде продуктов Битрикс ошибок нет. 

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

Паниковать и менять настройки вашего сайта на «1С-Битрикс» не нужно. Но необходимо обновить версию PHP на сервере, где этот сайт расположен.

Речь касается всех, у кого -  коробочный Битрикс24 или сайт на „1С-Битрикс: Управление сайтом“.

 PHP на сервере при этом нужно обновить отдельно. Обновление через SiteUpdate эту задачу не решает. Исправления вошли в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Это как-раз те самые официальные целевые версии, рекомендованные командой PHP.

Если же у вас облачный Битрикс24 (Cloud), делать ничего не нужно. Безопасность облачной инфраструктуры, включая обновление PHP, операционной системы и закрытие критических уязвимостей, полностью лежит на инженерах и службе безопасности „1С-Битрикс“. Облачный сервис уже работает в штатном режиме: файлы загружаются, функции доступны, обновления на серверы вендора установлены и проверены.

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

Для владельцев же коробочной версии Битрикс24, сайтов„1С-Битрикс: Управление сайтом“ актуальны следующие рекломедации.
Порядок обновления BitrixVM 9.x

Шаг 1. Подготовка и резервное копирование

Создайте полные бэкапы сайта, базы данных и конфигурации сервера.

Протестируйте обновление на копии проекта.

Шаг 2. Проверка репозиториев

Обновите кэш пакетов ОС и проверьте доступность исправленных версий PHP в репозиториях.

Шаг 3. Установка обновления

Установите обновление PHP вместе с необходимыми зависимостями.

Если исправленных пакетов в репозитории ещё нет, используйте ручную установку совместимых пакетов.

Шаг 4. Перезапуск веб-сервера

Если у вас конфигурация с Apache и модулем PHP, перезапустите Apache: systemctl restart httpd.service

Шаг 5. Проверка после обновления

Убедитесь, что сайт действительно использует исправленную сборку PHP.

Проверьте авторизацию, работу CRM, загрузку файлов, почту, интеграции.

Важно! Готовые пакеты появляются в репозиториях не одновременно. Обычная проверка обновлений может ещё не показать исправленную версию. При этом сторонние репозитории (например, remi) уже выпустили сборки поддерживаемых версий. Если исправленного пакета в вашем репозитории нет, установите совместимые пакеты вручную.
При этом репозиторий remi уже выпустил сборки всех поддерживаемых версий.

Если исправленного пакета нет в вашем репозитории, нужно установить совместимые исправленные пакеты вручную.

Важно: успешное выполнение команды обновления не гарантирует, что уязвимость устранена. Нужно проверить, какая сборка PHP фактически обслуживает сайт. Это можно сделать через phpinfo() или командой php -v в окружении веб-сервера.

Чек-лист контроля обновлений PHP (BitrixVM 9.x)

1. Подготовка и безопасность
• Бэкапы готовы: создана свежая резервная копия сайта, базы данных и конфигурации сервера.
• Тест пройден: совместимость обновления проверена на тестовой копии сайта.
2. Работа с репозиториями
• Кэш обновлен: обновлены сведения о пакетах в системе.
• Патч доступен: в подключенных репозиториях появилась исправленная версия PHP.
3. Установка и запуск
• PHP обновлен: установлена целевая безопасная версия (автоматически или вручную через сторонние репозитории).
• Службы перезапущены: веб-сервер и обработчик PHP применили изменения (перезапущен Apache при mod_php или PHP-FPM при связке с Nginx).
4. Финальная проверка
• Версия подтверждена: проверено, что сайт фактически переключился и работает на новой, защищенной сборке PHP.

А что делать владельцам других платформ?

  Уязвимости затрагивают все установки PHP, обрабатывающие веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Наибольший риск представляет mod_php: подтверждённый эксплойт срабатывает до того, как выполнится какой-либо код приложения, — то есть защитные механизмы самого сайта не успевают включиться.
Под угрозой оказались миллионы сайтов по всему миру, использующие PHP (WordPress, Drupal, Joomla).

Общие рекомендации

1. Обновите PHP.  Это можно сделать пакетным менеджером дистрибутива или пересборкой Docker-образа. Убедитесь, что устанавливаете следующие или более новые релизы: 8.5.x → 8.5.12; 8.4.x → 8.4.27; 8.3.x → 8.3.36; 8.2.x → 8.2.35. Для контейнеров обновите или пересоберите образ с исправленной версией PHP и пересоздайте контейнеры, сохранив конфигурацию и тома. Перед удалением старых контейнеров проверьте сохранность данных: файлы в записываемом слое удаляются вместе с контейнером.

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

2. Перезапустите воркеры. После обновления пакетов уязвимость остаётся активной, пока старые процессы находятся в памяти. Для Apache с mod_php: systemctl restart httpd.service. Для Nginx + PHP-FPM: systemctl restart php-fpm.service. Перезапуска одного Nginx недостаточно — это самая частая ошибка администраторов.  

3. Если используется PHP 8.1 или старше. Эти ветки больше не получают обновлений от команды PHP. Для 7.4, 8.0 и 8.1 опубликованы только минимальные патчи исходного кода, а не готовые пакеты. Если ваш дистрибутив или LTS-вендор не предоставляет исправленную сборку, рекомендуется перейти на поддерживаемую ветку (8.2+).

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

Для CVE-2026-109619: отключите session.upload_progress.enabled = 0. Если используется PHP-FPM, продублируйте настройку через php_admin_flag, чтобы приложение не могло её переопределить.

Для CVE-2026-109618: установите memory_limit = -1 (предпочтительно через php_admin_value) и низкий post_max_size: 8M, если загрузка файлов не нужна, или 32M, если нужна. Убедитесь, что upload_max_filesize меньше post_max_size.

Почему правим: Убрана опечатка «целессобразно». Главное — добавлено критическое уточнение, что это не полная защита, а частичная мера. PHP прямо предупреждает об этом, и SANS называет настройку session.upload_progress именно «partial mitigation». Без этого уточнения читатель может решить, что отключения одной опции достаточно. Также добавлены рекомендации по memory_limit и post_max_size для второй уязвимости — в исходном тексте их не было, хотя PHP их официально рекомендует. 

5. После обновления проверьте логи. В фокусе — подозрительно большие куки PHPSESSID (PoC использовал filename размером около 5 МБ) и падения воркеров. Если сервер был доступен из интернета без патча, проведите проверку на признаки компрометации. При обнаружении любых признаков ротируйте хранимые учётные данные: пароли к базам данных, API-ключи, токены интеграций.

Для устаревших веток 7.4, 8.0 и 8.1 команда PHP опубликовала минимальные патчи исходного кода, а не готовые релизы. Наличие пакетов в репозиториях зависит от дистрибутива или LTS-вендора. Уточните у поставщика, выпустил ли он исправленную сборку. Если нет — обновляйтесь на поддерживаемую ветку или собирайте PHP из исходников с патчем. 
Важно! Не допустите ошибки при перезапуске служб. Перезапуска одного Nginx, к сожалению,  недостаточно! Это самая частая ошибка администраторов. Если вы обновили бинарные файлы пакетом, но не перезапустили службы, старые уязвимые процессы в памяти продолжат обслуживать запросы сайта.

Проверенные решения:

• Для связки с Apache (mod_php): systemctl restart httpd.service
• Для связки Nginx + PHP-FPM:  systemctl restart php-fpm.service

Что делать, если некому обновить PHP прямо сейчас?

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

Самостоятельные попытки обновить критическую инфраструктуру без глубокого понимания процессов BitrixVM — это неоправданный риск для стабильности компании.
Если в вашем штате нет квалифицированного системного администратора или текущий подрядчик задерживает реакцию, не рискуйте безопасностью бизнеса. Поручите экстренное обновление PHP и защиту вашего ресурса нашим профильным инженерам.

Мы возьмем всю техническую часть на себя:

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

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

Ситуация критическая: готовые инструкции по взлому (PoC-эксплойты) уже выложены в открытый доступ. Это значит, что устроить атаку теперь может даже начинающий хакер. Более того, специалисты компании Cloudflare зафиксировали реальные попытки взлома сайтов еще до того, как разработчики PHP успели выпустить официальное обновление.
Автоматические роботы-сканеры уже ищут уязвимые серверы в сети. Не ждите, пока ваш сайт окажется в их списке — напишите нам, и наши специалисты оперативно закроют эту критическую уязвимость.