20 октября 2026 PHP Security Team выложила редкое для себя предупреждение: готовьтесь к экстренному security-релизу. Две критические дыры, обе по CVSS v4.0 на 9.2. Релиз назначен на 21 октября 2026, 14:00 UTC (17:00 по Москве). Полных технических деталей пока нет — и это как раз тот случай, когда «подожду changelog» может дорого стоить.
Повод ускориться неприятный: информация об уязвимостях утекла до официального disclosure. Сначала пост на Hacker News (потом удалили), затем подтверждение от исследователей watchTowr. PHP прямо написали: имеют право выпустить патч раньше, если детали станут публичными или появится эксплуатация в дикой природе.
Официальный анонс: Upcoming Critical PHP Security Release. Разбор ситуации: BleepingComputer.
Что уже известно
Пока официально PHP подтвердили только рейтинг и дату релиза. CVE-номера и «это RCE» в их коротком анонсе не расписаны — детали обещают вместе с патчами.
Из параллельных источников (watchTowr → BleepingComputer, CERT-EU, ACSC):
- идентификаторы: CVE-2026-109618 и CVE-2026-109619;
- тип: remote code execution (удалённое выполнение кода);
- watchTowr оценивает как CVSS 10, PHP официально ставит каждой 9.2 по CVSS v4.0 — расхождение в шкалах, не в том, что «не страшно»;
- по оценке исследователей, затронуты ветки PHP 5 / 6 / 7 / 8 (то есть фактически «почти всё, что ещё крутится в проде»);
- на момент предупреждений активной эксплуатации в wild не видели — но окно после утечки и до патча как раз самое опасное.
Ожидаемые fixed-релизы (по сообщениям security-комьюнити, не финальный список от PHP до момента публикации патчей): 8.5.12, 8.4.27, 8.3.36, 8.2.35. EOL-ветки вроде PHP 7.4 / 8.0 / 8.1 патча могут и не получить — рассчитывать на «дистр когда-нибудь подтянет» для мёртвой ветки наивно.
Почему это важно именно вам
PHP — это не «какой-то фреймворк». На нём сидят WordPress, Битрикс, Laravel, Magento, куча самописных ЛК и API. Если дыра в интерпретаторе и она RCE — компрометируется не «один плагин», а процесс php-fpm / apache-модуль. Дальше классика: шелл, бэкдор в wp-content, кража wp-config / .env, рассылка, ботнет.
После историй с wp2shell и массовыми взломами Битрикса сценарий знакомый: disclosure → через сутки сканеры по интернету → через неделю «у нас странный админ и левый плагин». Здесь ещё и leak до релиза — значит, кто умеет, уже мог готовить эксплойт, пока вы читаете новость.
Что сделать прямо сейчас
1. Инвентаризация. Пройдитесь по серверам и узнайте, где какой PHP:
php -v
# или на сайте
<?php echo PHP_VERSION;Отдельно — контейнеры, shared-хостинг клиентов, «забытые» лендинги на старом 7.4. Список версий и хостов лучше иметь до того, как пакеты появятся в репозитории.
2. Подготовить обновление. На Debian/Ubuntu заранее проверить, откуда тянете PHP (ondrej/php, вендорский репозиторий, remi на RHEL). На VPS с ручной сборкой — план: скачать релиз → подменить → reload php-fpm. На shared — тикет хостеру: «когда выкатите security-релиз PHP от 21.10».
3. Как только пакеты вышли — ставить без отлагательств. Для поддерживаемых веток цель простая: оказаться на fixed-версии своей линии (или новее). После обновления:
systemctl reload php*-fpm
# или
systemctl restart php8.3-fpm apache2И проверить, что сайт реально отвечает уже новым бинарником, а не старым php-fpm из другого pool.
4. EOL — отдельно. Если сайт на PHP 7.x или 8.0/8.1 и вендор патч не выпустит — это не «подождём», а миграция на поддерживаемую ветку. Временные костыли (WAF, закрыть наружу) — только мост, не лечение.
5. Пока патча нет / нельзя сразу обновить. CERT-EU прямо советует: где нельзя пропатчить мгновенно — по возможности изолировать интернет-facing приложения. На практике: усилить WAF/Cloudflare, убрать лишний PHP с публичных vhost’ов, закрыть ненужные entrypoint’ы, не торчать phpMyAdmin в мир. Это не замена патчу.
6. После патча — быстрый чек на компрометацию. Особенно если сервер торчал в интернет всё окно утечки. Смотрите новые PHP в uploads / странных каталогах, левых пользователей в CMS, неожиданные cron, правки .htaccess / nginx, неизвестные процессы от www-data. Патч закрывает вход — бэкдор, уже залитый до обновления, сам не исчезнет (мы это уже проходили на Битриксе и WordPress).
Чего пока делать не стоит
- Не гонять по себе чужие «PoC с GitHub», пока нет официального advisory — половина будет фейком или сама шеллом.
- Не путать CVSS 9.2 от PHP и «CVSS 10» из твитов: это разные формулировки одной критичности, а не две разные дыры.
- Не ждать, что «WordPress сам обновит PHP» — CMS ядро обновляет, интерпретатор на сервере — ваша зона.
Что дальше
После 14:00 UTC 21 октября на php.net должны появиться changelog’и и список affected/fixed. Как только будут точные версии и описание вектора — имеет смысл свериться ещё раз: не все сборки дистрибутивов выходят в ту же минуту, что upstream.
Если коротко: сегодня это не «интересная CVE для чтения на выходных», а окно, в котором нужно знать свои версии PHP и быть готовым нажать обновление в первые часы после релиза. WordPress, Битрикс, самопис — неважно: дыра в PHP бьёт по всему стеку.
Нужна помощь — пробежать серверы, обновить PHP на VPS, проверить сайты после патча — пишите через контакты.
Нужна профессиональная удалённая помощь с сервером, сайтом, компьютером или ноутбуком?
Свяжитесь со мной любым удобным для вас способом, и получите её быстро и не дорого.
Обсудить задачуПомогла статья? Поблагодари автора!
Остались вопросы, или есть что добавить? Добро пожаловать в комментарии.
Угостить автора чашечкой кофе