Критическая уязвимость PHP: сотни тысяч сайтов под угрозой взлома. Что сделать сегодня

Закрыть уязвимость PHP2Shell можно одним способом: обновить PHP на сервере до версии 8.5.12, 8.4.27, 8.3.36 или 8.2.35 и перезапустить PHP-FPM или Apache. Обновление Битрикса, WordPress или другой CMS дыру не закрывает, она сидит в самом PHP. Если у сайта PHP 8.1 или более ранняя версия, официального выпуска для него нет: нужна сборка хостинга с исправлением либо переход на ветку 8.2 и новее.

Ниже весь путь по шагам. Как узнать свою версию без доступа к серверу, что нажать в панели хостинга, какие команды ввести на VPS, что учесть на Битриксе и WordPress, как понять, что сайт уже успели взломать. В конце три промта для нейросети: с ними обновление можно провести вместе с ChatGPT, Claude или GigaChat, даже если вы не программист.

С чего начать, зависит от того, где живёт сайт:

• обычный хостинг с панелью: раздел «Обновление на виртуальном хостинге», там же готовое письмо в поддержку;
• свой сервер или VPS: раздел «Обновление на VPS и выделенном сервере»;
• не знаете: отправьте письмо хостингу по шаблону из статьи или напишите нам.

Если разбираться некогда или доступов к серверу у вас нет, специалисты техподдержки Optimism бесплатно скажут, какая версия PHP стоит на вашем сайте и закрыта ли уязвимость, а при необходимости обновят PHP с резервной копией до любых изменений.

Что случилось и почему это касается вашего сайта

21 октября 2026 года команда PHP выпустила экстренное обновление сразу для четырёх веток языка. Оно закрывает две уязвимости, CVE-2026-109618 и CVE-2026-109619. Исследователи назвали связку PHP2Shell, по смыслу «из PHP в командную строку сервера». Обе получили 9,2 балла из 10 по шкале CVSS, это критический уровень.

Механика атаки неприятная. Злоумышленник отправляет на сайт специально собранный запрос и выполняет на сервере свой код. Пароль ему не нужен, ошибка в коде сайта тоже: уязвим сам интерпретатор PHP. На серверах с Apache и модулем mod_php атака срабатывает ещё до того, как запустится код вашего сайта, поэтому ни защита CMS, ни капча тут не помогают.

Затронуты все способы запуска PHP для веб-запросов: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. По данным исследователей из компании Calif, которые нашли проблему, самый ранний уязвимый путь тянется с PHP 5.4. Проще считать так: уязвим любой сайт на PHP, который не обновили после 21 октября.

Как развивались события:

• 17 октября. Amazon фиксирует первую попытку атаки в своих ловушках, за четыре дня до выхода исправления.
• 20 октября. Номера уязвимостей утекают в соцсети раньше срока, команда PHP выпускает исправление на сутки раньше плана.
• 21 октября, 16:34 по Москве. Выходят PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35.
• 22 октября. НКЦКИ публикует открытый бюллетень и рекомендует организациям, использующим PHP, обновиться. Немецкое ведомство по кибербезопасности BSI опровергает слухи о том, что исправление можно обойти.

Что сообщил НКЦКИ владельцам критической инфраструктуры

По сообщению РБК от 22 октября, НКЦКИ направил владельцам объектов критической информационной инфраструктуры письмо об устранении уязвимостей PHP. Редакция сообщает, что получила копию документа и подтверждение его подлинности от трёх организаций.

Получателям предложено обновить PHP, проверить серверы антивирусом и изучить журналы на следы взлома. Если быстро установить исправления невозможно, в письме предлагается рассмотреть временное ограничение внешнего доступа к уязвимым веб-серверам вплоть до их отключения. О подозрительных инцидентах следует сообщать в ГосСОПКА.

Это сообщение касается адресатов письма, владельцев объектов КИИ. Оно не означает, что любой интернет-магазин обязан отключить сайт. Владельцу обычного коммерческого сайта стоит запросить у хостинга подтверждение установленного исправления, а при задержке согласовать временные ограничения доступа с администратором. По сообщению РБК, проверка журналов нужна и после обновления, поскольку исправление уязвимости само по себе не исключает более раннего взлома.

Мы проверили утром 23 октября: последние версии PHP, которые закрывают обе уязвимости, вышли 21 октября, новых выпусков после этого нет. Зато сборки для хостингов, панелей и операционных систем продолжают приходить по нескольку раз в день, в том числе этой ночью. Номер версии PHP в них тот же, но для вашего сервера это и есть обновление, которое нужно поставить. Поэтому ситуацию стоит проверять каждый день, пока поток исправлений не утихнет. Мы держим руку на пульсе по проектам наших клиентов.

Масштаб для Рунета большой: по данным W3Techs, которые приводит РБК, на PHP работает около 91% русскоязычных сайтов с известным серверным языком. Оценки числа уязвимых ресурсов расходятся в десять раз. BI.ZONE говорит о 50 тысячах потенциально уязвимых веб-приложений, разбор «Российской газеты» называет «ориентировочно 500 тыс. ресурсов» и сам оговаривается, что PHP на сайте ещё не означает уязвимость.

«Полных временных мер нет, единственный безопасный выбор это обновление».

Команда PHP, официальное объявление о выпуске 21 октября 2026 года (в переводе)

Атаки уже идут: компании, которые следят за угрозами, сообщают о попытках взлома, Cloudflare говорит о миллионах попыток. Подтверждённых массовых взломов государственные центры на 22 октября не называют, а часть опубликованных эксплойтов против PHP в настройках по умолчанию не срабатывает.

Затишье обманчивое. Миллионы попыток означают, что сайты на PHP уже прочёсывают автоматическими сканерами. BSI предупреждает, что с появлением ИИ-инструментов злоумышленники разбирают исправление и собирают рабочий эксплойт за короткое время. Каждый взломанный сервер становится площадкой для следующих атак: на Хабре администратор описал VPS, который после странных сбоев PHP-FPM использовали для нападения на другие ресурсы, и хостинг его заблокировал. Связь именно с PHP2Shell автор не доказывал, но сценарий типичный. Британский эксперт по кибербезопасности Алан Вудворд в комментарии The Guardian ждёт «длинного хвоста» уязвимых сайтов и атак на недели и месяцы вперёд, а исследователь Кевин Бомонт назвал PHP2Shell одной из крупнейших уязвимостей за последние годы.

Паниковать рано, откладывать нельзя. Окно, когда массовых взломов ещё нет, это время, чтобы спокойно обновиться.

Ваша версия PHP и что делать сегодня

Найдите свою строку и выполните действие справа. Как узнать версию, расскажем в следующем разделе.

Ваша версия PHP	Безопасна ли	Что делать
8.5.12 и новее, 8.4.27 и новее, 8.3.36 и новее, 8.2.35 и новее	да	проверить, что новую версию используют все сайты и все процессы PHP (см. ниже)
8.5, 8.4, 8.3 или 8.2 ниже этих номеров	нет	обновить до исправленного выпуска своей ветки сегодня
8.1, 8.0, 7.4	нет, официального выпуска не будет	поставить сборку хостинга или дистрибутива с исправлением и срочно готовить переход на 8.3 или 8.4
7.3 и более ранние, вплоть до 5.4	нет, исправления от проекта PHP нет	спросить хостинг про сборку с исправлением (такие выпускают CloudLinux и репозиторий Ondřej Surý); нет сборки: закрыть сайт от интернета до перехода на поддерживаемую ветку
не знаю	считать уязвимой	узнать версию за пять минут по инструкции ниже

Для веток 7.4, 8.0 и 8.1 команда PHP выложила только минимальные исправления в исходном коде, для тех, кто собирает PHP сам. Готовые пакеты с ними выпускают хостинги и сборщики: cPanel, Plesk, CloudLinux, DirectAdmin, репозиторий Ondřej Surý, Red Hat, у Ubuntu через подписку Ubuntu Pro. Если ваш хостинг или администратор не подтвердил такую сборку, считайте сайт уязвимым.

Американское агентство CISA советует организациям, которые не могут обновиться немедленно или работают на PHP 8.1 и более ранних версиях, отключить такие системы от сети до обновления. Похожие советы дали NSA, CERT-EU, британский NCSC и BSI.

Отдельная заметка на будущее: ветка PHP 8.2 перестаёт получать исправления безопасности 31 декабря 2026 года. Если вы сейчас обновляетесь в пределах 8.2, через два месяца переезд всё равно придётся делать. Разумнее сразу планировать 8.3 или 8.4.

Как узнать версию PHP и закрыта ли дыра

Без доступа к серверу

Проще всего посмотреть в панели хостинга. Версия PHP почти всегда видна в настройках сайта: у Beget это раздел «Сайты», у ISPmanager «Сайты», у FASTPANEL настройки сайта. Если сайтов несколько, проверьте каждый и каждый поддомен: версия выбирается для них отдельно.

Второй путь через административную панель CMS. В WordPress откройте «Инструменты», затем «Здоровье сайта», вкладку «Информация» и раздел «Сервер». В 1С-Битрикс версия PHP видна в разделе «Настройки», «Инструменты», «Проверка системы».

Третий путь работает везде, где есть доступ к файлам сайта. Создайте в корне сайта файл со случайным именем, например info-7f3k.php, с одной строкой:

<?php phpinfo();

Откройте его в браузере: версия написана в первой строке, режим работы в строке Server API. Пока файл открыт, не заходите в админку в этом браузере: страница показывает cookie посетителя, а на части серверов и пароли из настроек окружения. Нейросети или подрядчику передавайте только две строки, PHP Version и Server API. Сразу после проверки удалите файл и убедитесь, что адрес отвечает ошибкой 404.

Если доступ к серверу есть

Номер версии в консоли и версия, которая реально обслуживает сайт, могут отличаться. Команда php -v показывает консольный PHP, а сайт работает через PHP-FPM или модуль Apache. К тому же процесс, запущенный до обновления, продолжает работать на старом коде из памяти, хотя на диске уже лежит новый. Поэтому самая надёжная проверка это снова открыть phpinfo в браузере после перезапуска PHP. Из консоли можно посмотреть так:

php -v
apache2ctl -M | grep php      # на RHEL и AlmaLinux: httpd -M | grep php
                              # есть php_module, значит у вас mod_php
sudo needrestart -b -r l      # Debian и Ubuntu: пустой вывод, значит всё перезапущено

Если версия 8.2.35, 8.3.36, 8.4.27, 8.5.12 или новее, всё в порядке. Ловушка ждёт тех, у кого PHP из пакетов самой операционной системы. Ubuntu, Debian и Red Hat часто добавляют исправление без смены номера версии: в Ubuntu 24.04 после обновления PHP по-прежнему называется 8.3.6. В таком случае сверяйте версию пакета. Исправленные пакеты в Ubuntu 24.04 начинаются с 8.3.6-0ubuntu0.24.04.13, в Ubuntu 22.04 с 8.1.2-1ubuntu2.28.

dpkg -l 'php*' | awk '/^ii/{print $2, $3}'                     # Debian и Ubuntu
rpm -q --changelog php-common | grep -E 'CVE-2026-10961[89]'   # AlmaLinux, Rocky, RHEL

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

Обновление на виртуальном хостинге

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

• Beget сообщил, что обновил все версии PHP на виртуальном хостинге сам, клиентам действий не требуется. На VPS и в облаке обновлять PHP клиент должен самостоятельно.
• «Рунити» (Рег.ру, RU-CENTER, SpaceWeb) временно ограничивала загрузку файлов в части интерфейсов, у клиентов при этом появлялась ошибка 403 при загрузке файлов. К вечеру 22 октября ограничения сняли.
• Облачный Битрикс24 обновляет сам 1С-Битрикс, клиенту ничего делать не нужно. Временные ограничения затрагивали формы, CRM и бизнес-процессы.
• У остальных крупных хостингов публичных заявлений на утро 23 октября мы не нашли. Напишите в поддержку, шаблон ниже.

Если у вас ветка 8.2 или новее, ветку в панели не трогайте: хостинг ставит исправление внутри неё. Переключать нужно, только если стоит 8.1 или более ранняя версия. Смена ветки, например с 7.4 на 8.2, может сломать сайт, поэтому сначала резервная копия, потом проверка форм и оплаты. Как переключить версию PHP в панели (на примере инструкций Beget для трёх популярных панелей):

• Панель Beget: «Сайты», «Управление сайтами», шестерёнка у нужного домена, выбрать PHP 8.2 или новее. Обычно переключение занимает до десяти минут.
• ISPmanager: «Сайты», «Изменить параметры сайта», версия PHP.
• FASTPANEL: «Настройки», «Приложения», затем выбор версии в настройках сайта.

Письмо в поддержку хостинга, можно копировать как есть:

Здравствуйте!

Мой сайт: example.ru (договор или логин: ...).
В связи с уязвимостями PHP CVE-2026-109618 и CVE-2026-109619 (PHP2Shell) прошу подтвердить:

1. Обновлён ли PHP на сервере моего сайта до исправленной версии
   (8.5.12, 8.4.27, 8.3.36, 8.2.35 или сборки с бэкпортом исправления)?
2. Какая версия PHP и какой режим (PHP-FPM, mod_php, CGI) сейчас обслуживают сайт?
3. Перезапущены ли процессы PHP после обновления?
4. Видели ли вы попытки атак на мой сайт с 17 октября 2026 года?

Если обновление ещё не установлено, прошу сообщить срок.
Спасибо!

Обновление на VPS и выделенном сервере

Здесь PHP обновляете вы или ваш администратор. Порядок одинаковый для любой системы, отличаются команды.

1. Сделайте резервную копию файлов сайта, базы данных и конфигурации сервера. Проверьте, что копия открывается.
2. Обновите пакеты PHP.
3. Перезапустите PHP-FPM или Apache. Перезапуска одного nginx недостаточно: процессы PHP продолжат работать на старом коде из памяти.
4. Проверьте, что новая версия обслуживает сайт, и пройдите по ключевым функциям: вход, формы, загрузка файлов, оплата, обмен с 1С.

Debian и Ubuntu

Пакеты самих дистрибутивов получили исправления 21 октября: в Debian бюллетени DSA-6574-1 и DLA-4848-1, в Ubuntu USN-8948-1. Для старых Ubuntu 20.04 и ниже исправление доступно через подписку Ubuntu Pro.

sudo apt update
apt list --upgradable 2>/dev/null | grep php                       # что будет обновлено
sudo apt install --only-upgrade 'php8.3*' 'libapache2-mod-php8.3'  # цифры по вашей ветке
sudo systemctl restart php8.3-fpm                                  # для mod_php: sudo systemctl restart apache2

Строки «Skipping…, it is not installed» нормальны: так apt пропускает пакеты, которых на сервере нет. В Debian 12 из коробки ветка 8.2, в Debian 13 ветка 8.4, подставьте свои цифры.

Если на сервере несколько версий PHP или свежая ветка, PHP обычно ставят из репозитория Ondřej Surý. Исправленные сборки 8.2.35, 8.3.36, 8.4.27, 8.5.12 и пакеты с исправлением для 7.4, 8.0 и 8.1 там есть. В первые сутки основной сервер репозитория отвечал ошибкой 503, администраторы на Хабре выручались зеркалом Яндекса mirror.yandex.ru. Для серверов на процессорах ARM исправленные сборки там на утро 23 октября догнали ещё не все ветки.

AlmaLinux, Rocky, CentOS, RHEL

AlmaLinux выпустила исправления 21 октября, Red Hat выпустила бюллетень RHSB-2026-013. Про репозиторий Remi, которым пользуется много серверов, в день выпуска предупреждали, что обновлений там в этот день не будет (так писал, например, CERT-EU). Но сборки всех веток появились там уже 21 октября, а 22 октября автор подтвердил исправление в блоге.

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm      # для mod_php: sudo systemctl restart httpd
                                    # несколько версий из Remi: службы вида php84-php-fpm

Docker

Официальные образы php обновлены 21 октября. Обновить пакеты внутри работающего контейнера мало: пересоберите образ на свежей базе и пересоздайте контейнер, сохранив тома с данными. Если в Dockerfile жёстко прописан номер, например php:8.3.35-fpm, замените его на исправленный.

docker compose pull
docker compose build --pull
docker compose up -d --force-recreate
docker compose exec <имя сервиса> php -v

Панели cPanel, Plesk, DirectAdmin

cPanel 21 октября выпустил исправленные пакеты PHP для веток с 8.2 по 8.5 и пересобрал с исправлением пакеты 7.4, 8.0 и 8.1. Plesk и DirectAdmin тоже выпустили сборки, включая исправления для 7.4, 8.0 и 8.1. Обновите систему штатным механизмом панели.

1С-Битрикс, WordPress и другие CMS: что важно знать

Главное правило для любой CMS: обновление самой системы уязвимость не закрывает. Лечится только серверный PHP. Хорошая новость в том же: если у вас ветка 8.2, 8.3, 8.4 или 8.5, менять её не нужно, достаточно поставить исправленный выпуск той же ветки. Код сайта при этом не меняется, модули не ломаются.

Tilda и другие конструкторы работают как сервис, и PHP там обновляет платформа. WordPress, 1С-Битрикс, MODX, Joomla, Drupal и большинство других популярных в Рунете CMS стоят на хостинге владельца, и PHP там обновлять владельцу или его хостингу.

1С-Битрикс и коробочный Битрикс24

Центр кибермониторинга 1С-Битрикс в рассылке 21 октября написал прямо: обновление продукта через SiteUpdate не обновляет серверный PHP. Минимальная версия PHP для актуальных обновлений Битрикса с февраля 2026 года 8.2, рекомендуемая 8.3 и выше.

Если сайт работает на виртуальной машине BitrixVM 9:

1. Сделайте снимок виртуальной машины или полную копию сайта и базы.
2. Обновите пакеты PHP текущей ветки. BitrixVM берёт PHP из репозитория Remi, и исправленные сборки 8.2.35, 8.3.36, 8.4.27 и 8.5.12 там уже есть.
3. Перезапустите Apache: в BitrixVM PHP работает модулем Apache, и перезапуск одного nginx его не обновит.
4. Проверьте версию в админке, вход, CRM, загрузку файлов, Диск, почту и обмен с 1С. Если серверов в пуле несколько, обновите каждый.

sudo dnf clean metadata
sudo dnf upgrade 'php*'
rpm -q php-common                     # ожидаем 8.2.35, 8.3.36, 8.4.27 или 8.5.12
sudo systemctl restart httpd.service

Сменить ветку PHP в BitrixVM 9 можно через меню виртуальной машины: «Manage servers in the pool», затем «Update PHP, MySQL, PostgreSQL». Если сайт ещё на PHP 7.x или 8.0, переход проходит в определённом порядке: резервная копия, обновление ядра и всех модулей, обновление решений из Marketplace, затем новая ветка PHP и повторная установка обновлений. Свежие версии ядра Битрикса работают только в кодировке UTF-8, поэтому сайты в windows-1251 по дороге обычно приходится конвертировать. Это не работа на один вечер, поэтому на время перехода включите временные меры из следующего раздела.

Облачный Битрикс24 обслуживает сам 1С-Битрикс, там делать ничего не нужно.

WordPress

WordPress.org 21 октября сообщил, что обновление WordPress для этих уязвимостей не требуется и не планируется. Обновлять нужно PHP. Текущие версии WordPress 7.0 и 7.1 совместимы с PHP от 7.4 до 8.5, а для новых установок команда хостинга WordPress советует 8.4 или 8.5.

Версию PHP видно в консоли: «Инструменты», «Здоровье сайта», «Информация», «Сервер». Ядро WordPress новые ветки PHP переносит спокойно, ломаются обычно заброшенные плагины и темы. Перед сменой ветки сделайте копию сайта, включите журнал ошибок WP_DEBUG_LOG и пройдите по формам, корзине и оплате.

Drupal, Joomla, MODX, OpenCart и другие

CMS	Какие ветки PHP поддерживает	На что обратить внимание
Drupal 10	8.1 до 8.4	на PHP 8.1 нужен пакет с исправлением от дистрибутива или переход на 8.2+; поддержка Drupal 10 заканчивается в декабре 2026
Drupal 11	8.3 и 8.4, с версии 11.3 ещё 8.5	достаточно исправленного выпуска своей ветки
Joomla 5	от 8.1, рекомендована 8.3	на 8.1 тот же вопрос, что у Drupal 10
Joomla 6	от 8.3, рекомендована 8.4	достаточно исправленного выпуска
MODX 3	от 8.1, рекомендована 8.2+	у MODX 2 совместимость с 8.3 и 8.4 официально не описана, проверяйте на копии
OpenCart 4	от 8.0	многие платные расширения закодированы ionCube, см. ниже
PrestaShop 8	до 8.1 включительно	исправленного выпуска 8.1 от проекта PHP нет: только пакет с исправлением или переход на PrestaShop 9
Magento 2.4.4 и 2.4.5	только 8.1	та же ловушка, что у PrestaShop 8; у 2.4.6 есть ветка 8.2
UMI.CMS	8.2 и 8.3	достаточно исправленного выпуска

Тем, у кого стоят платные модули, закодированные ionCube (такие часто встречаются в Marketplace Битрикса, у OpenCart и DataLife Engine), стоит помнить одну деталь. Исправленный выпуск внутри ветки, например с 8.3.35 на 8.3.36, такие модули не ломает. Переход с 8.1 и более ранних веток на 8.3 или 8.4 такие модули ломает, пока разработчик модуля не выпустит сборку под новую ветку. Поэтому сначала закройте дыру внутри своей ветки, а переезд планируйте отдельно.

Tilda, InSales, Wix и другие конструкторы

Сервером здесь управляет платформа, владельцу обновлять нечего. Проверьте только то, что живёт отдельно на вашем хостинге: обработчики форм, скрипты интеграций, старые поддомены и лендинги, страницы оплаты. Их обновляйте по инструкции выше.

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

Бывает, что обновление упирается в старый код, который на новой ветке PHP не заведётся, или в подрядчика, который выйдет на связь только завтра. Временные меры снижают риск, но ни одна не делает сайт безопасным. Это прямо пишут и команда PHP, и BSI, и CERT-EU.

Мера	Что даёт	Чего не даёт
session.upload_progress.enabled = Off в php.ini или настройках пула (в BitrixVM в файле /etc/php.d/z_bx_custom.ini), затем перезапуск PHP	закрывает подтверждённые пути атаки через сессии, их используют чаще всего	не закрывает первую уязвимость и другие варианты второй; через ini_set и .user.ini не работает
ограничить размер и число частей запросов multipart/form-data на веб-сервере	мешает довести PHP до нехватки памяти, на этом построена первая уязвимость	не гарантирует защиту; формы с файлами могут сломаться
правила WAF (у хостинга, облачного WAF или Cloudflare)	Cloudflare включил правила против PHP2Shell для всех клиентов, включая бесплатный тариф	защищает только трафик, который идёт через WAF, и только известные варианты атаки; путь через нехватку памяти WAF не блокирует
закрыть от интернета весь сайт: доступ по IP или VPN, страница обслуживания на уровне сервера	убирает риск на время работ	сайт недоступен клиентам; закрыть одну админку бесполезно, атака срабатывает на любой странице

Осторожно с советом поставить memory_limit = -1. Он входит в список мер команды PHP, но без внешнего ограничения памяти первый же тяжёлый экспорт или атака может положить сервер целиком.

Сергей Боярский, глава думского комитета по информационной политике, IT и связи, 22 октября напомнил, что временное отключение сайта само по себе не означает, что его взломали. Это предупредительная мера, и в ситуации без исправления она честнее, чем надежда на удачу.

Что проверить после обновления

Обновить и забыть не получится. Пройдите короткий список.

1. Новая версия работает везде. Все сайты, поддомены, пулы PHP-FPM и все серверы, если их несколько. Контейнеры пересобраны вместе с хостом.
2. Ключевые функции живы. Вход в личный кабинет и админку, формы заявок, загрузка файлов, корзина и оплата, обмен с 1С и CRM, почта с сайта.
3. Известная ошибка выпусков 8.4.27 и 8.5.12. Сразу после выхода разработчики нашли сбой при работе с SimpleXML (задача 24488 в репозитории PHP): код, который разбирает XML, может падать с ошибкой памяти. Исправление уже влито в код PHP, но отдельной версии с ним пока нет. Если после обновления упали выгрузки товаров, импорт прайсов или обмен с 1С через XML, причина может быть здесь. Откатываться на прежнюю версию PHP нельзя, она уязвима: чините приложение или дождитесь следующего выпуска.
4. Журналы ошибок. Первые сутки после обновления смотрите журнал PHP и веб-сервера на новые фатальные ошибки.

Как понять, что сайт уже взломали

Попытки атак Amazon фиксирует с 17 октября, поэтому британский NCSC советует тем, кто не может обновить или отключить систему немедленно, сначала проверить её на признаки взлома и бэкдоры. Исправление закрывает дверь, но не выгоняет того, кто уже вошёл.

Признаки, на которые указывают CISA, BSI, Amazon и Datadog:

• в журнале веб-сервера всплески POST-запросов с ответами 500 или 502, падения процессов PHP (в журнале Apache строка Segmentation fault); поле PHP_SESSION_UPLOAD_PROGRESS в теле запросов видно только в журналах WAF или Cloudflare, обычный журнал доступа тела запросов не пишет;
• в журнале PHP ошибки нехватки памяти с припиской «in Unknown on line 0»;
• процессы PHP или веб-сервера запускают sh, bash, curl, wget;
• новые или изменённые PHP-файлы в папках загрузок, новые задания cron, незнакомые администраторы в CMS.

Быстрая проверка на сервере (только чтение, ничего не меняет):

# PHP-файлы, появившиеся или изменённые с 17 октября 2026 года (без кэша)
sudo find /var/www ~bitrix/www -name '*.php' -newerct '2026-10-17' -not -path '*/cache/*' -ls 2>/dev/null

# PHP-файлы там, где их быть не должно
sudo find /var/www ~bitrix/www -path '*upload*' -name '*.php' -ls 2>/dev/null

# POST-запросы, на которые сервер ответил ошибкой 5xx (с архивами журналов)
zgrep -h '"POST ' /var/log/nginx/access.log* /var/log/apache2/access.log* /var/log/httpd/access_log* 2>/dev/null | grep -E '" 50[0-9] '

# Падения процессов Apache
zgrep -h 'Segmentation fault' /var/log/apache2/error.log* /var/log/httpd/error_log* 2>/dev/null

# Нехватка памяти при старте запроса
zgrep -h 'Allowed memory size.*Unknown on line 0' /var/log/nginx/error.log* /var/log/apache2/error.log* /var/log/httpd/error_log* /var/log/php*-fpm.log 2>/dev/null

Пути к сайту и журналам у вас могут отличаться, запись ~bitrix/www означает папку сайта на виртуальной машине BitrixVM. Время изменения файла злоумышленник подделывает одной командой, поэтому поиск идёт по времени смены записи о файле (-newerct). Строка «Unknown on line 0» бывает и безобидной, например при превышении лимита размера запроса: смотрите на неё вместе с остальными признаками. В 1С-Битрикс дополнительно запустите «Сканер безопасности» и «Контроль целостности» в модуле «Проактивная защита». В WordPress проверить, не изменены ли файлы ядра, можно командой wp core verify-checksums.

Если нашли следы взлома:

1. Отключите сайт от интернета или закройте его страницей обслуживания на уровне сервера.
2. Не удаляйте подозрительные файлы сразу. Сохраните копию сервера и журналов, они нужны, чтобы понять, что именно сделал злоумышленник.
3. Смените все пароли и ключи. Это хостинг, база данных, SSH, админка CMS, ключи платёжных систем и API в настройках сайта.
4. Восстановите код сайта из чистой копии, сделанной до 17 октября, или переустановите ядро CMS. Заказы, клиентов и заявки за последние дни перенесите отдельно после проверки, иначе вместе с заразой потеряете неделю продаж. Затем обновите PHP и только потом возвращайте сайт в сеть.
5. Если на сайте были персональные данные клиентов, оцените, не было ли утечки. Закон о персональных данных требует уведомить Роскомнадзор об инциденте в течение суток с момента, когда его выявили, а о результатах расследования сообщить в течение трёх суток.

Это работа, где спешка стоит дороже всего: поспешная чистка уничтожает следы, и через неделю взлом повторяется через оставленный бэкдор. Если не уверены, что справитесь, лучше позвать специалистов. Наша техническая поддержка находит вредоносный код, закрывает уязвимость и разбирает причину инцидента, чтобы взлом не повторился.

Промты для нейросети: обновление вместе с ИИ

Нейросеть хорошо справляется с ролью терпеливого администратора-наставника: объяснит, что значит строка в phpinfo, подберёт команды под вашу систему, разберёт журнал. Три правила безопасности, без которых промты ниже лучше не использовать:

• не отправляйте в чат пароли, ключи API и персональные данные клиентов; перед отправкой журналов замените IP-адреса и почты клиентов;
• не выполняйте команду, смысл которой не понимаете; попросите нейросеть объяснить её построчно;
• до любых изменений сделайте резервную копию.

Промт 1. Для владельца сайта без технических знаний

Ты опытный системный администратор и помогаешь владельцу сайта, который не программист.
Ситуация: 21 октября 2026 года вышли исправления PHP против уязвимостей CVE-2026-109618
и CVE-2026-109619 (PHP2Shell). Исправленные версии: 8.5.12, 8.4.27, 8.3.36, 8.2.35.
Для 7.4, 8.0 и 8.1 бывают сборки хостингов с исправлением без смены номера версии.
Обновление CMS уязвимость не закрывает, нужно обновить серверный PHP.

Мои данные:
- CMS: [1С-Битрикс / WordPress / другая]
- Хостинг: [название] , тариф: [виртуальный хостинг / VPS / свой сервер / не знаю]
- Версия PHP и Server API из панели или из phpinfo (только эти две строки, не всю страницу): [...]

Задачи:
1. Скажи, уязвим ли мой сайт, и объясни почему простыми словами.
2. Дай пошаговую инструкцию, что нажать в панели моего хостинга или что написать в поддержку.
3. Перечисли, что проверить на сайте после обновления.
Правила: не придумывай пункты меню, которых не знаешь точно, так и скажи.
Если данных не хватает, задай мне вопросы, прежде чем советовать.
Не предлагай ничего удалять.

Промт 2. Для администратора с доступом к серверу

Ты старший Linux-администратор. Помоги безопасно обновить PHP на сервере из-за
уязвимостей CVE-2026-109618 и CVE-2026-109619 (PHP2Shell, исправлены 21.10.2026
в PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35; затронуты PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed).

Работаем строго по шагам. На каждом шаге дай ОДНУ команду или небольшой блок,
объясни, что он делает, и жди, пока я пришлю вывод. Не переходи дальше без вывода.

Шаг 1. Инвентаризация: ОС и её версия, все установленные версии PHP, какие SAPI
используются (FPM, mod_php, CGI), какие пулы FPM и какие сайты на какой версии,
есть ли контейнеры Docker. Только команды чтения.
Шаг 2. Проверка, исправлен ли уже PHP: по версии и по changelog пакета
(исправление бывает бэкпортом без смены номера).
Шаг 3. План обновления под мою систему и источник пакетов (дистрибутив,
packages.sury.org или ppa:ondrej/php, Remi, образы Docker), с оценкой риска.
Шаг 4. Резервная копия файлов, базы и конфигурации, с проверкой, что копия читается.
Шаг 5. Обновление и перезапуск именно процессов PHP (FPM или Apache, не только nginx).
Шаг 6. Проверка, что сайт обслуживает исправленная сборка, и проверка журналов.

Запреты: никаких rm, никаких изменений конфигурации без моего «да»,
никаких сторонних неофициальных патчей и скриптов вида curl | bash.
Не проси пароли и ключи. Не предлагай команды, которые печатают содержимое
файлов с настройками доступа к базе (wp-config.php, /bitrix/.settings.php,
dbconn.php, файлы окружения), а также переменные окружения процессов.
Если в моём выводе мелькнул пароль, скажи мне его замазать.
Не предлагай откат на прежнюю версию PHP: она уязвима.
Если не уверен в команде для моей системы, скажи об этом прямо.

Промт 3. Проверка журналов на следы атаки

Ты специалист по реагированию на инциденты. Проанализируй фрагмент журнала
веб-сервера и журнала PHP на признаки эксплуатации PHP2Shell
(CVE-2026-109618, CVE-2026-109619), попытки которой фиксируются с 17.10.2026.

Ищи: POST-запросы с полем PHP_SESSION_UPLOAD_PROGRESS; необычные multipart/form-data
запросы, после которых идут ошибки 500 или падения воркеров; ошибки памяти
с текстом «in Unknown on line 0»; запросы к новым или странным .php-файлам,
особенно в папках загрузок; признаки запуска sh, curl, wget.

Для каждой находки: строка журнала, почему она подозрительна, насколько уверен
(высоко, средне, низко). Отдельно перечисли, что проверить на сервере дальше
командами только для чтения. Если признаков нет, так и скажи и не выдумывай.

Журнал (IP-адреса клиентов и почты заменены):
[вставь фрагмент]

Как устроить сайт, чтобы следующая дыра не застала врасплох

PHP2Shell не первая и не последняя критическая уязвимость. Особенность этой в скорости: CJ Moses, директор по информационной безопасности Amazon, советует измерять сроки установки исправлений часами, потому что запаса в семь или тридцать дней больше нет. Значит, выигрывает тот, у кого обновление отрепетировано заранее.

Что для этого нужно:

• Поддерживаемая ветка PHP. Сайты на 7.4 и 8.1 оказались в худшем положении: для них нет нормального выпуска, и переезд приходится делать в аварийном режиме. План перехода на 8.3 или 8.4 стоит составить сейчас, до конца поддержки 8.2 31 декабря 2026 года.
• Тестовая копия сайта. Обновление сначала проверяется на копии, потом выкатывается на рабочий сайт. Так полчаса проверки заменяют день простоя.
• Резервные копии, которые проверены восстановлением. Копия, которую ни разу не разворачивали, остаётся надеждой. Храните её отдельно от сервера сайта.
• Мониторинг. Доступность сайта, изменения файлов, новые администраторы, необычные процессы. Взлом, замеченный в первый час, стоит в разы дешевле взлома, замеченного через месяц.
• Ответственный за обновления. Человек или подрядчик, который узнаёт о критической уязвимости в день выхода и знает, что делать с вашим сервером.

Если сайт работает на устаревшем движке, иногда честнее его переписать, чем латать, и мы писали, как выбрать подрядчика на разработку сайта, чтобы доступы и сервер остались у вас. Общий взгляд на тему собран в статье что такое безопасность сайта и как её улучшить. А про то, почему Битрикс отказался от старых версий PHP ещё в 2023 году, читайте в материале о прекращении поддержки PHP ниже 8.0 в 1С-Битрикс.

Что сделать сегодня

1. Узнайте версию PHP каждого своего сайта.
2. Если версия ниже 8.5.12, 8.4.27, 8.3.36 или 8.2.35 и хостинг не подтвердил исправленную сборку, обновитесь или напишите в поддержку хостинга по шаблону выше.
3. Перед обновлением сделайте резервную копию, после обновления перезапустите PHP и проверьте ключевые функции сайта.
4. Проверьте журналы и файлы на признаки взлома с 17 октября.
5. Если у вас PHP 8.2 или более ранняя версия, поставьте в план переход на 8.3 или 8.4.

Весь порядок работ собран на одной странице: чек-лист для вебмастера в PDF. Его удобно переслать администратору или подрядчику, он читается без статьи.

Как мы защищаем сайты наших клиентов

Optimism сопровождает сайты с 2000 года. За эти годы через взломы, заражения и срочные обновления мы провели сотни клиентских сайтов и собственные проекты, включая optimism.ru. Имена клиентов не называем: такие истории закрыты соглашением о конфиденциальности, и ни одному владельцу не понравилось бы читать о своём сайте в чужом блоге.

Что можем сделать прямо сейчас:

• Бесплатно: экспресс-проверка, какая версия PHP стоит на вашем сайте и закрыта ли уязвимость. Нам хватит адреса сайта и скриншота из панели хостинга или двух строк phpinfo.
• Бесплатно: внешний технический аудит сайта, чтобы вы увидели, как мы работаем, и получили список рисков на руках.
• Срочное обновление PHP как разовая работа, от 20 000 ₽. Перед изменениями делаем резервную копию сайта и базы, обновление проверяем на тестовой копии и только потом выкатываем.
• Помощь при взломе: найдём вредоносный код, закроем уязвимость, восстановим сайт и разберём, как злоумышленник попал внутрь.
• Постоянная техническая поддержка от 23 000 ₽ в месяц: мониторинг доступности, ежедневная проверка на вредоносный код, резервные копии и обновления без аврала.

Работаем с 1С-Битрикс, WordPress, Joomla, Drupal, NetCat и самописными системами. Звоните +7 (495) 118-20-98 или пишите на go@optimism.ru, в теме письма достаточно написать «PHP2Shell» и адрес сайта.

Частые вопросы

Нужно ли что-то делать, если сайт на виртуальном хостинге, а я не программист

Проверить, что хостинг обновил PHP, и выбрать в панели поддерживаемую ветку. Часть хостингов, например Beget, обновила PHP на виртуальном хостинге сама. Если хостинг молчит, отправьте письмо по шаблону из статьи.

Хватит ли обновить 1С-Битрикс через SiteUpdate

Нет. SiteUpdate обновляет продукт, а уязвимость в серверном PHP. 1С-Битрикс в рассылке своим клиентам написал об этом прямо.

Закрывает ли уязвимость обновление WordPress

Нет. WordPress.org сообщил, что обновление WordPress для этих уязвимостей не требуется и не планируется. Исправление только в PHP.

Почему php -v показывает 8.3.6, хотя хостинг пишет, что исправление стоит

Чаще всего прав хостинг. Ubuntu и Debian добавляют исправление, не меняя номер версии PHP. Сверьте версию пакета командой из раздела про проверку версии.

Что делать сегодня, если сайт держится на PHP 7.4

Попросить хостинг или администратора поставить сборку 7.4 с исправлением: она есть у cPanel, Plesk, CloudLinux, DirectAdmin и в репозитории Ondřej Surý, у Ubuntu через подписку Ubuntu Pro. Включить временные меры из таблицы выше. И начать переход на поддерживаемую ветку: исправлений для 7.4 в будущем может не быть.

Помогает ли отключение session.upload_progress

Частично. Оно закрывает самые частые пути атаки через сессии, но не первую уязвимость. Команда PHP прямо пишет, что полных временных мер нет.

Касается ли уязвимость сайтов на Tilda, Wix и в облачном Битрикс24

Сайты на конструкторах обслуживает платформа, облачный Битрикс24 обновила сама компания 1С-Битрикс. Проверьте только отдельные PHP-скрипты и сайты, которые вы держите у себя на хостинге, если они есть.

Сколько стоит обновление PHP у подрядчика

Зависит от того, нужен ли переход на новую ветку. Обновление в пределах ветки на исправленную версию это часы работы. Переход с 7.4 на 8.3 на сайте с самописными модулями может занять дни. В Optimism срочное обновление PHP стоит от 20 000 ₽, а проверку версии и закрыта ли уязвимость мы делаем бесплатно.

Как понять, что сайт уже взломали

Смотрите новые PHP-файлы с 17 октября, особенно в папках загрузок, незнакомых администраторов, новые задания cron, запуск sh, curl, wget от имени веб-сервера и запросы с PHP_SESSION_UPLOAD_PROGRESS в журнале. Команды есть в разделе про взлом.

Источники

Официальные объявления

• PHP. Объявления о выпусках PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 и описание уязвимостей, 21 октября 2026
• PHP Foundation. Today’s PHP security release and how we’re strengthening PHP security, 21 октября 2026
• НКЦКИ. НКЦКИ предупреждает об угрозе эксплуатации уязвимостей в PHP, 22 октября 2026
• ФСТЭК России, Банк данных угроз. BDU:2026-17191 и BDU:2026-17192, 21 октября 2026

Государственные центры кибербезопасности

• CISA. Critical Vulnerabilities in PHP Require Immediate Patching, 21 октября 2026
• NCSC UK. Critical security issue affecting PHP, 21 октября 2026
• BSI. Предупреждение о PHP2Shell, версия 1.2, 22 октября 2026

Исследователи и платформы

• Amazon Threat Intelligence. PHP2Shell exploitation prior to public disclosure, 21 октября 2026
• 1С-Битрикс. Уязвимости в PHP: что важно знать пользователям Битрикс24 и «1С-Битрикс: Управление сайтом», 21 октября 2026
• WordPress.org. Critical PHP security release, 21 октября 2026

Рынок и эксперты

• РБК. Материалы об уязвимостях PHP и оценки экспертов, 21 и 22 октября 2026
• Beget. Уязвимость в PHP от 21.10.2026

Теги публикации: BitrixVM, CVE-2026-109618, CVE-2026-109619, PHP2Shell, безопасность сайта, как обновить php, обновить php wordpress, обновление php битрикс, техническая поддержка сайта, уязвимость php