Критические уязвимости PHP: вышло исправление

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

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

Что это за уязвимости

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

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

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

Где риск выше всего

Если сайт работает на Apache с модулем PHP — а так до сих пор устроены многие серверы с 1С-Битрикс и коробочным Битрикс24 — это первоочередная задача на сегодня, а не на ближайший плановый регламент.

Кого это касается

Что сделать

Передайте эти шаги администратору сервера или хостинг-провайдеру.

1. Узнайте версию PHP и файл настроек. На сервере это команды php -v и php --ini. В административной панели 1С-Битрикс версия видна в «Проверке системы». У веб-сервера файл настроек может быть свой, отличный от консольного, — проверяйте именно тот, который видит сайт.
2. Обновите PHP до исправленной версии своей ветки: 8.2.35, 8.3.36, 8.4.27 или 8.5.12.
3. Перезапустите веб-сервер и PHP — Apache, php-fpm или LiteSpeed. Без перезапуска старый код остаётся в памяти рабочих процессов. Если перед PHP стоит nginx, перезапускать его бесполезно: PHP живёт в Apache или в php-fpm, перезапускать нужно именно их.
4. Убедитесь, что сайт работает на новой версии, а не только консоль. Проще всего посмотреть в системной информации панели управления или в «Проверке системы» Битрикса.
5. Проверьте сайт: вход в личный кабинет и админку, формы, загрузку файлов, отправку почты, работу CRM и обмен с 1С. Если серверов несколько, обновлять и проверять нужно каждый.

Не ищите на сервере ровно эти номера. Debian, Ubuntu и другие дистрибутивы переносят исправления в свои сборки, не меняя версию целиком: в системе останется, например, 8.2.28, но с уже закрытой уязвимостью. Ориентируйтесь не на номер, а на то, установлено ли обновление безопасности для пакета PHP.

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

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

Если у вас коробочный Битрикс24 или сайт на 1С-Битрикс

Уязвимость не в продуктах 1С-Битрикс, а в самом PHP, поэтому обновление платформы её не закрывает. Несколько частных моментов, на которых обычно спотыкаются.

• Обновление через SiteUpdate не поможет. Оно обновляет сам продукт, а не системный PHP. Версию PHP меняет администратор сервера или хостинг-провайдер.
• На веб-окружении BitrixVM после обновления пакетов перезапустите Apache: systemctl restart httpd.service. В стандартной сборке PHP работает именно под ним.
• В контейнерах обновлять пакеты внутри работающего контейнера бессмысленно: обновите или пересоберите образ и пересоздайте контейнеры, сохранив конфигурацию и тома. Перед этим проверьте, не осталось ли нужных данных в записываемом слое.
• После обновления посмотрите версию PHP в «Проверке системы» — там же видно, что именно использует сайт, а не консоль.

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

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

• memory_limit = -1, заданный административно для всех пулов и приложений. Это основная мера против первой уязвимости, но не полная: если память не сможет выделить уже система, уязвимый путь снова откроется.
• session.upload_progress.enabled = 0 с перезапуском рабочих процессов. Закрывает продемонстрированные сценарии через сессии во второй уязвимости. Задавать её нужно в php.ini или в настройках пула PHP-FPM, для Apache с модулем PHP подойдёт .htaccess. Через ini_set() в коде настройка не меняется — она применяется до запуска скрипта; на .user.ini хостинг-провайдеры в этом случае полагаться не советуют. Выключенной её имеет смысл держать и после обновления, если прогресс загрузки сайту не нужен.
• Ограничение размера запросов. Если сайт не принимает файлы, post_max_size = 8M; если принимает — порядка 32M, а upload_max_filesize сделайте меньше post_max_size. Туда же — лимиты на число частей multipart, заголовков, входных переменных и вложенность массивов. Если приложение вообще не работает с multipart, такие запросы проще заблокировать на фронтенде.
• Для PHP 8.5 — fatal_error_backtraces = 0 с перезапуском процессов: убирает путь, через который показан рабочий эксплойт.
• Чего делать нельзя: ограничивать память через RLIMIT_AS и RLIMIT_DATA. Это как раз приводит к сбою выделения памяти и запускает уязвимый сценарий.

Если у вас PHP 8.1 или старше

Эти ветки проект больше не поддерживает, готовых сборок для них нет. Для 7.4, 8.0 и 8.1 опубликованы минимальные патчи в исходном коде: их может применить ваш дистрибутив или администратор, который собирает PHP самостоятельно. Уточните у хостинг-провайдера, планирует ли он выпустить обновление.

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

Если сервер на CentOS 7 или другой системе без поддержки

Это отдельный и самый неприятный случай. CentOS 7 снята с поддержки 30 июня 2024 года, обновлений безопасности для неё не выпускают. Репозиторий remi, из которого на такие серверы обычно ставили свежий PHP, закрыт для EL7 тогда же: последние сборки там — PHP 8.1.29, 8.2.20 и 8.3.8 весны 2024 года. Это значит, что привычное обновление пакетов исправленную версию не принесёт, и сервер придётся считать уязвимым.

Варианты, по убыванию разумности.

• Перенести сайт на поддерживаемую систему. AlmaLinux 9, Rocky Linux 9, Debian 13 — для Битрикса это веб-окружение BitrixVM девятой ветки. Единственный вариант, который закрывает не только эту уязвимость: на CentOS 7 не обновляются ещё и ядро, OpenSSL и веб-сервер.
• Собрать PHP из исходников с официальными патчами. Для 7.4, 8.0 и 8.1 команда PHP опубликовала минимальные исправления, их можно применить к исходному коду. Нужен администратор, который соберёт PHP и дальше будет сам поддерживать эту сборку — разовой операцией дело не ограничится.
• Коммерческая расширенная поддержка. Платные программы вроде TuxCare ELS выпускают исправления для снятых с поддержки систем и версий PHP. Прежде чем покупать, уточните у поставщика, покрывает ли подписка вашу версию PHP и конкретно эти две уязвимости.
• Если ни один вариант не доступен сегодня — ограничьте доступ к сайту снаружи: закройте админку по IP или через VPN, поставьте перед сайтом веб-фаервол, примените временные меры из раздела выше и усильте наблюдение за логами. Это не защита, а способ прожить до переезда.

И главное: переезд с CentOS 7 придётся делать в любом случае. Разница только в том, пройдёт он по плану или в ночь после взлома.

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

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

• В логах веб-сервера и PHP участились аварийные завершения: Segmentation fault, zend_mm_heap corrupted, «дочерний процесс завершён сигналом».
• Выросло число ошибок о нехватке памяти (Allowed memory size exhausted) на страницах, где их раньше не было.
• В логах доступа появились необычные multipart-запросы: без корректной длины, с огромным числом полей или заголовков, на адреса, которые файлы обычно не принимают.
• От имени пользователя веб-сервера запущены непривычные программы: командная оболочка, curl, wget, nc, perl, python, майнеры с высокой загрузкой процессора.
• В каталогах сайта появились новые или изменённые PHP-файлы, которые никто из сотрудников не выкладывал, — особенно в папках загрузок и временных файлов.
• В админке сайта или в планировщике заданий появились незнакомые пользователи или задания.

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

Источники

• Анонс релизов PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12, 21 октября 2026 года.
• GHSA-w8hw-w9fx-j79w — CVE-2026-109618, порча памяти при нехватке памяти.
• GHSA-6wmf-4rv5-p3rp — CVE-2026-109619, устаревшее состояние между запросами.
• Разбор Центра кибермониторинга 1С-Битрикс — порядок обновления для серверов с Битриксом.

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