Две критические дыры в ядре PHP: почему обновляться нужно в тот же день

21 октября 2026 года проект PHP выпустил внеплановые версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Они закрывают две уязвимости в ядре языка — CVE-2026-109618 и CVE-2026-109619. Обе относятся к худшему классу из возможных: удалённое выполнение кода без авторизации. Проще говоря, злоумышленнику не нужен ни логин, ни пароль, ни доступ к админке — достаточно отправить серверу специально подготовленный запрос.

В примечаниях к релизу разработчики PHP написали фразу, которую стоит перечитать дважды: «There are no complete mitigations, updating is the only safe choice» — полноценных обходных мер нет, единственный безопасный вариант — обновиться (php-src, релиз 8.4.27).

Почему ситуация хуже обычной

Обычно у критической уязвимости есть «окно»: производитель выпускает исправление, а подробности публикуются позже, когда большинство успело обновиться. В этот раз окна не было. Детали утекли 20 октября — за день до скоординированного раскрытия, и вскоре появился публичный PoC, то есть рабочая демонстрация атаки. Разбор механики опубликовали исследователи Akamai, предупреждение выпустил CERT-EU, ответы на частые вопросы собрала команда watchTowr.

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

Что это значит для обменника на PHP

Выполнение кода на сервере — это не «сломали страницу». Это доступ ко всему, что видит веб-приложение:

к файлу .env с паролями от базы данных, ключами API бирж и платёжных шлюзов;
к базе с заявками, балансами и данными клиентов, включая документы KYC;
к ключам горячего кошелька, если они хранятся на том же сервере, что и сайт;
к возможности тихо подменить адреса для приёма средств в интерфейсе.

Последний пункт особенно неприятен: злоумышленнику не обязательно что-то «красть» сразу. Достаточно незаметно поменять адрес депозита в шаблоне — и клиенты сами начнут отправлять деньги на чужой кошелёк.

«Обновим в следующем спринте» стоит денег

Самая дорогая фраза в этой истории — «запланируем на следующей неделе». Между выходом исправления и массовым сканированием проходят не недели, а часы и дни. Каждый день на уязвимой версии — это день, когда о вашем сервере может узнать чужой автоматический сканер.

Отдельно стоит помнить про PHP 8.2: эта ветка получила исправление, но 31 декабря 2026 года она перестаёт поддерживаться. После этой даты следующую подобную дыру в 8.2 уже никто не закроет. Если ваш проект до сих пор на 8.2, переход на актуальную ветку нужно планировать сейчас, а не в январе.

Как выстроить обновления, чтобы не бегать в панике

Хорошая новость: срочное обновление — не подвиг, если процесс подготовлен заранее. Вот что для этого нужно.

Знать о выпусках первым. Подпишитесь на рассылку анонсов php.net и на список рассылки безопасности вашего дистрибутива (Debian, Ubuntu). Разработчик не должен узнавать о критической дыре из новостей через неделю.

Иметь staging. Тестовая среда, повторяющая боевую, позволяет за час проверить, что новая версия PHP не ломает приложение. Без неё любое обновление превращается в лотерею, и его откладывают.

Делать бэкапы и проверять восстановление. Резервная копия, из которой никто ни разу не восстанавливался, — это надежда, а не бэкап.

Автоматизировать обновления ОС. Пакет unattended-upgrades в Debian и Ubuntu ставит исправления безопасности без участия человека. Для пакетов PHP из репозитория дистрибутива это часто означает обновление в тот же день.

Проверять зависимости. Команда composer audit показывает известные уязвимости в библиотеках проекта. Её стоит запускать в CI при каждой сборке, а версии зависимостей — фиксировать в composer.lock, чтобы на сервер не приезжало ничего непроверенного.

Выкатывать постепенно. Канареечный деплой — сначала один сервер или небольшая доля трафика, затем все — позволяет обновляться быстро и при этом безопасно откатиться, если что-то пошло не так.

Если сервер мог быть уязвим

Раз подробности были публичными до выхода исправления, само обновление не отменяет вопрос: а не успел ли кто-то зайти раньше? Если сервер работал на уязвимой версии и был доступен из интернета, имеет смысл:

просмотреть журналы веб-сервера за период с 20 октября на предмет необычных запросов;
поискать на сервере посторонние PHP-файлы — так называемые веб-шеллы, через которые злоумышленник возвращается позже;
сравнить файлы приложения с репозиторием, особенно шаблоны с адресами для депозитов;
сменить пароли от базы данных, ключи API бирж и платёжных систем, секреты в .env;
если ключи горячего кошелька лежали на том же сервере — считать их скомпрометированными и перевести средства на новые адреса.

Критическая уязвимость с публичным PoC — это гонка, которую выигрывает тот, кто обновился раньше сканеров. Выиграть её можно только процессом, подготовленным заранее.
Подпишитесь на анонсы php.net и рассылку безопасности дистрибутива.
Держите staging и проверенные бэкапы, чтобы обновление занимало часы, а не недели.
Включите unattended-upgrades и composer audit в CI.
Планируйте уход с PHP 8.2 до 31 декабря 2026 года.
После инцидентного окна проверьте журналы, ищите веб-шеллы и меняйте ключи.