PHP2Shell: как проверить, уязвим ли ваш сайт, и что делать

Что случилось: PHP2Shell простыми словами

PHP — это «движок», который превращает код сайта в страницы. Он стоит на сервере под WordPress, 1С-Битриксом, Joomla, OpenCart и под большинством самописных сайтов. Если сравнивать сайт с магазином, то CMS — это витрина и касса, а PHP — само здание. На этот раз трещина нашлась в здании.

Обе уязвимости — ошибки работы с памятью внутри PHP. Одна (CVE-2026-109619) оставляет «мусор» от одного запроса к сайту, а следующий запрос может прочитать его и переписать; вторая (CVE-2026-109618) срабатывает, когда PHP не хватает памяти в середине обработки запроса. В худшем случае злоумышленник, отправив на сайт специально собранные запросы, может выполнить на сервере свой код — без логина и пароля. В мире безопасности это называют RCE, удалённым выполнением кода, и это самый опасный класс уязвимостей.

Название PHP2Shell придумали не разработчики PHP, а исследователи и журналисты: «shell» — это доступ к командной строке сервера, то есть та самая цель злоумышленника. Хронология получилась нервной — детали утекли в соцсети раньше времени, и выпуск исправлений пришлось ускорить.

Откуда даты: php.net, бюллетени PHP GHSA-w8hw-w9fx-j79w и GHSA-6wmf-4rv5-p3rp, Huntress, watchTowr, Cloudflare, Beget, Sophos, SANS ISC, Хабр и РБК (письмо НКЦКИ — в пересказе, оригинал не публиковался), каталог CISA KEV — ссылки в разделе «Источники».

Насколько это опасно на самом деле

Новости пестрят заголовками про «70 % интернета» и «22 млн уязвимых серверов». Это правда в том смысле, что PHP стоит почти везде, — но это цифры о том, где может сработать атака, а не о том, сколько сайтов взломано. Разложим по полочкам, что известно на 24 октября 2026 года.

Почему уязвимости всё-таки критические. Обе получили оценку 9.2 по шкале CVSS v4 — это верх шкалы. Атака идёт по сети, не требует пароля и действий пользователя, а функция, через которую работает одна из уязвимостей (отслеживание прогресса загрузки файлов в сессии), включена в PHP по умолчанию, причём сайту даже не нужно её использовать.

Почему паниковать рано. В той же оценке стоит пометка «высокая сложность атаки» и «нужны предварительные условия». Исследователи, которые разбирали опубликованные эксплойты, пишут одно и то же: они работают только в лабораторных условиях — на конкретной сборке PHP, с урезанным лимитом памяти, с одним рабочим процессом.

Откуда цифры: Rapid7, Sansec, SANS ISC, Cloudflare, Canadian Centre for Cyber Security (AL26-026), SecurityLab — ссылки в разделе «Источники».

Что из этого следует для бизнеса. Окно, когда эксплойты ещё ненадёжны, — лучшее время спокойно обновиться. Обычно такие окна закрываются: исследователи и злоумышленники дорабатывают инструменты, и через недели «лабораторная» атака становится массовой. Ровно поэтому специалисты SANS формулируют совет так:

Кого касается: WordPress, Битрикс, самописные сайты и хостинги

Короткий ответ: любого сайта, где PHP отвечает на запросы из интернета, если версия PHP ниже исправленной. А это большинство: по данным W3Techs на 24 октября 2026 года, PHP работает на 69,3 % сайтов, у которых известен серверный язык, а среди русскоязычных — на 90,8 %. Уязвимость в самом PHP, поэтому неважно, какая CMS стоит сверху. Исследователи Wiz воспроизвели атаку на тестовых установках WordPress, Drupal и Joomla, а канадский центр кибербезопасности и Field Effect отдельно подчёркивают: атака срабатывает раньше, чем запускается код самого сайта.

Что это значит для разных типов сайтов:

• WordPress. Касается, если PHP не обновлён. Обновление WordPress, темы и плагинов PHP2Shell не закрывает (хотя делать его всё равно нужно — это самый частый путь взлома WordPress в обычные дни).
• 1С-Битрикс. Битрикс работает на PHP, значит, под тем же риском, что и остальные. Официальных заявлений 1С-Битрикс о PHP2Shell мы в открытых источниках не нашли — поэтому ориентируйтесь на версию PHP, а не на версию Битрикса.
• Самописные сайты на PHP. Касается так же. Для атаки не нужен ваш код и даже вызов сессий в нём.
• Сайты на конструкторах (Тильда, Wix и т. п.). PHP там, если он есть, обслуживает платформа, и обновлять его — её задача. Вам делать ничего не нужно.

В зоне .ru из трёх самых популярных систем две работают на PHP: WordPress и 1С-Битрикс вместе — почти половина сайтов с известной CMS.

Как узнать версию PHP своего сайта

Это главный шаг — и он занимает пару минут. Есть три способа, начинайте с первого.

Версия PHP почти всегда видна в панели хостинга — в разделе сайтов или настроек PHP.

Способ 1. Панель хостинга. Зайдите в личный кабинет хостинга и найдите раздел «Сайты», «Настройки PHP» или «Версия PHP» — там указана ветка (например, 8.3), а иногда и точный номер. Если указана только ветка, переходите ко второму или третьему способу: важно знать точный номер — 8.3.36 и 8.3.30 — это «исправлено» и «уязвимо».

Откуда: справки хостингов, проверено 24.10.2026. Интерфейсы меняются — если пункта нет, ищите «PHP» в настройках сайта.

Способ 2. Файл phpinfo. Создайте в корне своего сайта файл со случайным именем, например check-7f3a.php, с одной строкой <?php phpinfo();, откройте его в браузере и посмотрите строку «PHP Version» в самом верху. Сразу после этого удалите файл — он показывает настройки сервера, и оставлять его открытым нельзя.

Способ 3. Спросить хостинг. Напишите в поддержку: «Какая точная версия PHP используется для сайта example.ru? Установлены ли исправления CVE-2026-109618 и CVE-2026-109619 от 21.10.2026?» — это нормальный вопрос, поддержка отвечает на него каждый день.

Теперь сравните версию с таблицей:

Откуда: объявления php.net от 21.10.2026 (исправленные версии, бэкпорты для 7.4–8.1), php.net/supported-versions (поддержка 8.2 — до 31.12.2026), watchTowr (ветки 7.3 и старше).

Насколько это массовая проблема, видно по статистике версий. Почти половина сайтов на PHP работает на ветках, которые разработчики уже не поддерживают, — им одного «обновления» мало, нужен переход.

Как обновить PHP: на хостинге и на своём сервере

На виртуальном хостинге версию PHP переключают в той же панели, где её смотрели (таблица выше): выбираете ветку 8.3 или 8.4 вместо старой и сохраняете. Переключение применяется сразу или в течение нескольких минут. Точный номер внутри ветки (например, 8.3.36) обновляет сам хостинг — если сомневаетесь, что исправления установлены, спросите поддержку.

На своём сервере (VPS) обновляют пакеты PHP из репозитория дистрибутива или стороннего, из которого PHP был установлен, — и обязательно перезапускают PHP-FPM или Apache: без перезапуска продолжает работать старая версия. Если сервер настраивал программист, которого уже нет, — это задача для подрядчика: на «чужом» сервере легко обновить не тот PHP.

Перед переключением ветки (например, с 7.4 на 8.3) сделайте копию сайта: старые темы, плагины и самописный код на новой версии PHP могут выдавать ошибки. После — пройдите сайт как клиент: формы заявок, корзина, оплата, личный кабинет, обмен с 1С. Сломалось — верните прежнюю ветку в панели и решайте вопрос с подрядчиком, но не оставляйте уязвимую версию надолго.

Самопроверка: есть ли признаки взлома

Отметьте, что знаете про свой сайт, — получите оценку и что делать первым. Ничего не отправляется, пока вы сами не нажмёте кнопку.

Признаки, что сайт уже взломали

Хорошие новости — у большинства взломов есть заметные симптомы. Плохие — их часто замечают не владельцы, а клиенты и поиск: вредоносный код любит показываться только «чужим» — посетителям с телефонов или из поисковой выдачи.

Типичная картина заражения: чужой код в шаблоне, перенаправления и спам-страницы, которые видит поиск, а не владелец.

Как выглядят заражения в цифрах, видно по отчёту Sucuri: в 2024 году их сканер проверил 70,8 млн сайтов и нашёл 1 176 701 заражённый — 1,66 %. Один сайт может попасть сразу в несколько категорий, поэтому сумма больше 100 %.

Что проверить в первую очередь:

1. Яндекс Вебмастер → «Безопасность и нарушения». Если поиск нашёл на сайте вредоносный код, он пишет об этом здесь, а в выдаче рядом с сайтом появляется предупреждение. В Google то же — в Search Console, раздел «Проблемы безопасности».
2. Поиск по своему сайту в Яндексе: запрос site:вашсайт.ru и посмотрите, нет ли страниц, которых вы не создавали — особенно на английском, про казино, аптеки и займы.
3. Откройте сайт с телефона через мобильный интернет и перейдите на него из поиска — редиректы часто срабатывают только так.
4. Список администраторов в CMS — нет ли незнакомых.
5. Письма от хостинга — о вирусах, спаме, превышении нагрузки.
6. Свежие изменения файлов в панели хостинга — если вы ничего не меняли, а файлы шаблона или ядра «помолодели», это тревожный знак.

Откуда: справки Яндекс Вебмастера и Google Search Console о проблемах безопасности; опыт студии.

Что делать по шагам

Порядок действий зависит от того, что показала самопроверка.

Восстановление — это не «удалить вирус», а цепочка: копия, очистка, закрытие входа, обновление, проверка.

Если признаков взлома нет

1. Узнайте точную версию PHP (см. выше).
2. Обновите PHP до версии с исправлениями — на хостинге в панели или через поддержку, на VPS — сами или с подрядчиком. На старых ветках 7.4–8.1 — переход на 8.3/8.4.
3. Включите временную меру, которую советует PHP: session.upload_progress.enabled=0 в php.ini или в настройках пула PHP-FPM и перезапуск всех процессов PHP. PHP просит держать её и после обновления — из-за третьей уязвимости CVE-2026-115560. Побочный эффект — перестанет работать индикатор прогресса загрузки файлов, если сайт его использует.
4. Проверьте сайт после обновления: формы заявок, корзину, оплату, обмен с 1С, личный кабинет. Старые сайты на новой версии PHP иногда ломаются.
5. Сделайте резервную копию, которая хранится отдельно от сайта, и поставьте регулярные обновления CMS и плагинов.

Если признаки взлома есть

1. Не удаляйте файлы и не откатывайте сайт из копии сами. Следы нужны, чтобы найти вход, а копия может быть уже заражённой.
2. Смените пароли от хостинга, почты, админки сайта, базы данных и FTP — с чистого устройства.
3. Сохраните доказательства: скриншоты предупреждений и писем хостинга с датами.
4. Найдите причину: старый PHP, уязвимый плагин, утёкший пароль, форма загрузки файлов. Без этого заражение вернётся.
5. Очистите сайт: вредоносный код в файлах и базе, задания по расписанию, чужих администраторов, спам-страницы.
6. Обновите PHP, CMS и плагины и проверьте работу сайта.
7. Запросите перепроверку в Яндекс Вебмастере и Google Search Console — только после полной очистки. У Яндекса проверка идёт до 30 дней, и если пометку не сняли, повторно отправить сайт на проверку можно лишь через 30 дней (справка Вебмастера). У Google — от нескольких дней до нескольких недель (справка Search Console). Поэтому недочищенный сайт на проверку отправлять нельзя: потеряете месяц.

Почему «обновить и забыть» мало

Обновление PHP закрывает PHP2Shell — и только его. Вот что остаётся за кадром у тех, кто нажал «обновить» и выдохнул:

• Третья уязвимость. 23 октября PHP сообщил о CVE-2026-115560 — она срабатывает только при нестандартной настройке, и разработчики называют её маловероятным путём атаки, но исправление выйдет лишь со следующим релизом. Отсюда совет держать временную меру и после обновления.
• Обновление не лечит. Если до обновления на сайт успели загрузить вредоносный код, он остаётся на месте и работает дальше.
• Временные меры ≠ защита. Разработчики PHP прямо пишут, что временные меры «не делают установку безопасной» — это мостик до обновления, а не замена ему.
• Ветка тоже стареет. PHP 8.2 перестанет получать исправления 31.12.2026 — следующая уязвимость для неё уже не будет закрыта. Сайт на 8.2 сегодня — это задача на переход в ближайшие месяцы.
• В обычные дни сайты ломают не через PHP. Чаще — через устаревшие плагины, темы и слабые пароли. Только в экосистеме WordPress за 2025 год нашли 11 334 уязвимости, 91 % из них — в плагинах, 46 % не были исправлены к моменту публикации, а массово эксплуатируемые уязвимости начинали атаковать в среднем через 5 часов после раскрытия (Patchstack). PHP2Shell — хороший повод навести порядок во всём сразу.

Правильная модель — не разовая уборка, а регулярное обслуживание: обновления по графику, резервные копии отдельно от сайта, наблюдение за Вебмастером и человек, который отвечает за это по имени.

Как мы закрыли PHP2Shell у себя

21 октября вечером, в день выхода исправлений, мы проверили свои серверы. На это ушло около 15 минут:

1. Нашли, где работает PHP. Большая часть наших сайтов — статические страницы и сервисы на Python и Node.js, PHP на них нет. На сервере, где PHP был установлен, единственным его «потребителем» оказался старый неиспользуемый сайт.
2. Включили временную меру из бюллетеня PHP — session.upload_progress.enabled=0.
3. Отключили PHP совсем там, где он не нужен. Пакет с исправлением для нашей версии Debian к тому моменту ещё не вышел, а лучший способ закрыть уязвимость в программе, которой не пользуешься, — выключить программу.
4. Проверили, что все сайты работают после изменений.

Сколько стоит восстановить сайт после взлома

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

Сравнивая предложения, спрашивайте одно: ищут ли причину взлома и закрывают ли её — или только удаляют найденные файлы. Без первого вторую услугу часто покупают повторно. В Хайвее диагностика бесплатная, а смету вы видите до начала работ.

Откуда: прайс студии Хайвей на hwstudio.ru (страница восстановления сайта и ИИ-ведение), 24.10.2026.

Итог: что сделать сегодня

1. Узнайте точную версию PHP своего сайта — в панели хостинга или у поддержки.
2. Если она ниже 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 — обновите; если это 7.4–8.1 или старше — планируйте переход на 8.3/8.4.
3. Пройдите самопроверку и загляните в Яндекс Вебмастер, раздел «Безопасность и нарушения».
4. Если видите признаки взлома — не удаляйте ничего сами, смените пароли и напишите нам: бесплатно посмотрим и скажем, что делать.

PHP2Shell на 24 октября — серьёзная, но не катастрофическая история: время спокойно обновиться ещё есть. Лучше потратить на это полчаса сегодня, чем неделю на восстановление сайта потом.