Критические уязвимости PHP: почему в этот раз всё серьёзно и что делать

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

Ниже — что случилось, чем это грозит компании и как закрыть проблему по шагам. Ссылки на первоисточники — в конце статьи.

PHP — язык, на котором работает большая часть сайтов в интернете: интернет-магазины на 1С-Битрикс и WordPress, порталы, системы дистанционного обучения, CRM, форумы, панели управления хостингом. Когда посетитель открывает страницу или отправляет форму, на сервере запускается интерпретатор PHP и выполняет код сайта.

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

Исправления вошли в версии 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Всё, что ниже этих номеров, уязвимо.

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

• Ошибка в самом языке, а не в конкретной CMS. Неважно, на чём сделан сайт — на 1С-Битрикс, WordPress, Joomla или написан программистом с нуля. Если под ним работает уязвимая версия PHP, риск есть.
• Не нужен ни логин, ни доступ в панель администратора. Достаточно, чтобы сайт принимал запросы из интернета, то есть работал.
• Атака срабатывает раньше, чем запускается код сайта. Основной путь — разбор данных формы, который интерпретатор выполняет сам. Плагины безопасности и защита внутри CMS не помогают: до них дело не доходит.
• Подробности утекли раньше, чем вышло исправление. Описание ошибок появилось в открытом доступе 20 октября, за день до релиза. По данным компаний, которые следят за угрозами, массовое сканирование сайтов и первые попытки взлома начались в течение нескольких часов.
• Многие серверы работают на старых ветках. Ошибки есть в версиях от 5.4 до 8.5. Официальные исправления вышли только для 8.2–8.5, а ветка 8.1 и всё, что старше, поддержку уже не получает. По оценке исследователей, на таких устаревших версиях работает около двух третей PHP-серверов, видимых из интернета.

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

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

• подмена страниц или скрытое встраивание вредоносного кода, заражающего компьютеры посетителей;
• перехват заявок, заказов и контактов клиентов из форм;
• кража паролей к базе данных, ключей обмена с 1С, платёжных и почтовых сервисов, которые хранятся в настройках сайта;
• рассылка спама с вашего домена — после этого письма компании начинают попадать в спам у партнёров, а поисковики помечают сайт как опасный;
• использование сервера как точки входа во внутреннюю сеть, если он с ней связан;
• утечка персональных данных клиентов, а вместе с ней — обязанность уведомить Роскомнадзор и риск штрафа.

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

Первый шаг — понять, что проверять. Кроме основного сайта, интерпретатор нередко работает там, о чём руководитель не помнит:

• сайт и интернет-магазин, лендинги рекламных кампаний, старые версии сайта на поддоменах;
• система дистанционного обучения (например, Moodle), корпоративный портал, база знаний, wiki;
• коробочные CRM и системы заявок, установленные на своём сервере;
• панели управления хостингом и базами данных (например, phpMyAdmin);
• веб-интерфейсы оборудования и программ, которые настраивал подрядчик несколько лет назад.

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

Этот порядок можно передать системному администратору или подрядчику и использовать как чек-лист для контроля.

1. Составить список всех систем на PHP и для каждой узнать точную версию интерпретатора (команда php -v на сервере или страница phpinfo()). Начинать с того, что открыто в интернет.
2. Сверить версии с исправленными: 8.2.35, 8.3.36, 8.4.27, 8.5.12. Если PHP установлен из пакетов дистрибутива Linux, номер версии часто остаётся старым, а заплатка уже внутри — это видно по бюллетеню безопасности дистрибутива.
3. Перед обновлением сохранить копию базы и файлов сайта. Заброшенную систему проще выключить, чем обновлять.
4. Обновить PHP и перезапустить все его процессы — PHP-FPM, Apache и другие. Без перезапуска в памяти продолжает работать старый уязвимый код, хотя новая версия формально установлена.
5. Проверить, что всё работает: версия на странице phpinfo() новая, формы отправляются, оплата проходит, обмен с 1С и личный кабинет работают.
6. Поискать следы взлома за период с 20 октября: новые или изменённые файлы в каталоге сайта, незнакомые задания планировщика (cron), новые учётные записи администраторов, подозрительные процессы, запущенные от имени веб-сервера.
7. Если признаки взлома есть — отключить сервер от интернета, сохранить журналы для разбора, затем сменить все пароли и ключи, которые на нём хранились: от базы данных, почты, обмена с 1С, платёжных сервисов.
8. Если сайт на виртуальном хостинге — выбрать в панели управления актуальную версию PHP и уточнить у поддержки хостинга, установлены ли исправления. На старых ветках (8.1 и ниже) исправлений не будет — нужен переход на поддерживаемую версию.

Так бывает, если сайт работает на старой CMS, которая не запускается на новых версиях PHP. Разработчики PHP описали временные меры: ограничить размер запросов (post_max_size, memory_limit), отключить session.upload_progress, отсекать загрузку форм на уровне веб-сервера там, где она не нужна. Но в официальном уведомлении сказано: единственная полная защита — обновление.

Временные меры имеют смысл только вместе с ограничением доступа к сайту (VPN, белый список адресов, межсетевой экран для веб-приложений) и с планом перехода на поддерживаемую версию в ближайшие дни, а не месяцы.

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

• Какие наши системы работают на PHP и какая версия стоит на каждой после обновления?
• Перезапущены ли процессы PHP после обновления?
• Проверяли ли сервер на следы взлома с 20 октября, и что нашли?
• Есть ли у нас системы на ветках 8.1 и ниже, и какой план их перевода?

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

Многие наши клиенты работают в 1С и при этом держат сайт или интернет-магазин с обменом данными с учётной системой. Если не уверены, что у вас всё в порядке, — напишите, специалист подскажет, что проверить в первую очередь.

• Уведомление команды PHP: RCE via OOM corruption (CVE-2026-109618)
• Уведомление команды PHP: RCE via stale global state (CVE-2026-109619)
• Сроки поддержки версий PHP (endoflife.date)
• Разбор атак и признаков взлома (Huntress)