Защита сайта от взлома: что делать после PHP2Shell

Коротко: 21 октября 2026 года вышли исправления для двух опасных ошибок в самом PHP, языке, на котором работает большинство сайтов. Через них посторонний человек без пароля может запускать свои команды на машине, где живет сайт. Обновление WordPress или Битрикса тут не поможет: нужно обновление PHP до актуальной версии. Защита сайта от взлома на сегодня начинается с трех шагов: узнать версию PHP, поставить задачу хостингу или подрядчику и проверить, нет ли следов вторжения.

PHP2Shell — так назвали две ошибки в ядре PHP. Каждая получила 9,2 балла из 10 по международной шкале опасности: это почти потолок. Простыми словами, ошибка в программе, которой можно воспользоваться, называется уязвимостью. А программу, которая этим пользуется, хакеры называют эксплойтом.

PHP работает примерно на семидесяти процентах сайтов мира. Эту цифру приводит компания Wiz, это ее оценка. На PHP написаны WordPress, Joomla, Drupal и многие интернет-магазины. Представьте, что PHP — это входная дверь здания, а ваш сайт — офис внутри. Можно поставить в офисе хороший замок, но если дверь в здание не запирается, это не поможет. Поэтому уязвимость PHP опасна даже для сайта с аккуратным собственным кодом, и защищать нужно именно PHP.

Исправления вышли 21 октября для веток PHP 8.2–8.5. Число машин, которые теоретически могут быть уязвимы, исчисляется миллионами (оценка Palo Alto Networks). Но это не число взломанных сайтов, а размер возможной мишени.

События развивались так. За четыре дня до выхода исправлений ловушка Amazon увидела первую попытку атаки. Накануне релиза утекли технические детали. 21 октября исправления вышли, а Cloudflare включила защиту для всех клиентов, в том числе бесплатных. На следующий день похожее правило выпустила AWS. Еще через день проект PHP раскрыл третью связанную ошибку, но, как пишет CERT-EU, она касается только необычно настроенных приложений.

Правда ли, что ИИ сделал взломы быстрее, или это громкая фраза? В этой истории правда, в части скорости. Ошибка в PHP старая: на нее обращали внимание еще в 2024 году, но сочли теоретической, потому что никто не смог доказать, что через нее реально проникнуть внутрь. Изменилось другое. По данным Wiz и IBM, исследователи за неделю использовали три ИИ-инструмента, в том числе собственного агента Wiz, чтобы найти ошибки, связать их в цепочку и довести эксплойт до рабочего состояния. Раньше на это у команды мирового уровня уходили месяцы.

Общий тренд подтверждает Positive Technologies: агентный ИИ сократил время от раскрытия уязвимости до появления рабочего эксплойта до нескольких часов. Злоумышленники разбирают выпущенные исправления и по ним понимают, где именно была ошибка.

Атаки не ждали исправлений. Cloudflare говорит о миллионах попыток, а в первые часы атакующие на ходу меняли свои инструменты, чтобы обойти защиту. Это попытки, а не подтвержденные взломы.

Выдумывать сенсации при этом не стоит. Amazon сам пишет, что неясно, сработали бы ранние попытки на реальных серверах. Dataminr видел в основном сканирование и нерабочие эксплойты и не нашел подтвержденных взломов. Рассказы про «массово взломанные сайты» пока не подтверждены. Попыток много, а сколько из них удачные, публично не знает никто.

Еще одна оговорка. Исследователи Palo Alto Networks (Unit 42) сначала связали взлом одного европейского госоргана с PHP2Shell, а потом отозвали этот вывод. Позже этот вывод отозвали, так что считать его доказанным нельзя.

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

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

Теперь о том, как узнать, под угрозой ли вы. Безопасны версии PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12, а также любые более новые в своей ветке. Ветки 8.1 и старше обычных обновлений не получают. Переезд на 8.2 и новее остается правильным выбором.

Версию обычно знает не владелец бизнеса, а ИТ-отдел, подрядчик или хостинг. Если у вас обычный хостинг, где провайдер сам управляет сервером, откройте панель, найдите раздел с настройками PHP и посмотрите версию для каждого сайта. Если там 8.2 или новее, исправление обычно ставит сам провайдер, но стоит спросить, поставил ли он его. Если там 8.1 или старше, сайт нужно переводить на новую версию, лучше на 8.4, сначала на копии: старые темы и плагины могут сломаться. Если у вас своя машина или VPS (арендованный сервер, которым вы управляете сами), все это делает тот, кто ее настраивал, а вам достаточно задать ему вопросы из списка ниже.

Обновлять и чистить сервер вам самому не нужно. Нужно написать одно сообщение и получить на него письменный ответ. Вот вопросы, которые стоит задать:

Про последний вопрос. Если сразу сменить версию невозможно, проект PHP предлагает временные настройки, которые снижают риск. Конкретные значения подрядчик возьмет со страницы новостей проекта PHP. Полную защиту даст только новая версия. Еще один временный вариант: поставить перед сайтом WAF. Это сторожевой фильтр для сайтов: он отсеивает вредоносные запросы до того, как они дойдут до сайта. Правила под PHP2Shell уже выпустили Cloudflare и AWS, и это выигрывает время.

Поставили новый PHP, значит, взлом закрыт? Нет. Исправление закрывает дверь, но не выгоняет того, кто уже зашел. Злоумышленники часто оставляют веб-шелл: небольшую программу-лазейку, через которую можно вернуться позже, даже после обновления. Поэтому смотреть журналы посещений нужно не с даты исправления, а с того дня, когда атаки начались, то есть минимум за четыре дня до релиза.

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

Сам разбор журналов и файлов — работа хостинга или разработчика. Вы ставите задачу: «Проверьте журналы за период с 17 октября и найдите в папках сайта файлы, которых там быть не должно. Есть ли на сервере незнакомые задачи и пользователи?»

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

Отдельно про закон. Если сайт собирает имена, телефоны, email или адреса, ваша компания — оператор персональных данных по закону 152-ФЗ. Сама по себе уязвимость повода уведомлять Роскомнадзор не дает: обязанность появляется, когда утечка установлена. Тогда, как пишут юристы, уведомление подают в течение суток, а итоги внутреннего расследования в течение трех суток. С деталями лучше обратиться к юристу.

PHP — не единственное слабое место. Дыры в CMS, плагинах и библиотеках остаются одним из частых путей атаки: по оценке Positive Technologies, 2 из 5 инцидентов в мире в 2025 году были совершены через эксплуатацию уязвимостей.

Если вы спрашиваете, как защитить сайт на WordPress, список короткий. Обновляйте ядро, темы и плагины, удаляйте те, которыми не пользуетесь, и не оставляйте на сервере старые копии сайта. После обновления PHP закажите подрядчику еще три вещи. Первая: двухфакторный вход в админку и на хостинг и минимальные права для подрядчиков. Вторая: резервные копии вне хостинга, причем хотя бы раз проверьте, что из копии сайт действительно разворачивается. Копия, которую ни разу не открывали, может оказаться пустой. Третья: наблюдение за сайтом, чтобы о проблеме вы узнали от уведомления, а не от клиента.

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