Две критические дыры в PHP: кого касается и что делать

Разбор · 2026-10-21 · 7 мин чтения

21 октября 2026 года разработчики PHP выпустили внеплановые версии 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Внеплановые – значит, ждать обычного расписания не стали: закрыты две критические уязвимости, каждая из которых позволяет выполнить чужой код на сервере без пароля и без участия человека. Обе получили 9,2 балла из 10 по шкале CVSS.

Если коротко: это касается почти любого сайта. PHP крутится под Битриксом, WordPress, Drupal, OpenCart, самописными панелями и половиной корпоративных сайтов в стране. Обновление – единственное полное решение, так прямо и написано в уведомлении самого PHP.

Что именно нашли

CVE-2026-109618 – порча памяти при нехватке памяти. Когда PHP упирается в лимит памяти, он прерывает запрос особым способом. Оказалось, что в некоторых местах память запроса доступна раньше, чем она полностью готова, и сбой выделения именно в этот момент приводит к тому, что завершение запроса работает с мусором вместо данных. Дальше всё зависит от того, что именно окажется в этом мусоре – при удачной для атакующего раскладке получается выполнение его кода.

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

CVE-2026-109619 – остатки прошлого запроса. Рабочий процесс PHP обслуживает запросы один за другим и хранит между ними служебное состояние: ошибки, сессии, данные расширений. Если запрос оборвался на полпути – упёрся в память, превысил время выполнения, – часть этого состояния остаётся указывать на память, которая уже освобождена. Следующий запрос в тот же процесс может на эти остатки наткнуться.

Здесь подтверждённых путей несколько: в PHP 8.5 – трассировка фатальных ошибок (на ней и показали выполнение кода), отслеживание прогресса загрузки файлов в сессии (проверено и на модуле Apache, и на PHP-FPM), а также разбор настроек из файла .htaccess до инициализации запроса.

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

Здесь важно не поддаться ни панике, ни обратной крайности.

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

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

Разумная позиция: это не пожар, из-за которого надо поднимать людей ночью, но и не то, что откладывают до следующего квартала. Неделя – приемлемый срок. Месяц – уже нет.

Что делать

Шаг 1. Узнайте свою версию. На своём сервере – командой php -v. На хостинге – в панели управления, раздел с настройками PHP. Если доступа нет, спросите у того, кто ведёт сайт.

Шаг 2. Сравните с безопасными.

Ветка PHP	Уязвимы	Обновиться до
8.5	до 8.5.12	8.5.12
8.4	до 8.4.27	8.4.27
8.3	до 8.3.36	8.3.36
8.2	до 8.2.35	8.2.35
8.1 и старше	да	поддержка закончилась, исправлений не будет

Шаг 3. Обновитесь. На общем хостинге это обычно переключение версии в панели или письмо в поддержку – у крупных хостеров обновление приезжает само в течение нескольких дней, но проверить стоит. На своём сервере – обновление пакетов средствами системы.

Шаг 4. Перезапустите рабочие процессы. Это тот шаг, который забывают. Пока старые процессы живы, в памяти остаётся прежний код, и уязвимость никуда не делась. Перезапустите PHP-FPM или веб-сервер целиком и убедитесь, что php -v и страница состояния показывают новую версию.

Если обновиться прямо сейчас нельзя

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

На PHP 8.5 – отключить трассировку фатальных ошибок (fatal_error_backtraces=0). Это убирает подтверждённый путь атаки, но не остальные.
Отключить отслеживание прогресса загрузки файлов (session.upload_progress.enabled=0), если оно вам не нужно. Его стоит держать выключенным и после обновления.
Ограничить на уровне веб-сервера или защитного экрана размер тела запроса и количество частей в формах с файлами. Если приложение вообще не принимает файлы – закрыть такие запросы на подходе.
Не использовать ограничение памяти процесса через RLIMIT_AS и RLIMIT_DATA: именно они приводят к той самой ошибке выделения памяти, с которой всё начинается.

И главное – поставьте себе срок на настоящее обновление, а не считайте временные меры решением.

Отдельно про PHP 8.2 и всё, что старше

PHP 8.2 обновление получил, но его поддержка заканчивается 31 декабря 2026 года. Это значит, что следующая такая история – уже без заплатки. Если сайт живёт на 8.2, ближайшие два месяца – хороший повод спланировать переход на 8.3 или 8.4, пока это плановая работа, а не аварийная.

Если версия 8.1 или ниже – исправлений нет уже сейчас. Такой сайт уязвим и останется уязвимым; единственный выход – переезд на поддерживаемую ветку.

Частые вопросы

Я обновил Битрикс (или WordPress) – этого достаточно?

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

У меня общий хостинг, я ничего не настраиваю. Что делать?

Проверьте в панели, какая версия PHP выбрана для сайта, и переключитесь на свежую, если она уже доступна. Если нужной версии в списке нет – напишите в поддержку хостинга и спросите, когда поставят обновление с исправлением CVE-2026-109618 и CVE-2026-109619. Внятный хостер ответит сроком, а не отпиской.

Поможет ли защитный экран перед сайтом?

Частично. Ограничение размера запросов и фильтрация форм с файлами усложняют атаку, но оба сценария опираются на внутреннее поведение PHP, а не на какую-то подозрительную строку в запросе, которую можно узнать по шаблону. Полагаться на экран вместо обновления не стоит.

Как понять, что сайт уже взломали?

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

Коротко

21 октября закрыты две критические уязвимости PHP: обе дают выполнение чужого кода на сервере без пароля.
Безопасные версии: 8.5.12, 8.4.27, 8.3.36, 8.2.35.
Эксплуатация сложная, подтверждена для Apache с модулем PHP; для PHP-FPM показана достижимость уязвимого кода.
Обновление – единственное полное решение; временные настройки только сужают щель.
После обновления обязательно перезапустите рабочие процессы и проверьте версию.
PHP 8.2 живёт до 31 декабря 2026 года, 8.1 и старше не получают исправлений вовсе.

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