ИИ нашёл дыры в PHP: инструкция для не специалиста и владельцам сайтов

Если техническая часть не для вас, от вас требуется одно: перешлите эту статью тем, кто отвечает за ваши сайты, и спросите письмом: «Какая версия PHP на сайте и обновлена ли она после 21 октября?» Переслать можно подрядчику или агентству, администратору сайта, интегратору (на 1С-Битриксе это обычно он) или в поддержку хостинга.

22 октября НКЦКИ, центр кибербезопасности при ФСБ, разослал через ГосСОПКА директиву объектам критической инфраструктуры: обновить PHP, проверить серверы антивирусом и изучить журналы на следы взлома. А если обновить быстро нельзя, то дословно «рассмотреть временное ограничение внешнего доступа к уязвимым веб-серверам вплоть до их отключения».

Директива касается госорганов, банков, энергетики и больниц. Проблема касается всех. Дыры сидят в самом PHP, на нём работает 90,8% сайтов с русскоязычным контентом (данные W3Techs), и Cloudflare уже зафиксировал миллионы попыток эксплуатации. Статья для двоих: для тех, кто помогает бизнесу с сайтами, и для владельцев собственных сайтов. Дальше идёт техническая часть. Если она не для вас, вы уже знаете, что делать.

PHP это язык, на котором сервер собирает страницы сайта. 21 октября его разработчики выпустили экстренные версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35, закрывающие две дыры с оценкой опасности 9,2 из 10.

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

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

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

Нашли дыры исследователи и ИИ-инструменты. Первый внешний аудит PHP прошёл в 2024 году, а летом 2026-го к нему добавился аудит фирмы Calif: 11 августа её исследователь описал удалённое выполнение кода, независимо тот же корень нашли OpenAI и Wiz, сканировали и проверяли отчёты ИИ-модели. За два дня до релиза номера уязвимостей утекли в сеть, а дистрибьютор Chainguard выпустил образы с патчем за шесть часов до срока, дав атакующим время изучить исправление в бинарном виде. Отсюда миллионы попыток эксплуатации, которые зафиксировал Cloudflare.

На PHP в России стоит почти весь привычный стек: 1С-Битрикс, WordPress, Joomla, Drupal, OpenCart, MODX, HostCMS, Umi.CMS, NetCat, DIAFAN, InstantCMS и самописы всех поколений. Но дыра общая для всех, поэтому перечислить CMS мало. Важнее понять, в какой вы ситуации. Пять типовых сценариев.

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

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

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

Чего не бояться: с сайтом ничего не случится от обновления в пределах одной ветки. Это тихая операция на стороне сервера.

Это вы, если арендуется VPS, а у администратора есть панель типа ISPmanager, FastPanel, HestiaCP или cPanel.

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

Что спросить у администратора: «Сайты обновили. А внутренний PHP панели?» Если ответ «панель не трогали», это не конец света, но строка в плане работ.

Это вы, если сайту больше пяти лет, это OpenCart 1.5–3.x, старый WordPress, Битрикс древней сборки или самопис, который «всё работает, не трогайте».

Что происходит: официальных патчей для веток ниже 8.2 нет и не будет. Обновить «в лоб» тоже нельзя: старый сайт написан под старый PHP и на новом просто упадёт. Магазины на старых OpenCart разработчики называют главной головной болью рунета именно в этой истории.

Два пути. Первый, временная защита: администратор меняет настройки сервера так, чтобы сломать саму цепочку атаки. Это работа на день, но это костыль, а не лечение. Второй, настоящий: переезд сайта на новую версию PHP. Олег Рогов из AIRI оценивает переезд в недели, для Битрикса и самописов это проект с тестированием, а не апдейт.

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

Это вы, если сайт собран на Tilda, Wix, uKit или Nethouse, а магазин живёт на InSales или Ecwid.

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

Что делать: со своей стороны нечего. Для критичного бизнеса два спокойных действия: посмотреть статус-страницу платформы на предмет инцидентов и задать поддержке тот же вопрос про PHP.

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

Паркованный домен, лендинг 2012 года, старый каталог, «висит, пусть висит». На нём PHP 5.6, его никто не обновит, потому что им никто не занимается.

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

Решение владельца простое и дешёвое: закрыть. Одна кнопка у хостера дешевле, чем разбирательство после взлома.

Шаг 1. Инвентаризация. Таблица по всем сайтам: домен, хостинг, ветка PHP, CMS, у кого доступ. Владельцу одного сайта хватит одной строки, но строка должна быть.

Шаг 2. Письмо хостеру (для сценариев 1 и 4):

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

Шаг 3. VPS и свой сервер (сценарии 2 и 3). Обновить PHP и совместимые модули, не только ядро: так рекомендует Лаборатория Касперского. Проверить внутренний PHP панели управления. На свежих ветках обновление занимает минуты, проверка сервера и журналов растянется до двух недель.

Шаг 4. Проверка на следы взлома. Прогнать сервер антивирусом и посмотреть журналы, как предписывает НКЦКИ. Искать незнакомые задачи в расписании, новые PHP-файлы в неожиданных папках, странные исходящие соединения.

Шаг 5. Если сайт успели взломать. Дыра позволяет читать память сервера, а там ключи и пароли. Перевыпустить SSL-сертификат и сменить все пароли и ключи: базы, FTP, админки, интеграции.

Шаг 6. Если обновить нельзя. Наследие ниже 8.2: временная защита, переезд или, для забытых сайтов, отключение по формулировке НКЦКИ.

Если строка вашей роли пустая, значит, её уже заполняет за вас кто-то другой. Не факт, что в вашу пользу.

Если в договоре с бизнесом не прописано, кто отвечает за инфраструктуру, обновления и безопасность, эта неделя рано или поздно закончится спором о том, кто платит за взлом. Дешевле прописать это сейчас, на спокойной голове.

Дыры нашла команда исследователей ИИ-инструментов за недели, а не команда ИБ. Инструменты теперь ищут баги быстрее у обеих сторон, и патчи будут выходить внезапнее. Обновлением инфраструктуры теперь нужно заниматься постоянно, и у этой работы должен быть владелец.