Дыра в плагине — это будни: выключил плагин, обновил, живёшь дальше. Дыра в самом интерпретаторе языка — другой жанр: она не зависит от того, насколько аккуратно написан ваш код, и закрывается только обновлением того, что стоит под приложением. Именно это произошло сейчас: 20 октября проект PHP опубликовал анонс, а 21 октября в 13:30 UTC вышли внеплановые релизы 8.5.12, 8.4.27, 8.3.36 и 8.2.35 — с исправлениями двух критических уязвимостей в ядре.
Обе уязвимости — удалённое выполнение кода без авторизации, каждая оценена в CVSS 9.2 (v4.0). Идентификаторы — CVE-2026-109618 и CVE-2026-109619; в открытых обзорах историю уже называют «PHP2Shell». Главная деталь, из-за которой стоит дочитать даже владельцу «самого обычного сайта»: одна из двух срабатывает до того, как управление вообще дойдёт до кода приложения.
Мы на PHP не пишем и новым проектам не советуем — ниже объясним, почему. Но коробки Битрикс24 у клиентов мы обслуживаем, а стоят они именно на PHP. Поэтому главное в этой статье — не «мы же говорили», а рабочий порядок действий для владельца коробки.
Table Of Contents
Что случилось: внеплановые релизы четырёх веток
Формат произошедшего — сам по себе сигнал. Анонс вышел 20 октября, а уже 21 октября в 13:30 UTC проект выпустил внеплановые релизы сразу четырёх веток: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Так закрывают то, что нельзя оставлять открытым до ближайшего планового релиза.
Речь о двух уязвимостях в самом ядре интерпретатора: CVE-2026-109618 и CVE-2026-109619. Каждая получает CVSS 9.2 (v4.0) — верхнюю часть шкалы, куда попадают вещи, с которыми не спорят. Обе позволяют выполнить код на сервере удалённо и без авторизации: не нужно быть пользователем портала, не нужно взламывать админку, не нужно ничего знать о конкретном сайте.
Одна из двух уязвимостей срабатывает до того, как управление дойдёт до кода приложения. Это ключевой момент всей истории, и к нему мы ещё вернёмся: он перечёркивает любимый аргумент всех, кто привык не думать об инфраструктуре, — «у нас код написан аккуратно».
Первоисточники по теме: advisory CERT-EU 2026-018, релизы на php.net, разбор в блоге «Лаборатории Касперского» и обзоры на Хабре; технические выжимки собирает и SecurityLab.
Почему это не «ещё одна дыра в плагине»
Привычная история с уязвимостями в вебе устроена так: дыра находится в конкретном плагине или компоненте конкретной CMS. У неё есть имя и версия, а лекарство известно — обновить плагин, а если он не нужен, то отключить. Администратор к этому привык: приложение — его зона ответственности.
Здесь уязвимость живёт ниже — в самом интерпретаторе. Для одного из CVE не важно, аккуратно ли написан ваш код, есть ли у вас «сложные формы» или «проверенные годами модули». Запрос, который эксплуатирует уязвимость, не ищет дырку в вашей логике — он бьёт в сам язык, на котором написано всё.
Отсюда и бессилие привычных обходных мер. Ограничить доступ к админке, выключить лишние плагины, поставить экранирующий прокси — всё это работает на уровне приложения, а проблема уровнем ниже. Единственный полный фикс — обновить интерпретатор. Это неудобно: обновление PHP нередко тянет за собой проверку совместимости всего зоопарка кода. Но альтернатива — жить с RCE в ядре — заметно хуже.
Кто под ударом
Уязвимы все версии ниже исправленных; по неофициальным данным — начиная с PHP 5.4. Даже если это лишь приблизительная оценка снизу, масштаб понятен: речь не о какой-то свежей экзотической ветке, а практически о всей линейке языка, которая реально встречается на серверах.
Отдельный нюанс для тех, кто считает старое «безопасно устаревшим»: по данным CERT-EU, ветки PHP 8.1 и старше больше не получают обновлений от проекта PHP. Если сервер живёт на такой ветке, исправления с php.net для неё не выйдет.
Info
Ветки PHP 8.1 и старше не получают обновлений от проекта PHP. Это не приговор: дистрибутивы — например Ubuntu — поддерживают старые версии своими патчами. Но обновляться в этом случае нужно не с php.net, а из репозитория дистрибутива — и следить за его анонсами отдельно.
Практический вывод: сначала выяснить, какая версия PHP стоит на сервере и откуда она берёт обновления. Дальше стратегия зависит от ответа. На поддерживаемой ветке — обновляться до 8.5.12, 8.4.27, 8.3.36 или 8.2.35. На снятой с поддержки — ставить патч дистрибутива и в спокойном режиме планировать переезд на актуальную ветку.
Что делать владельцу коробки Битрикс24
Коробочный Битрикс24 — это не облако, за которым кто-то присматривает. Это ваш сервер: вы его администрируете, вы ставите обновления, вы отвечаете за версию PHP под ним. Вендор за вас интерпретатор не поменяет — а в ситуации уровня «RCE в ядре» ждать, что кто-то придёт и починит сам, худшая из стратегий.
Warning
Коробка Битрикс24 = ваш сервер. Вендор не обновляет PHP в вашей коробке — это делает тот, кто её администрирует. Если на вопрос «кто обновляет инфраструктуру» у вас нет внятного ответа, первый шаг не технический: найти ответственного.
Дальше — порядок действий, в котором работаем мы:
- Обновить PHP до исправленной ветки — 8.5.12, 8.4.27, 8.3.36 или 8.2.35, либо поставить патч дистрибутива, если версия приходит из его репозитория. Не «в следующем регламенте», а сейчас.
- Начать с интернет-доступных сервисов. Всё, что торчит наружу — порталы, публичные формы, API, — обновляется первым. Внутренние стенды — следом.
- Проверить, не было ли эксплуатации. Логи веб-сервера — на аномальные запросы, файловую систему — на подозрительные файлы и изменения там, куда их класть не должны. Признаки, на которые смотрят, описаны в разборах по ссылкам выше.
- Зафиксировать процедуру. Кто отвечает за инфраструктуру, как часто проверяются обновления, как выглядит проверка после критических релизов. Без этого следующий раз пройдёт по тому же сценарию — с тем же «мы не знали».
Пункт про проверку — не для галочки. Обновление могло встать без проблем, но остаётся вопрос: не воспользовались ли дырой до него. Ответ дают только логи и осмотр сервера; без них любое «у нас ничего не взломали» — угадывание.
Почему мы всё равно обновляем коробки
Резонный вопрос: вы же PHP не любите — зачем возиться с нашими коробками? Ответ простой: коробка Битрикс24 — чужая для нас, но живая инфраструктура, на которой работает бизнес клиента. Она не перестаёт быть зоной нашего обслуживания от того, что язык нам не по вкусу.
Обновление — часть обслуживания, а не одолжение. Уязвимость с CVSS 9.2 в ядре интерпретатора не спрашивает, какие у нас отношения с PHP: она эксплуатируется через любой запрос к порталу. Поэтому коробки, за которые мы отвечаем, закрываются по списку выше — начиная с тех, что доступны из интернета.
При этом обслуживание коробки не сводится к латанию дыр. Мы, например, поднимаем в связке с Битрикс24 локальные языковые модели, чтобы чувствительные данные не уходили во внешние API — об этом у нас отдельный разбор.
Почему новое мы строим не на PHP
Теперь обещанное «почему». История с PHP2Shell возможна потому, что на периметре стоит интерпретатор: каждый HTTP-запрос — это запуск исполняемого кода на вашем сервере. Чем толще слой исполняемого кода между интернетом и данными, тем выше шансы, что однажды в нём найдут способ исполнить чужой код.
Статика работает иначе: сервер отдаёт готовый HTML, стили и файлы — в ответ на запрос ничего не исполняется. Атакующей поверхности уровня «RCE в ядре интерпретатора» там просто нет: эксплуатировать нечего, кроме самого веб-сервера, который раздаёт файлы. Этот блог, например, собран генератором статических сайтов и раздаётся именно так.
Поэтому всё новое мы собираем на стеке без исполняемого кода на периметре; про статику и ИИ у нас выходит отдельная статья. Статика не спасает от всех бед мира, но целый класс аварий — того самого сорта «дыра в ядре языка» — она выключает начисто.
Что случилось и что делать: шпаргалка
| Что случилось | Что делать | Срок |
|---|---|---|
| Внеплановые релизы PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 (21 октября, 13:30 UTC) с исправлениями двух уязвимостей ядра | Обновить PHP на всех серверах до исправленной ветки или патча дистрибутива | Сейчас, не дожидаясь регламента |
| CVE-2026-109618 и CVE-2026-109619: RCE без авторизации, каждая CVSS 9.2 (v4.0), одна срабатывает до кода приложения | Проверить логи веб-сервера и файлы на следы эксплуатации | Сразу после обновления |
| Уязвимы версии ниже исправленных — по неофициальным данным, начиная с PHP 5.4 | Сверить версию PHP на каждом сервере; на старых ветках — патч дистрибутива и план переезда | В ближайшие дни |
| Ветки PHP 8.1 и старше без обновлений от проекта PHP | Определить источник обновлений — php.net или репозиторий дистрибутива — и следить за его анонсами | В ближайшие дни |
| Коробка Битрикс24 — ваш сервер | Назначить ответственного и зафиксировать порядок обновлений и проверок | На этой неделе |
Итог: три правила
- Обновлять инфраструктуру, а не только приложения. Уязвимость в ядре интерпретатора обходит всю аккуратность вашего кода; PHP под коробкой — такой же компонент, как сам Битрикс24, и в такой ситуации обновляется первым.
- Изолировать коробки. У каждого сервера — свой владелец, свой график обновлений и своя проверка после критических релизов. «Кто-то же следит» — это не роль, а дыра в процессе.
- Новое строить на стеке без исполняемого кода снаружи. Статика на периметре — не панацея, но класс аварий уровня PHP2Shell она исключает по построению.
Если коробки Битрикс24 у вас обслуживает подрядчик — покажите ему таблицу выше и спросите, когда она будет выполнена. А о том, как мы строим новые сервисы, в том числе на ИИ, без исполняемого кода на периметре, читайте в разделе ИИ-разработки и в соседней статье про статику.