21 октября 2026 года проект PHP выпустил исправления для двух критических уязвимостей (CVSS v4.0 9.2): PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Уязвимости находятся в самом PHP, а не в коде 1С-Битрикс, поэтому обновление сайта через SiteUpdate их не закрывает. Владельцам сайтов на коробочных 1С-Битрикс и Битрикс24 нужно обновить PHP на сервере.
Это следует из официального архива новостей PHP: предупреждение вышло 20 октября, исправления 21 октября, а 23 октября добавилась отдельная рекомендация по настройке session upload progress. Облачный Битрикс24 это не касается: серверным PHP там управляет сам сервис, и менять ничего не нужно. Зато любой сайт или корпоративный портал, который вы держите на своем сервере или у хостинга, попадает в зону внимания.
Ниже по порядку: что именно закрыли, как узнать, какая версия PHP стоит у вас на самом деле, как обновиться без остановки бизнеса и что делать, если обновиться прямо сейчас нельзя.
Что произошло с PHP 21 октября?
PHP получил внеплановое обновление безопасности для четырех поддерживаемых веток: 8.2, 8.3, 8.4 и 8.5. Исправлены две уязвимости, обе с максимально высокой для этого релиза оценкой CVSS v4.0 9.2, и обе позволяют удаленно выполнить код на сервере.
CVSS — это общая система оценки опасности уязвимостей по шкале от 0 до 10: чем выше число, тем проще эксплуатация и тяжелее последствия. Оценка 9,2 относится к критическим.
| Уязвимость | В чем суть по описанию PHP |
|---|---|
| CVE-2026-109618 | Сбой при нехватке памяти: PHP может прерваться, когда данные запроса инициализированы лишь частично, и очистка запроса примет некорректные данные за корректные |
| CVE-2026-109619 | Устаревшее состояние запроса сохраняется после освобождения памяти, и следующий запрос в том же рабочем процессе может его использовать |
Под угрозой все установки PHP, которые обслуживают веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Наибольший риск авторы оценивают для mod_php, где продемонстрирован эксплойт: неаутентифицированный запрос запускает атаку еще до выполнения кода приложения. Подробности опубликованы в описаниях GHSA-w8hw-w9fx-j79w и GHSA-6wmf-4rv5-p3rp.
Почему это касается 1С-Битрикс и коробочного Битрикс24?
Потому что и «1С-Битрикс: Управление сайтом», и коробочный Битрикс24 работают на PHP, а уязвимость сидит в интерпретаторе, который обслуживает любые запросы к сайту, включая запросы к страницам входа и форм. Для атаки не нужны ни логин, ни ошибка в вашем коде.
Минимальная версия PHP для обоих продуктов сейчас 8.2, что указано в требованиях «1С-Битрикс: Управление сайтом» и в справке по требованиям коробочного Битрикс24. Страницы обновлялись в июне 2026 года, и перед работой стоит открыть их заново. Это означает, что большинство актуальных установок работают на ветках, для которых исправления уже вышли.
Главная ловушка в другом: многие считают, что обновление продукта, которое они регулярно ставят в админке, закрывает и серверные риски. Это не так. SiteUpdate обновляет файлы и модули 1С-Битрикс, но не заменяет серверный интерпретатор PHP, в том числе в BitrixVM. Если вы последний раз обновляли PHP полгода назад, ваш сайт остается уязвимым, даже когда все модули обновлены до последней версии.
Как узнать, какая версия PHP работает на вашем сайте?
Узнать версию можно из административной части самого сайта или у хостинга, но проверять нужно ту версию, которая обслуживает веб-запросы, а не ту, что отвечает в командной строке сервера. Эти версии часто различаются: на одном сервере могут стоять несколько версий PHP.
- Откройте в административной части 1С-Битрикс или Битрикс24 раздел с информацией о системе или проверкой системы и найдите там версию PHP.
- Если на сервере несколько сайтов, проверьте каждый: у каждого пула PHP-FPM или виртуального хоста может быть своя версия.
- Спросите хостинг или администратора, каким способом PHP подключен к веб-серверу: PHP-FPM, mod_php или иначе. Для mod_php срочность выше.
- Сравните номер версии со списком исправленных: 8.2.35, 8.3.36, 8.4.27, 8.5.12. Если ваш номер ниже внутри своей ветки, исправления нет.
- Если версия 8.1 и старше, ситуация иная: эти ветки проект больше не поддерживает, а обновление веток 7.4, 8.0 и 8.1 PHP выложил только как минимальные бэкпорты.
Названия разделов интерфейса отличаются в зависимости от редакции и версии продукта, поэтому, если нужного пункта нет, проще спросить администратора или хостинг, чем искать его вслепую.
Как обновить PHP и не остановить сайт?
Обновление нужно делать с резервной копией и планом отката, а изменения сначала проверить на копии сайта. Обновление PHP на рабочем сервере без проверки может сломать расширения и самописный код.
- Сделайте полную резервную копию файлов сайта и базы данных и проверьте, что она открывается.
- Разверните копию сайта на тестовом сервере с новой версией PHP и пройдите основные сценарии: вход, форма заявки, корзина или сделка в CRM, загрузка файлов, импорт.
- Проверьте совместимость модулей, расширений PHP и собственных доработок. Старые доработки чаще всего ломаются на устаревших функциях.
- Согласуйте окно обновления с бизнесом: лучше в часы, когда в портале работает мало сотрудников, например вечером или в выходные.
- Обновите PHP на рабочем сервере и перезапустите рабочие процессы. Если в вашем окружении кэш байт-кода и пулы FPM, перезапуск обязателен.
- После обновления проверьте версию еще раз и просмотрите журнал ошибок в первые часы.
Дистрибутивы Linux и поставщики долгосрочной поддержки получили патчи заранее, поэтому вместо ручной сборки обычно достаточно установить обновление из репозитория своей операционной системы. Хостинги могут отставать на несколько дней: если провайдер не подтверждает исправление, попросите у него точную версию сборки и сведения о примененных исправлениях.
Что делать, если обновиться сразу нельзя?
Временные меры снижают риск по отдельным путям атаки, но не заменяют обновление: PHP прямо называет обновление единственным полным решением. Их стоит применять только на время подготовки к переходу.
- Для первой уязвимости ограничьте размер запроса:
post_max_sizeв пределах 8M (если загрузки файлов не нужны) или 32M (если нужны), аupload_max_filesizeсделайте меньше этого значения. Лучше задавать значения черезphp_admin_valueв пуле FPM или Apache, чтобы приложение не могло их переопределить. - Для второй уязвимости отключите отслеживание прогресса загрузки:
session.upload_progress.enabled=0в php.ini, конфигурации пула FPM или сервера, и перезапустите все рабочие процессы. Черезini_set()и.user.iniв FPM настройка не сработает. - Ограничьте на веб-сервере или прокси размер запроса, число полей и частей multipart, заголовков и глубину вложенности.
- Не используйте лимиты
RLIMIT_ASиRLIMIT_DATA: они могут вызвать именно тот сбой выделения памяти, который нужен для атаки.
Перед отключением session upload progress проверьте загрузку файлов и свои доработки: если на сайте есть индикатор загрузки, он может перестать работать. Не блокируйте полностью multipart/form-data без тестирования, иначе сломаются формы с вложениями.
Если обновиться не получается совсем, временно ограничьте внешний доступ к административным и служебным частям сайта по списку разрешенных адресов или через VPN. Это особенно уместно для корпоративного портала, к которому обращаются только сотрудники.
Что написано в рекомендации от 23 октября?
23 октября PHP опубликовал отдельную рекомендацию: до следующего регулярного релиза установить session.upload_progress.enabled=0, чтобы полностью закрыть маловероятный вектор удаленного выполнения кода. Если эта настройка уже применена как мера против CVE-2026-109619, дополнительных действий не требуется.
Условия проблемы редкие. Приложение должно одновременно задавать обработчик сериализации сессий как php_binary или php_serialize в конфигурации, переключать его на php через ini_set() до вызова session_start() и иметь включенный session upload progress. Приложения, которые не меняют обработчик во время работы, могут оставить функцию включенной. Исправление будет выпущено в обычном цикле, а полное описание проблемы под номером CVE-2026-115560 опубликуют вместе со следующим релизом.
Для владельцев сайтов вывод простой: самописные модули, которые меняют настройки сессий на лету, стоит показать разработчику. Если вы не уверены, делает ли ваша доработка такие вещи, быстрее и безопаснее отключить функцию и проверить загрузку файлов.
Когда PHP 8.2 перестанет получать исправления?
PHP 8.2 выходит из поддержки 31 декабря 2026 года, после этой даты исправлений безопасности для него не будет. Поскольку 8.2 сейчас является минимальной версией для 1С-Битрикс и коробочного Битрикс24, у многих компаний на ней стоят рабочие системы.
Практический вывод: если ваш сайт или портал работает на 8.2, обновление до 8.2.35 решает вопрос на ближайшие недели, но планировать переход на 8.3 или новее нужно уже сейчас. Для этого проверьте, поддерживает ли ваша редакция продукта и все модули более новую ветку, и оставьте время на тестирование. Откладывать до декабря рискованно: в конце года у разработчиков и хостингов обычно много других задач.
Если у вас нет своего администратора, обновление и проверку совместимости можно поручить подрядчику. Мы в B2BPRO.KZ по опыту проектов на 1С-Битрикс и WordPress советуем делать такую работу заранее, в спокойный период, а не в день, когда выходит критический релиз. Если нужна помощь, посмотрите разработку и сопровождение сайтов под ключ.
Чем рискует бизнес, если сервер остался без обновления?
Удаленное выполнение кода означает, что злоумышленник получает возможность запускать свои команды на сервере, а значит, получает доступ к тому, что на этом сервере хранится. Для сайта это файлы и база данных, для коробочного Битрикс24 это еще и вся CRM с клиентами, сделками, перепиской и документами.
Здесь стоит назвать последствия, которые типичны для любой такой ситуации (это общая оценка рисков, а не данные о конкретных взломах после 21 октября). Первое: утечка клиентской базы и коммерческой информации. Второе: подмена страниц и подстановка чужого кода, из-за чего поисковые системы могут пометить сайт как опасный. Третье: остановка работы, пока сайт восстанавливают из копии. Четвертое: для компаний, которые хранят персональные данные клиентов, добавляются обязательства по их защите по законодательству Казахстана.
Стоимость профилактики на этом фоне невелика: обновление PHP при готовой резервной копии занимает от нескольких часов до нескольких дней, в зависимости от размера проекта и числа доработок. Восстановление после взлома обычно занимает заметно дольше и требует остановки процессов, а потерянное доверие клиентов вернуть сложнее, чем потерянные часы.
Кто в компании должен отвечать за обновление PHP?
За обновление должен отвечать конкретный человек или подрядчик, у которого есть доступ к серверу, и руководитель обязан знать, кто это. В небольших компаниях обязанности часто не распределены: администратор портала думает, что сервером занимается хостинг, а хостинг считает, что это зона ответственности владельца сайта.
Чтобы избежать такой ситуации, договоритесь о трех вещах письменно:
- кто следит за выходом критических обновлений PHP и операционной системы;
- кто принимает решение об обновлении и согласует окно работ с бизнесом;
- кто проверяет результат после обновления и подтверждает его руководителю.
Если у вас есть договор на сопровождение, проверьте, входит ли в него обновление серверного ПО. Часто в такие договоры включают только работы с самим продуктом, а сервер остается вне поля зрения. Тогда критический релиз вроде нынешнего застает компанию без ответственного.
Как проверить, что сайт работает с mod_php или PHP-FPM?
Способ подключения PHP к веб-серверу определяет хостинг или администратор, и самостоятельно по внешним признакам его надежно не определить. Поэтому проще всего задать вопрос напрямую: «Как у нас PHP работает с веб-сервером: через PHP-FPM, mod_php или иначе, и на какой версии?»
Ответ нужен потому, что PHP оценивает риск по-разному для разных способов. Наибольшую опасность авторы связывают с mod_php, где продемонстрирован эксплойт без выполнения кода приложения, но уязвимы все установки, которые обслуживают веб-запросы. Не успокаивайтесь, если у вас PHP-FPM: это снижает один из сценариев, но не отменяет необходимость обновления.
На виртуальных серверах с BitrixVM и на выделенных серверах чаще всего ответственность лежит на владельце. На виртуальном хостинге PHP обновляет провайдер, но запросить подтверждение и версию сборки все равно стоит, так как сроки зависят от его процессов.
Отдельно подумайте о тестовых и забытых копиях сайта. Часто на том же сервере остаются старые копии, поддомены для разработки и пробные установки: они обслуживаются тем же PHP, но о них никто не помнит. Составьте список всех сайтов на сервере, а ненужные удалите или закройте от внешнего доступа. Меньше точек входа означает меньше работы при следующем критическом релизе и меньше риска, что один забытый сайт превратится в проблему для всей инфраструктуры. Такую ревизию удобно провести вместе с обновлением PHP: доступ к серверу у вас уже будет открыт. Заодно проверьте, сколько версий PHP одновременно установлено на сервере, и уберите лишние, чтобы не гадать в следующий раз, какая из них отвечает на запросы.
Что проверить в первую очередь: короткий список
- Версия PHP, которая обслуживает сайт, и способ подключения к веб-серверу.
- Наличие свежей резервной копии и план отката.
- Подтверждение от хостинга, что исправленная сборка установлена.
- Состояние всех сайтов и поддоменов на сервере, включая забытые тестовые копии: они тоже обслуживаются тем же PHP.
- Доработки, которые меняют настройки сессий и загрузки файлов во время работы.
- Журнал ошибок и необычная активность в журнале веб-сервера за последние дни.
Если вы нашли признаки взлома, например неизвестные файлы в каталоге сайта или необычные запросы в журнале, сначала сохраните копию журналов и файлов, а потом восстанавливайте сайт из чистой резервной копии. Просто удалить подозрительный файл недостаточно.
Частые вопросы
Нужно ли обновлять PHP, если сайт на облачном Битрикс24?
Нет, для облачного Битрикс24 ничего делать не нужно: серверным PHP управляет сам сервис. Обновление PHP касается коробочных версий и сайтов, которые размещены на вашем сервере или у хостинга. Если вы не уверены, какая у вас версия, уточните у администратора или в поддержке.
Закрывает ли обновление через SiteUpdate эти уязвимости?
Нет, SiteUpdate обновляет продукт, но не серверный интерпретатор PHP. Нужно отдельно обновить PHP до 8.2.35, 8.3.36, 8.4.27 или 8.5.12, в зависимости от вашей ветки. Это относится и к BitrixVM, где PHP тоже обновляется отдельно.
Какие версии PHP получили исправление?
Исправления вышли в версиях PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Для веток 8.1 и старше проект исправлений как полноценных релизов не выпускает, а предлагает только минимальные бэкпорты для 7.4, 8.0 и 8.1. Поэтому лучше перейти на поддерживаемую ветку.
Можно ли обойтись настройками вместо обновления?
Нет, настройки снижают риск, но не делают установку безопасной. Проект PHP называет обновление единственным полным решением. Ограничение размера запроса и отключение session upload progress можно применить на время подготовки к обновлению, но откладывать само обновление нельзя.
Как понять, что мой хостинг уже обновил PHP?
Проверьте номер версии в административной части сайта и сравните его со списком исправленных версий. Если номер ниже, запросите у хостинга подтверждение и точную версию сборки: дистрибутивы иногда переносят исправления, не меняя номер версии. Не полагайтесь на устное «все обновлено».
Что делать, если на сайте PHP 8.1 или старше?
Планировать переход на поддерживаемую ветку и до этого применить временные меры и ограничить внешний доступ. Ветки 8.1 и старше проект больше не поддерживает, а минимальная версия для 1С-Битрикс и коробочного Битрикс24 сейчас 8.2. Проверьте совместимость доработок на копии сайта.