Коротко: что случилось и что делать
21 октября 2026 года разработчики PHP выпустили исправления двух критических уязвимостей, которые позволяют выполнить чужой код на сервере без авторизации. В прессе их объединили под общим названием PHP2Shell. Обе получили CVSS v4.0 9,2 из 10, уровень критический. Ошибки не в CMS и не в плагине, а в самом языке PHP, поэтому обновление движка сайта проблему не закрывает: обновлять нужно PHP на сервере. На виртуальном хостинге это делает провайдер, а не владелец сайта. Если сайт работает на ветке ниже 8.2, обычных обновлений для неё уже не выпускают: для 7.4, 8.0 и 8.1 есть только патчи исходного кода, а для 5.x и ранних 7.x — ничего.
Что именно нашли
Уязвимостей две. CVE-2026-109618, «RCE via OOM corruption», связана с обработкой нехватки памяти: сбой оставляет внутренние данные запроса частично инициализированными, и очистка может принять невалидные данные за валидные. CVE-2026-109619, «RCE via stale global state», устроена иначе: состояние одного запроса остаётся доступным после освобождения памяти, и следующий запрос в том же рабочем процессе может использовать его до сброса.
RCE — remote code execution, удалённое выполнение кода: злоумышленнику не нужны ни логин, ни пароль, ни доступ к админке — он отправляет запросы из интернета и добивается, чтобы сервер исполнял его код.
Нашли уязвимости Wiz, OpenAI и Calif в августе 2026 года и держали в тайне до выхода патчей. Одну из них OpenAI обнаружила с помощью модели GPT-5.6 Sol. Уязвимый код присутствует с версии 5.4, то есть с 2012 года.
| Ветка PHP | Исправленная версия | Статус поддержки на 22 октября 2026 |
|---|---|---|
| 8.5 | 8.5.12 | поддержка до 31.12.2027, безопасность до 31.12.2029 |
| 8.4 | 8.4.27 | поддержка до 31.12.2026, безопасность до 31.12.2028 |
| 8.3 | 8.3.36 | только безопасность, до 31.12.2027 |
| 8.2 | 8.2.35 | только безопасность, до 31.12.2026 |
| 8.1 и более старые | официального обновления нет | поддержка прекращена |
Для 7.4, 8.0 и 8.1 разработчики дали минимальные патчи исходного кода — для тех, кто собирает PHP сам или ждёт пакет от поставщика операционной системы.
Почему это касается почти любого сайта
PHP — рабочая основа интернета. По данным W3Techs на 22 октября 2026 года, PHP используют 69,3 процента сайтов, чей серверный язык известен. Внутри этой группы 65,3 процента работают на PHP 8, 26,9 процента — на PHP 7, 7,7 процента — на PHP 5 и 0,1 процента — на PHP 4.
В пересчёте на все сайты с определённым серверным языком: PHP 8.1 — 6,9 процента, 8.2 — 12,5, 8.3 — 15,8, 8.4 — 5,5, PHP 7 — 18,7. Отсюда наша оценка: около 31 процента таких сайтов работает на ветках ниже 8.2, то есть без официального патча. Это арифметика по данным W3Techs, а не перепись интернета.
Уязвимость не привязана ни к одному движку. Sansec подтвердила выполнение кода без авторизации на Magento 2.4.9, WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 и WHMCS. Общее одно — PHP под капотом.
Кому хуже всех
Затронуты все установки PHP, обслуживающие веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed.
Почему mod_php — худший случай
Разработчики называют наибольшим риск для Apache с mod_php: атака срабатывает до запуска кода приложения. Приложение может быть чистым, без единой известной дыры, а сервер всё равно уязвим. mod_php — режим, когда PHP встроен в сам веб-сервер.
Чем отличается PHP-FPM
В PHP-FPM, самом распространённом варианте на хостингах, при неудачном запуске запроса дочерний процесс завершается: испорченное состояние не успевает быть использовано. Анализ кода позволяет считать FPM подверженным, но полного эксплойта для этого режима не показали. Повод не паниковать, но не повод откладывать обновление.
Отдельная история — сайты с формами и загрузкой файлов: один из сценариев атаки идёт через обработку multipart/form-data, так браузер отправляет на сервер файлы и данные форм. Загрузка аватара, документ, корзина, оформление заказа — всё это точки, куда приходит такой запрос. И ещё эффект: уязвимость позволяет не только выполнить код, но и прочитать чужую память процесса — там могут оказаться пароли, токены сессий, API-ключи и приватные ключи TLS. Sansec сравнивает последствия с Heartbleed; это её формулировка, не наша оценка.
Что уже происходит
20 октября детали утекли в интернет, и релиз патчей сдвинули на день раньше. Публичный инструмент эксплуатации под названием PHP2Shell, авторство которого приписывают Calif, объединяет обе уязвимости в одну атаку и не требует входа в систему.
Атаки начались до выхода исправлений: Cloudflare зафиксировала первые попытки 21 октября в 07:43 по UTC, патчи вышли в 14:00 UTC. Sansec ожидала массовую эксплуатацию в течение 15 минут после релиза. Amazon фиксировала попытку против приманки 17 октября и новые атаки 21 октября из разных источников, об этом заявил глава её безопасности CJ Moses.
Часть организаций временно отключила сайты: Tweakers, Палата представителей Нидерландов, NCSC Нидерландов, Security.NL. Правительство Финляндии закрыло публичные веб-сервисы, Wikipedia отключила часть сайта. CISA 21 октября предупредила организации, CERT-EU, NCSC Британии и структуры Австралии рекомендовали немедленно обновлять PHP, а если это невозможно — рассмотреть отключение системы.
NSA сформулировало суть: уязвимости «часто дают прямой путь к файловой системе или базе данных сервера», и это «недостатки самого PHP, а не размещённого приложения». Wiz оценивает охват как примерно 70 процентов интернета, а BBC оговаривает, что не может независимо проверить эту цифру.
Что делать владельцу сайта
- Узнать версию PHP. Панель хостинга, страница phpinfo, если она открыта, заголовок X-Powered-By, лог ошибок. Если ничего из этого недоступно — тикет в поддержку с прямым вопросом: какая версия PHP обслуживает сайт.
- Обновить до исправленной версии — 8.5.12, 8.4.27, 8.3.36 или 8.2.35. На своём сервере это делаете вы или администратор, на виртуальном хостинге версию выбирает провайдер, и просить нужно его.
- Если обновиться прямо сейчас нельзя — применить временные меры из следующего раздела и держать задачу открытой.
- Проверить, не пользовались ли уязвимостью. Необычные файлы, чужие страницы, изменения в формах оплаты. Исходить стоит из худшего: пароли, токены сессий и API-ключи могли утечь, их надо заменить.
- Поставить обновление в практику. Поддержка PHP 8.2 заканчивается 31 декабря 2026 года, 8.3 — 31 декабря 2027, 8.4 — 31 декабря 2028, 8.5 — 31 декабря 2029. Версия PHP — такая же часть эксплуатации, как резервные копии.
Россия: что известно
С февраля 2026 года актуальная версия 1С-Битрикс требует PHP не ниже 8.2, и старые сайты могут этому не соответствовать. Beget 21 октября ограничил работу механизма upload_progress и планирует ограничить обработку multipart/form-data. Оценка Валентина Малых из MWS AI для РБК: под угрозой могут быть десятки тысяч ресурсов Рунета. Это мнение эксперта, а не измерение.
Если обновиться нельзя
Временные меры выглядят так. Отключить session.upload_progress и перезапустить всех воркеров. Убрать лимит памяти административно, на уровне пула FPM или конфига Apache. Ограничить обработку multipart/form-data на веб-сервере: по размеру тела запроса, числу полей и частей. Для PHP 8.5 дополнительно отключить fatal_error_backtraces и перезапустить процессы. Sansec предлагала жёстче — блокировать multipart/form-data целиком, но это ломает загрузку файлов и часть форм.
Главное: разработчики PHP прямо написали, что эти меры снижают риск по отдельным путям атаки, но не делают установку безопасной. Временная настройка — отсрочка, а не решение. При крайней необходимости остаётся приостановить сайт, но это мера на часы, а не рабочий режим на недели.
PHP 8.1 и старше: обновлений больше не будет
Для PHP 8.1 и более старых версий регулярных обновлений от проекта PHP не будет: он их больше не поддерживает. Минимальные патчи исходного кода для 7.4, 8.0 и 8.1 предназначены тем, кто собирает PHP сам или ждёт пакет от поставщика операционной системы; для 5.x и ранних 7.x патчей нет вовсе. Если сайт живёт на виртуальном хостинге со старой веткой, вариантов два: ждать, пока провайдер предложит переход, или переезжать.
Отдельно про 8.2: она перешла в режим только обновлений безопасности, и поддержка заканчивается 31 декабря 2026 года. Обновление до 8.2.35 закрывает текущие уязвимости, но не даёт запаса на будущее.
Если движок несовместим с 8.2, это задача не на один вечер: нужен тестовый стенд с копией сайта, проверка расширений и плагинов, проверка форм и оплаты. Переход на поддерживаемую ветку стоит планировать как проект, а не как настройку в панели.
Что мы увидели в своей выборке
15 октября 2026 года, до публикации уязвимости, мы осмотрели 955 интернет-магазинов малого и среднего бизнеса — без доступа к сайтам, только по открытым ответам серверов. 917 сайтов отдавали в ответе заголовок Server или X-Powered-By, у 447 из них был номер версии. Версию PHP через заголовок X-Powered-By открыто сообщали 272 сайта.
Распределение по этим 272: PHP 5.2 — 5 сайтов, 5.3 — 5, 5.4 — 4, 5.5 — 1, 5.6 — 39, 7.0 — 1, 7.1 — 10, 7.2 — 13, 7.3 — 8, 7.4 — 68, 8.0 — 8, 8.1 — 13, 8.2 — 49, 8.3 — 27, 8.4 — 17, 8.5 — 4. У 175 из 272 ветка без официальных обновлений: 86 сайтов на 5.x–7.3, для которых исправлений нет вовсе, и 89 на 7.4–8.1, где патч вышел только в исходниках.
Оговорка: это срез только тех, кто сам показывает версию PHP. Он не говорит, какая доля магазинов вообще работает на устаревших ветках, — зато показывает, что версия видна из интернета без всякого доступа. Похожую картину мы описывали в разборе по 487 осмотренным сайтам.
Наш бесплатный внешний осмотр — 54 проверки, без регистрации — показывает, раскрывает ли сервер версию технологии в заголовках Server и X-Powered-By. Если в X-Powered-By видна ветка PHP без обновлений, проверка T1-HDR-03 отмечает это как проблему: для 5.x–7.3 — серьёзную, для 7.4–8.1 — среднюю. Границы: если версия скрыта, осмотр её не увидит, конкретные CVE он не проверяет и не подтверждает, что сайт уязвим или взломан.
Чего мы пока не знаем
Нет данных, сколько сайтов в мире и в России реально уязвимы на 22 октября 2026 года: есть доли версий и оценки, но не измерение. Попытки атак фиксируют несколько компаний, однако успешных взломов конкретных сайтов с известным ущербом в открытых источниках на момент публикации не подтверждено. Неизвестно и то, сколько российских хостингов уже обновили PHP: публично известны только ограничения Beget.
Короткие ответы на частые вопросы
У меня WordPress, меня это касается?
Да. Уязвимость в самом PHP, а не в WordPress, поэтому обновление плагинов и движка её не закрывает. Нужно, чтобы хостинг обновил PHP до 8.2.35, 8.3.36, 8.4.27 или 8.5.12.
Как узнать версию PHP на своём сайте?
Зависит от доступа: версия видна в панели хостинга, на странице phpinfo, если она открыта, в заголовке X-Powered-By и в логе ошибок. Быстрее всего — тикет в поддержку с прямым вопросом, какая версия PHP обслуживает сайт и обновлена ли она после 21 октября.
Хостинг говорит, что обновил. Как проверить?
Зависит от того, видна ли версия. Попросите подтвердить конкретный номер версии, посмотрите заголовок ответа или phpinfo, затем проверьте формы и загрузку файлов — при смене версии они ломаются чаще всего. Если версия скрыта, проверить из интернета не получится.
Что делать, если сайт уже взломали?
Действовать нужно сразу: сменить пароли к админке, хостингу и базе данных, отозвать API-ключи, посмотреть логи и свежие файлы. Что именно смотреть и в каком порядке — в статье как понять, что сайт взломали.