ИИ нашёл в PHP самую серьёзную уязвимость за десять лет. Если сайт «просто работает» на WordPress или Битриксе, вот что сделать за вечер

Меня зовут Карим, я занимаюсь автоматизацией и сайтами в NODA, и на этой неделе у подсайта одна тема: две критические уязвимости в PHP, языке, на котором работает около 70% сайтов мира, включая почти все на WordPress и Битриксе. Патчи вышли 21 октября, правительства нескольких стран на день отключали свои сайты, а попытки атак зафиксированы ещё до публичного раскрытия. Новость прочитали 38 тысяч человек; разбираю, что в ней делать владельцу сайта, у которого нет своего админа, по шагам, за один вечер.

Короткий ответ: узнать версию PHP на своём хостинге и обновить до 8.2.35, 8.3.36, 8.4.27 или 8.5.12 — смотря какая ветка. Если версия старше 8.2, обновить ветку целиком. Если обновить сегодня нельзя — включить защиту на уровне хостинга или Cloudflare и держать сайт выключенным ровно столько, сколько нужно на обновление. Всё остальное ниже — как это сделать, если слово «ветка» вы видите впервые.

Две уязвимости, которым дали общее имя PHP2Shell, позволяют выполнить чужой код на сервере без входа в админку: украсть данные, подменить страницы, атаковать посетителей. Их нашли в августе две исследовательские компании с помощью ИИ-моделей, PHP выпустила исправления 21 октября — на день раньше плана, потому что описание утекло в сеть 20-го. Инженер фонда, который поддерживает PHP, назвал это самой серьёзной уязвимостью за десять лет. Cloudflare фиксировала атаки с утра 21-го, Amazon — попытку ещё 17-го, за четыре дня до раскрытия.

Если сайт делали вам, ответ лежит в панели хостинга: раздел «PHP», «Версия PHP» или «Настройки сайта». На виртуальном хостинге версия выбирается из списка, и часто там стоит то, что поставили в день запуска три года назад. Если панели нет или вы не знаете, где она, — письмо подрядчику с одним вопросом: «Какая версия PHP на нашем сайте и обновлена ли она после 21 октября». Ответ «у нас всё обновляется автоматически» не считается: нужна цифра.

Исправлены версии 8.2.35, 8.3.36, 8.4.27 и 8.5.12. У вас 8.3.30: обновить до 8.3.36. У вас 8.1 или 7.4: эти ветки официально не поддерживаются; для них опубликованы минимальные исправления в исходном коде, но обычный хостинг их не соберёт, поэтому правильный ответ: переход на 8.2 и выше. Для WordPress и Битрикса это обычно проходит без проблем на актуальных версиях CMS и ломается на старых плагинах; поэтому шаг 3.

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

Переключить версию в панели (или попросить подрядчика), открыть главную, каталог, корзину или форму заявки, личный кабинет и админку. Если что-то упало: откат к копии и письмо подрядчику с названием сломавшегося плагина. На этом месте обычно выясняется, что плагин не обновлялся с 2022 года; это отдельный разговор, но не сегодня.

Два варианта, оба временные. Первый: защита на уровне сети. Cloudflare выкатила правила против известных векторов для всех тарифов, включая бесплатный; у крупных российских хостингов и защитных сервисов аналогичные правила включены или включаются по запросу — спросите у своего. Второй: то, что сделали правительства Финляндии и Нидерландов и несколько европейских университетов, выключить сайт на время обновления. Для интернет-магазина это звучит страшно, но день без продаж дешевле недели с подменёнными страницами.

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

Здесь ИИ-часть, и она не про сегодняшний патч. Эти две уязвимости нашли модели; Wiz прямо пишет, что современные модели снизили порог входа для тех, кто их использует. Атаки начались до раскрытия, защита появилась утром в день патча. Окно между «найдено» и «используется» теперь измеряется днями, и так будет с каждой следующей дырой. Для бизнеса с сайтом это значит одно: обновление в день выхода патча становится регламентом, как оплата хостинга, и перестаёт быть задачей на «когда будет время». Если своего админа нет, это строка в договоре с подрядчиком: «критические обновления платформы — в течение 24 часов, с уведомлением». В нашей статье про план Б для ИИ-продукта было три зависимости — хостинг, данные, модель; сайт на PHP и есть первая зависимость, и у неё теперь есть срок реакции.

Первое. Я делаю и сопровождаю сайты, и мне выгодно, чтобы «регламент обновлений» выглядел обязательной услугой. Всё, что выше, выполняется без подрядчика, если есть доступ к панели.

Второе. Версии и сроки взяты из публикаций от 21–22 октября; если ваш хостинг обновил PHP сам, до того как вы прочитали это, шаги 1–2 займут минуту на проверку.

Третье. Для некоторых продуктов, которые используют PHP внутри (сетевое оборудование, панели управления), патчей на момент написания не было. Это не про сайты малого бизнеса, но если у вас такой продукт есть, вопрос вендору.

Вопрос к тем, у кого сайт на сопровождении: подрядчик написал вам первым или вы узнали из новостей? Это, по-моему, единственный тест сопровождения, который имеет значение.