Уязвимость PHP 21 октября: сайт можно захватить без пароля

Двадцатого октября 2026 года команда безопасности PHP опубликовала то, что публикует редко: предупреждение о выпуске за сутки до него. Подробностей в нём не было. Только время, 14:00 по UTC, то есть 17:00 по Москве, и оценка: две критические уязвимости, обе на 9,2 балла по шкале CVSS 4.0. И оговорка, что выпуск выйдет раньше, если подробности утекут или кто-то начнёт уязвимости использовать.

Двадцать первого октября вышли PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, а с ними объявление, в заголовке которого стоит "update now", обновляйтесь сейчас. Ниже разбор для владельца сайта, у которого нет своего системного администратора: касается ли это вас, как проверить за пять минут и что сделать сегодня.

Короткий ответ

• Что случилось. В PHP нашли две уязвимости, через которые посторонний может выполнить свой код на сервере сайта без логина и пароля. Исправлены 21 октября 2026 года.
• Кого касается. Любого сайта на PHP, который сам отвечает на запросы из интернета: Битрикс, WordPress, самописные сайты. Сильнее всего рискуют сайты, где PHP работает модулем Apache: для них рабочая атака уже показана.
• Какая версия нужна. 8.5.12, 8.4.27, 8.3.36 или 8.2.35, либо новее в своей ветке. Переходить ради этого на другую ветку не нужно.
• PHP 8.1 и старше команда PHP больше не исправляет. Таким сайтам нужен переход на поддерживаемую ветку, и это работа с проверкой на копии сайта.
• Как узнать свою версию. В админке Битрикса: Настройки, Инструменты, Диагностика, Настройки PHP. На хостинге: в панели управления. Нужны две строки, номер версии и Server API.
• Временные меры в настройках PHP есть, но команда PHP пишет прямо: безопасной установку они не делают. Полное решение одно, обновление.
• Сайт на конструкторе вроде Тильды обновлять не вам: сервер там обслуживает платформа.

Что произошло 21 октября

Команда PHP выпустила исправления сразу для четырёх поддерживаемых веток и назвала обе уязвимости критическими. Через них можно выполнить произвольный код на сервере, не входя на сайт: в терминах объявления это unauthenticated remote code execution.

У каждой уязвимости есть номер в общем реестре и подробное описание на GitHub: CVE-2026-109618 и CVE-2026-109619. Оценка 9,2 из 10 попадает в верхнюю ступень шкалы, которая так и называется: критическая. Нашли уязвимости четыре исследователя, исправляли четыре разработчика ядра PHP.

Для тех, кто привык откладывать обновления, в объявлении есть важная строка: дистрибутивы Linux и поставщики долгой поддержки получили исправления заранее, до публикации. Поэтому команда PHP советует проверить обновлённые пакеты у своего поставщика сразу, без ожидания. Исключение одно. Если PHP на сервере поставлен из бесплатного репозитория rpms.remirepo.net, который ведут волонтёры, обновлений там в день выпуска не будет, и команда PHP советует перейти на пакеты дистрибутива или собрать PHP из исходников.

Как работает уязвимость, если объяснять без кода

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

Сервер с PHP держит несколько рабочих процессов, и каждый обслуживает запросы по очереди, как кассир в магазине. Между покупателями кассир убирает со стойки. Первая уязвимость, CVE-2026-109618, срабатывает, когда у кассира посреди оформления кончилось место: он бросает дело на полпути, а уборка потом принимает недооформленный чек за настоящий. Нехватку памяти злоумышленник вызывает нарочно. Например, отправляет форму с огромным числом заголовков или вложенных полей: в описании уязвимости сказано, что внутри PHP такие данные занимают намного больше памяти, чем при передаче по сети.

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

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

Касается ли это вашего сайта

Если сайт сделан на PHP и сам отвечает на запросы из интернета, касается. Различается степень риска, и зависит она от режима, в котором PHP запущен на сервере.

PHP стоит на 69,3 % сайтов, у которых известен серверный язык, по данным W3Techs на 21 октября 2026 года. На нём написаны Битрикс, WordPress, Joomla и OpenCart. Что известно про каждый режим, начиная с самого опасного:

• Apache с модулем PHP, mod_php. Для него команда PHP оценивает риск как наибольший: показана рабочая атака, которой не нужны ни вход на сайт, ни код сайта. Битрикс в технических требованиях называет Apache рекомендуемым веб-сервером. Сам по себе Apache ещё не значит mod_php, PHP при нём запускают и по-другому, но на сайте на Битриксе режим стоит проверить первым делом.
• FrankenPHP. По разбору кода в описании первой уязвимости он завершает запрос так же, как Apache с модулем, и, скорее всего, уязвим без участия кода сайта.
• PHP-FPM, обычно в связке с nginx. Разбор кода показывает, что он тоже уязвим, хотя полностью рабочей атаки на него по первой уязвимости не продемонстрировано. По второй показан путь, которому нужна подходящая операция в коде самого сайта. Обновлять его нужно так же срочно.
• LiteSpeed и php-cgi названы в объявлении среди уязвимых вместе с остальными.
• PHP только в консоли, например для задач по расписанию, в зоне риска не назван: объявление говорит об установках, которые обслуживают веб-запросы. Но если на той же машине открыт хоть один адрес с PHP, например панель управления базой данных, сервер под правило попадает.

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

Как узнать версию PHP за пять минут

Нужны две строки из настроек PHP: номер версии и Server API, то есть режим, в котором PHP запущен. Показывают их админка Битрикса, панель хостинга или служебная страница phpinfo.

1. Битрикс. В админке: Настройки, затем Инструменты, Диагностика и Настройки PHP. Тот же раздел открывается по адресу ваш-сайт.ru/bitrix/admin/phpinfo.php, если вы вошли как администратор. Версия написана крупно в первой строке, Server API в таблице ниже.
2. Панель хостинга. Версию PHP обычно показывают в настройках сайта или домена, там же её переключают. Если на аккаунте несколько сайтов, у каждого может стоять своя. Server API панель показывает не всегда, тогда хватит одного письма в поддержку, текст ниже.
3. WordPress. Инструменты, Здоровье сайта, вкладка Информация, раздел Сервер: там есть и версия PHP, и PHP SAPI, это тот же Server API.
4. Свой сервер. Команда php -v в консоли покажет версию консольного PHP, а она может отличаться от той, что обслуживает сайт: на одной машине их бывает несколько. Надёжнее посмотреть phpinfo самого сайта.

В строке Server API вы увидите одно из значений:

• Apache 2.0 Handler, а начиная с PHP 8.4 Apache 2 Handler: PHP работает модулем Apache, режим с наибольшим риском;
• FPM/FastCGI: PHP-FPM;
• CGI/FastCGI: php-cgi или похожая схема;
• строка со словом LiteSpeed или FrankenPHP: соответствующий сервер.

Первые две цифры версии, например 8.2, это ветка. Последняя, номер выпуска внутри ветки, должна быть не меньше исправленной: для 8.2 это 35, для 8.3 это 36, для 8.4 это 27, для 8.5 это 12. Все ветки со сроками поддержки собраны в таблице после текста

Одна тонкость. Дистрибутивы Linux и поставщики долгой поддержки иногда переносят исправление в пакет со старым номером: версия может значиться как 8.2.20, а заплатка внутри уже стоит. Если PHP у вас из пакетов дистрибутива и номер ниже нужного, смотрите бюллетень безопасности дистрибутива: номер версии здесь ничего не скажет.

Что делать сегодня

Обновить PHP до исправленного выпуска своей ветки и перезапустить все его процессы. Кто это делает, зависит от того, где живёт сайт.

• Обычный хостинг. PHP обновляет хостинг, у вас к нему доступа нет. Ваша задача: убедиться по номеру версии, что обновление встало, а если нет, написать в поддержку письмом выше. Если в панели можно выбрать ветку и у вас стоит 8.1 или старше, не переключайте её в тот же вечер вслепую: сначала прочитайте раздел про старые ветки
• Свой сервер или VPS. Обновите пакеты PHP из репозитория дистрибутива и перезапустите PHP-FPM или Apache, а лучше все службы, где работает PHP. Пока процесс не перезапущен, в памяти работает старый код, хотя на диске уже лежит новый.
• Виртуальная машина Битрикса, BitrixVM. PHP на ней обновляется через меню самой машины: в справке Битрикса указан пункт Manage servers in the pool, затем Update PHP and MySQL. Встал ли исправленный выпуск, проверяется той же строкой версии.
• Сайт ведёт подрядчик или штатный программист. Перешлите ему ссылку на объявление и попросите ответить двумя строками: какая версия стоит сейчас и когда будет исправленная. Ответ "у нас всё нормально" без номера версии ответом не считается.

Обновление внутри ветки, например с 8.2.33 на 8.2.35, почти никогда не ломает сайт: такие выпуски исправляют ошибки и не меняют поведение языка. Его можно ставить сегодня без долгой подготовки. Ломает сайты другое: переход между ветками, скажем с 8.1 на 8.3. Его готовят на копии, и о нём ниже

Если обновить сегодня нельзя

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

• Против первой уязвимости: memory_limit=-1, заданный так, чтобы сайт не мог его переопределить, например через php_admin_value в настройках пула FPM или Apache. Цена: тяжёлый скрипт сможет занять всю память сервера, поэтому держать эту настройку дольше нескольких дней не стоит.
• Там же: небольшой post_max_size. 8M, если сайт не принимает файлы, и 32M, если принимает, а upload_max_filesize меньше этого значения. Если сайт принимает крупные файлы, например выгрузку из 1С, проверьте её после изменения: она может упереться в новый предел.
• Против второй: session.upload_progress.enabled=0 в php.ini или настройках пула, затем перезапуск всех процессов PHP. Через ini_set() в коде и через файл .user.ini эта настройка не сработает.
• На PHP 8.5 дополнительно fatal_error_backtraces=0 и снова перезапуск всех процессов.
• Чего не делать: ставить вместо memory_limit системные ограничения памяти RLIMIT_AS и RLIMIT_DATA. По словам команды PHP, именно они вызывают нужный атакующему сбой.
• Что не помогает: скрыть ошибки через display_errors, error_reporting или знак @. В описании второй уязвимости это сказано отдельно.

Перезапуск процессов в этих пунктах не формальность. Без него новая строка в файле настроек ничего не меняет, и проверка "мы же всё поставили" ничего не доказывает.

PHP 8.1 и старше: что делать, если исправления не будет

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

Таких сайтов много. По данным W3Techs на 21 октября 2026 года, среди сайтов на PHP 27,0 % работают на седьмой версии и 7,7 % на пятой. Выпусков с исправлением для них команда PHP не делает. Но из-за серьёзности уязвимостей она сделала исключение и выложила минимальные исправления в исходном коде для 7.4, 8.0 и 8.1. Они нужны тем, кто сам собирает PHP, а на обычном хостинге ими не воспользуешься. Некоторые дистрибутивы и поставщики долгой поддержки переносят исправления в старые ветки сами: если сервер на таком пакете, спросите своего поставщика.

У сайтов на Битриксе есть второй срок. С 1 февраля 2026 года Битрикс ограничил поддержку своих продуктов на PHP ниже 8.2. Обновления коробочных версий не ставятся, пока PHP не поднят хотя бы до 8.2, а рекомендует Битрикс версию 8.3 и выше. Значит, сайт на Битриксе с PHP 8.1 уже больше восьми месяцев не может обновить и саму платформу.

Куда переходить: не на 8.2. Её поддержка безопасности заканчивается 31 декабря 2026 года, через два с небольшим месяца. Разумная цель сегодня 8.3, которую чинят до конца 2027 года, или 8.4, которую чинят до конца 2028 года, если с ней совместимы ядро и модули сайта.

PHP 8.6 по плану выйдет 19 ноября 2026 года. Переводить на неё рабочий сайт в первые недели мы бы не стали: пусть сначала под новую ветку обновятся платформа и модули, которыми пользуется сайт.

Как понять, не взломали ли сайт раньше

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

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

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

И главное: есть ли копия сайта, снятая до 21 октября и лежащая отдельно от сервера. Если что-то найдётся, именно она решит, сколько займёт возвращение. Ещё четыре проверки, которые владелец делает сам, и порядок действий при подозрении разобраны на странице о безопасности сайта

Плохая новость про нас

Первая: наша собственная копия для разработки в день выпуска работала на PHP 8.2.33. Это видно на скриншоте выше: на два выпуска ниже исправленного. Снаружи до неё не достать, но мы заметили это, только когда сели писать статью. Правило "обновиться внутри ветки" касается нас так же, как вас.

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

Третья: переход со старой ветки не делается за вечер. Если сайт на Битриксе давно не обновлялся и в файлах платформы есть правки, переход на 8.3 начинается с подсчёта, сколько их и что сломается. Срок такой работы мы называем после проверки копии. Как считаются правки, описано на странице поддержки Битрикса