Утром в почту приходит письмо от DigitalOcean с пометкой «URGENT» в теме. В начале письма говорится о двух критических уязвимостях в PHP: обе позволяют удалённо выполнить код (RCE), а их номера — CVE-2026-109618 и CVE-2026-109619. Бывают письма, которые нельзя отложить «на потом», и это одно из них. PHP лежит в основе очень большой части сайтов в мире, а для такой уязвимости не нужны даже логин и пароль.
В этой статье мы рассказываем, что произошло, в чём суть уязвимостей, какие именно меры против них существуют и как наша команда закрыла ситуацию за один день. Цель — дать понятный ориентир для проверки собственного сайта и сервера и показать, как бизнесу стоит действовать в такой ситуации.
Что произошло
21 октября 2026 года проект PHP выпустил версии PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Это обновления безопасности, которые закрывают две критические уязвимости: CVE-2026-109618 и CVE-2026-109619. Сам PHP описал обе как уязвимости, способные привести к удалённому выполнению кода без аутентификации, и призвал всех пользователей немедленно обновиться. Уязвимостям часто дают общее название PHP2Shell, а уровень опасности обеих по шкале CVSS v4.0 оценён в 9,2 — то есть это критическая зона.
Уведомление пришло к нам от хостинг-провайдера. DigitalOcean предупредил клиентов о ситуации и попросил провести обновление срочно. Здесь важно вот что: вскоре после того, как уязвимость становится известной, появляются попытки её эксплуатации. Некоторые исследования безопасности сообщали, что попытки эксплуатации фиксировались ещё до официального раскрытия, поэтому в этом случае время измеряется часами, а не неделями.
Уязвимости простым языком
Суть можно объяснить, не углубляясь в технические детали. Обе уязвимости связаны с ошибкой при работе с памятью: при обработке одного запроса PHP освобождает часть памяти, а затем всё ещё считает её используемой. В реальных условиях такая ошибка позволяет атакующему прочитать содержимое памяти сервера или выполнить собственный код.
Первая (CVE-2026-109618) связана с ошибкой в механизме, отслеживающем ход загрузки файлов, и её последствие — раскрытие содержимого памяти и выполнение кода. Вторая (CVE-2026-109619) возникает так: после фатальной ошибки (fatal error) внутреннее состояние одного запроса остаётся в памяти даже после её освобождения, а следующий запрос, обрабатываемый тем же рабочим процессом, использует его. Один из известных путей ко второй уязвимости — функция «session upload progress», которая в PHP включена по умолчанию и работает, даже если приложение никогда не использует сессии. Главный вывод прост: это брешь в самом PHP, а не в коде обычного сайта, даже если тот написан правильно, поэтому исправить её на уровне приложения невозможно.
Почему это касается бизнеса
На PHP работают WordPress, Joomla, многие системы интернет-магазинов, CRM и административные панели, а также индивидуальные проекты на фреймворках вроде Laravel. Поэтому уязвимость касается не одного сайта, а всего, что опирается на PHP: корпоративного сайта, каталога, личного кабинета, внутренней учётной системы. Если на сервере стоит уязвимая версия PHP, это проблема не одного сайта, а риск для всех проектов, размещённых на этом сервере.
Последствия тоже близки к бизнесу: взлом сайта, утечка данных клиентов, размещение на сайте вредоносного кода, использование сервера в чужих целях и, как итог, потеря репутации. Это невидимый, но важный технический фундамент сайта: сайт можно сделать красивым, но если PHP, на котором он стоит, не обновлён, вся работа может рухнуть одним запросом. Подобные риски мы обсуждали и в статье «Открытые порты и забытые сервисы».
Как мы действовали: план на один день
Получив уведомление, мы восприняли проблему не как плановую работу, а как срочное дело. Сначала разобрались в ситуации: определили, на каких серверах и в каких проектах используется PHP, какие версии стоят и у кого есть к ним доступ. Этот шаг важен, потому что без ответа на вопрос «сколько систем под угрозой?» полноценное обновление не провести: нередко новым риском оказывается один забытый старый сервер.
Затем мы действовали в два слоя. Первым, быстрым шагом включили временные параметры безопасности, рекомендованные самим PHP: отключили функцию session upload progress, а для PHP 8.5 применили параметр, отключающий трассировку фатальных ошибок. С самого начала мы понимали, что это не полное решение, и рассматривали его лишь как мост до момента, когда обновление будет готово. Вторым, основным шагом обновили PHP до закрытых версий — 8.2.35, 8.3.36, 8.4.27 или 8.5.12. Важное замечание: после обновления нужно перезапустить PHP-FPM и веб-сервер, иначе старые процессы, находящиеся в памяти, продолжат работать в уязвимом состоянии.
Третий шаг — проверка. После обновления мы заново подтвердили версию PHP на каждом сервере и убедились, что сайты работают, а формы и административные панели отвечают корректно. После этого усилили мониторинг журналов безопасности и необычной активности, потому что в первые дни после раскрытия уязвимости попыток атак становится больше. В итоге ситуацию мы закрыли за один день: от момента, когда мы узнали об уязвимости, до обновлённых и перезапущенных систем прошёл меньше чем один рабочий день. Такая скорость не случайна: она стала возможной благодаря уже существующему списку серверов, понятным ответственным и процессу, готовому к быстрому обновлению.
Временная мера и полное решение: в чём разница
Самая частая ошибка здесь — принять временные параметры за полное решение. Проект PHP прямо заявил: полностью защищающей меры смягчения нет, обновление — единственный надёжный выбор. Отключение параметра session.upload_progress.enabled закрывает один из известных путей ко второй уязвимости, но не все возможные варианты, и оно не относится к первой (CVE-2026-109618). Поэтому эту меру можно использовать лишь как краткосрочную защиту до обновления.
Важно и то, где задаётся параметр. По официальной рекомендации он должен находиться в файле php.ini или в конфигурации пула PHP-FPM, а установка через ini_set() или .user.ini не работает, потому что путь к уязвимости обрабатывается ещё до того, как запрос доходит до скрипта. После изменения параметра нужно перезапустить все рабочие процессы. А после обновления, если хостинг-провайдер отключил функции временно, не стоит включать их обратно самостоятельно — лучше дождаться, пока провайдер подтвердит выход патча.
Задайте вопрос или оставьте заявку
Определим версии PHP на ваших серверах, обновим их и настроим мониторинг — без простоя для бизнеса.
Отправляя форму, вы соглашаетесь с обработкой персональных данных.
Как проверить версию PHP
Если у вас свой сервер, прежде всего нужно узнать, какая версия установлена. В командной строке команда php -v покажет используемую версию, но для веб-сервера PHP-FPM или модуль Apache могут использовать другую версию, поэтому версию каждого пула стоит проверять отдельно. Если версия ниже 8.2.35, 8.3.36, 8.4.27 или 8.5.12, сервер уязвим.
В системах на основе Debian и Ubuntu обновление обычно выполняется через пакетный менеджер; например, правильно обновлять все пакеты PHP вместе: sudo apt update && sudo apt install --only-upgrade 'php8.*'. После этого нужно перезапустить службу PHP-FPM, например sudo systemctl restart php8.3-fpm (название меняется в зависимости от версии), а если используется Apache, перезагрузить и его. После обновления снова проверьте версию через php -v и посмотрите, как работает сайт. Если используется Docker, нужно пересобрать образ с новой версией PHP и перезапустить контейнер. Не забывайте, что для PHP 8.1 и более старых версий официального обновления от проекта PHP не выходило: в таком случае нужно запросить бэкпорт у провайдера или перейти на поддерживаемую версию.
Что делать, если сайт на хостинге
Если сайт размещён на общем хостинге, версией PHP на сервере управляет хостинг-провайдер, поэтому главное действие — прочитать уведомление провайдера и узнать, когда и как будет проведено обновление. Многие хостинг-провайдеры в такой ситуации обновляются сами в короткие сроки, а некоторые сначала включают защитные параметры и лишь затем выпускают патч. Если в панели управления можно выбрать версию PHP, переключите её на поддерживаемую и закрытую версию.
Параллельно проверьте и свою сторону: обновите WordPress, плагины и темы, удалите неиспользуемые плагины, включите для административной панели надёжный пароль и двухфакторную аутентификацию. Они не защитят от самой этой уязвимости, но закроют другие пути атакующего и повысят общую безопасность сайта. Если сайт поддерживает разработчик или студия, попросите у них письменно, что именно было сделано: это нормальная часть договора поддержки.
Чему нас научила эта ситуация
Эта история подтвердила несколько простых, но важных вещей. Во-первых, точный список серверов и проектов — главный фактор скорости в срочной ситуации: если вы не знаете, сколько систем у вас есть и где они стоят, массово обновить всё невозможно. Во-вторых, откладывать обновления «на тихое время» дорого: когда уязвимость становится публичной, атаки начинаются в течение нескольких часов (в зависимости от её силы), а команда с готовым процессом в этот момент уже работает.
В-третьих, нужно уметь отличать временную меру от полного решения: отключение параметра успокаивает, но не устраняет опасность. В-четвёртых, нельзя игнорировать уведомления провайдеров: письмо «URGENT» от таких провайдеров, как DigitalOcean, чаще всего говорит о реальной угрозе, и его нельзя пропустить, приняв за рекламу. И наконец, это случай, показывающий смысл договора поддержки: основа безопасности — не сделать сайт и забыть о нём, а постоянно его обновлять. Об этом мы писали и в статьях о договоре технической поддержки и сопровождении сайта.
Чек-лист
- Есть список всех серверов и проектов, отмечены те, что используют PHP
- На каждом сервере проверена версия PHP (8.2.35, 8.3.36, 8.4.27 или 8.5.12 и выше)
- До завершения обновления включён временный параметр (session.upload_progress.enabled = 0, для PHP 8.5 дополнительно fatal_error_backtraces = 0), и он задан в php.ini или в пуле PHP-FPM
- PHP обновлён, PHP-FPM/Apache и другие долгоживущие процессы перезапущены
- После обновления версия подтверждена заново, сайты, формы и административные панели проверены
- Для PHP 8.1 и старше запланирован бэкпорт или переход на поддерживаемую версию
- Docker-образы пересобраны, контейнеры перезапущены
- Уведомление хостинг-провайдера прочитано, срок обновления подтверждён
- Усилен мониторинг журналов безопасности и необычной активности
- В договоре поддержки назначен ответственный за обновления безопасности
