11 ноября 2026 г.
Автор
Рецензент
Вам не нужно быть разработчиком PHP или системным администратором, управляющим ПО на базе PHP, чтобы знать о недавней уязвимости PHP2Shell:
- Сообщения от CBS News, BBC, Le Monde (на французском языке), Australian Broadcasting Corporation, на крупных новостных сайтах и подкастах, таких как Hacker News, Bleeping Computer, Heise.de (на немецком языке), The Times of India и ITWire
- Премьер-министр Японии упомянул об этом
- Федеральное министерство цифровых технологий и модернизации государственного управления Германии, а также Министерство внутренних дел Франции и многие другие организации по всему миру отключили веб-сайты, пока они не будут исправлены
- Об этом — до сих пор — говорят во всех социальных сетях, например, АНБ опубликовало сообщение: «Вступает в силу немедленно: всем организациям, использующим PHP для своих систем, рекомендуется подготовиться к обновлению, устраняющему две критические уязвимости»
На всякий случай, если вы пропустили, PHP2Shell представляет собой комбинацию двух эксплойтов RCE (удаленное выполнение кода): CVE-2026-109618, который представляет собой RCE через повреждение OOM (исчерпание памяти), и CVE-2026-109619, который представляет собой RCE через устаревшее глобальное состояние.
Цитируя The PHP Foundation (выделение мое):
CVE-2026-109618: Если запрос достигав предела памяти PHP в абсолютно неподходящий момент, PHP мог оставлять частично инициализированные внутренние данные и позже рассматривать их как действительные, что приводило к повреждению памяти. На Apache с mod_php неаутентифицированный запрос может спровоцировать это до того, как запустится какой-либо код приложения, и было продемонстрировано полное удаленное выполнение кода с настройками по умолчанию. Удаленное выполнение кода также было подтверждено на PHP-FPM через пути кода на уровне приложения.
CVE-2026-109619: Критическая ошибка в неподходящий момент могла привести к тому, что внутреннее состояние указывало на память, принадлежавшую предыдущему запросу. Последующий запрос, обрабатываемый тем же воркером, мог затем использовать эту освобожденную память. Было подтверждено использование освобожденной памяти (use-after-free) и падение воркера, а автор доклада продемонстрировал удаленное выполнение кода против реального приложения, работающего на Apache с mod_php.
Оба эксплойта затрагивают каждую версию PHP вплоть до PHP 5.4!
Как это было обнаружено?
CVE-2026-109618 , когда одна из проблем, обнаруженных во время внешнего аудита безопасности PHP, была исправлена. Однако эксплойт так и не был исправлен по нескольким причинам:
- Основная команда разработчиков не была уверена, что его можно легко использовать
- Другие проблемы считались более насущными
- Исправление проблемы, вероятнее всего, привело бы к нарушению обратной совместимости, потребовало бы значительного объема работы при имеющихся ресурсах, а также создало бы неопределенность относительно влияния исправления на более широкое сообщество
Затем, в 2026 году в рамках программы OpenAI Patch the Planet, два юридических лица провели более свежий аудит: Calif и Wiz. Этот аудит привел к обнаружению более раннего RCE, а также более позднего — CVE-2026-109619. Кроме того, компании показали, как можно использовать оба эксплойта, и какова их степень опасности.
Если говорить о конкретных цифрах, оба эксплойта оцениваются в 9,2 балла из возможных 10,0 по шкале CVSS (Common Vulnerability Scoring System) 4.0, что делает их критическими. Более того, ни для одного из эксплойтов не требовался логин. Оба эксплойта могут позволить неаутентифицированным злоумышленникам запускать код с привилегиями пользователя воркера PHP, например, www-data.
К сожалению, до того, как удалось завершить скоординированные усилия по выпуску патча для PHP, видео с доказательством концепции (PoC) было случайно слито в сеть. Сохранять нечто подобное в тайне слишком долго практически невозможно.
Вскоре после этого были выпущены обновления PHP для четырех самых последних версий, а также бэкпорты для PHP 8.1, 8.0 и 7.4. Несмотря на то, что последние три версии больше не поддерживаются, они были пропатчены из-за масштаба влияния этих эксплойтов.
Учитывая все этапы между слиянием изменений в PHP и их доступностью в качестве обновления, эти патчи стали доступны довольно быстро.
Были ли эти эксплойты успешно использованы?
Да! Mallory подтвердила это 26 октября:
Dream Research сообщила об артефактах кампании, которая захватила 25 серверов путем объединения PHP2Shell с уязвимостью повышения привилегий в ядре Linux Fragnesia (CVE-2026-46300).
В дополнение к этому Cloudflare, Imperva и Check Point сообщили о попытках атак с использованием эксплойтов «в количестве от сотен тысяч до миллионов», а также о поступающих отчетах от AWS.
Что вам нужно сделать?
Чтобы защититься от этих уязвимостей безопасности, вам необходимо проверить все приложения, использующие PHP. Следуйте приведенным ниже инструкциям для обеспечения безопасности, обязательно проверив, не используют ли какие-либо из ваших приложений PHP, о чем вы могли забыть или упустить из виду.
Шаг 1: Проведите инвентаризацию всего кода и инсталляций, зависящих от PHP
Поскольку PHP повсеместен, ищите не только в очевидных местах, таких как ПО, которое вы разрабатываете, или ПО, которым вы управляете и которое, как вы знаете, основано на PHP. Ищите везде.
Цитата Стива Гибсона из episode 1102 of the Security Now podcast:
Я считаю, что найдутся забытые системы, которые находятся в подсобке или, как мы часто говорим в подкасте, в каком-то пыльном чулане, где их никто не будет обновлять. Злоумышленник сможет туда проникнуть. Также неверно и то — и мы видели намеки на это в некоторых репортажах, которыми я поделился, — что непосредственные доказательства концепции являются зрелыми, надежными и работают независимо от версии PHP.
Вероятно, в вашей организации найдется множество мест, где может присутствовать PHP. Например:
Тип ПО
Доступное ПО
CMS (системы управления контентом)
Wordpress, Drupal, TYPO3, Joomla и Silverstripe
Электронная коммерция
Magento, WooCommerce и OpenCart
Фреймворки
Laravel, CakePHP, Laminas или Symfony
Платформы умного дома
Jeedom
Устройства NAS (сетевые хранилища данных)
Некоторые продукты от QNAP, Synology, Asustor и Unraid
Программное обеспечение для хранения данных
Nextcloud и OwnCloud
Стек разработки
XAMP, WAMP и MAMP
ПО для досок объявлений и форумов
Moodle и phpBB
Бизнес-ПО
SugarCRM
ПО для веб-хостинга
Plesk, cPanel и ISPConfig
Ознакомьтесь с руководством Mallory по корпоративному ПО на базе PHP. Руководство разбито по задачам, таким как телефонные системы, контейнеры и образы, NAS и хранилища, а также панели управления хостингом, что делает его невероятно простым для использования.
Независимо от того, используете ли вы электронную таблицу, приложение или бумагу с ручкой, обязательно проведите инвентаризацию и поддерживайте ее в актуальном состоянии. Если вы не знаете, с чего начать, я создал таблицу Google Sheet, которая поможет вам в этом.
Шаг 2: Обновите PHP
Были выпущены PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, каждая из которых содержит исправление для двух рассматриваемых эксплойтов. Обновитесь до ближайшей версии как можно скорее.
Загрузки исходного кода и бинарных файлов доступны, а обновленные пакеты можно найти в предпочитаемом менеджере пакетов вашего дистрибутива Linux, например, APT, Yum и т. д. Кроме того, несмотря на прекращение их поддержки, исправления также доступны для PHP 7.4, 8.0 и 8.1. Если вы используете контейнеры, пересоберите их, используя соответствующий пропатченный тег из официальных источников, таких как Docker Hub.
Обязательно перезапустите все экземпляры и воркеры, чтобы убедиться, что они используют новые версии PHP.
Шаг 2а: Настройте PHP, если вы не можете выполнить обновление
Обновление возможно не всегда, поскольку проекты могут иметь зависимости, привязанные к более ранним неисправленным версиям PHP. В таких случаях остается ряд параметров, которые можно настроить, чтобы снизить вероятность уязвимости к одному или обоим эксплойтам.
Хотя это полезно, полным решением является только установка патчей. Поэтому при необходимости рассмотрите возможность отключения сервисов.
Вот краткая сводка the guidance from PHP.net:
Для CVE-2026-109618:
- Установите для memory_limit значение -1. php2shell.com рекомендует также использовать Linux cgroup v2 memory.max (или аналогичный механизм) для сдерживания потребления ресурсов и ограничения воздействия на процессы PHP. Если вы используете контейнер, подумайте об установке deploy.resources.limits.memory в подходящее значение или обратитесь к документации вашего хостинг-провайдера, чтобы узнать, какие лимиты ресурсов разрешено настраивать.
- Установите низкое значение :
- Если одно или несколько ваших приложений не используют загрузку файлов, установите значение 8M.
- Если загрузка файлов необходима, установите значение 32M.
- Рекомендуется установить на уровне веб-сервера или прокси ограничения для размера декодированного запроса, количества полей ввода, количества частей multipart, количества заголовков и глубины вложенности. Эти ограничения также должны распространяться на запросы без используемого заглавия content-length.
- Удерживайте значение ниже post_max_size.
Для CVE-2026-109619:
- Установите для session.upload_progress.enabled значение 0 и перезапустите все рабочие процессы (воркеры)
- В PHP 8.5 установите fatal_error_backtraces в значение 0 и перезапустите соответствующие рабочие процессы
- Удалите недействительные или устаревшие параметры, применяемые для каждого запроса, которые вывод сообщения диагностики до инициализации
- Устраните фатальные ошибки и тайм-ауты выполнения, доступные злоумышленникам, включая сбои в обратных вызовах (callbacks), обработке и очистке при загрузке или импорте
- Убедитесь, что изменения в php.ini не могут быть переопределены настройками воркеров
Перезапустите все экземпляры и рабочие процессы, чтобы убедиться, что они используют новую конфигурацию.
Что вам следует делать дальше?
Мэтью Вайер О'Финни из Perforce рекомендует следующие лучшие практики безопасности PHP:
- Всегда пишите код с учетом безопасности PHP: следите за ежегодным рейтингом десяти основных рисков безопасности веб-приложений от The OWASP Foundation.
- Регулярно обновляйте все компоненты приложения: как отмечалось ранее, убедитесь, что вы регулярно обновляетесь до последней версии PHP.
- Изучите и задокументируйте существующую инфраструктуру: чтобы гарантировать, что ни одна инсталляция не останется без патча, и сократить объем работы, делайте это регулярно.
- Развертывайте защищенные образы контейнеров: по возможности используйте защищенные контейнеры, чтобы обеспечить максимальную безопасность ваших PHP-приложений и избавить себя от необходимости самостоятельно повышать уровень их защищенности.
- Убедитесь, что ваша инфраструктура PHP настроена правильно
- Обучайте и тренируйте всех сотрудников тому, как поддерживать безопасность PHP-приложений: правильная разработка программного обеспечения выходит за рамки простого написания кода. Она включает в себя такие практики безопасного кодирования, как предотвращение SQL-инъекций, обеспечение безопасности PHP (то есть организация безопасных сессий) и многое другое. Обязательно включайте это в стандартные сессии обучения разработчиков.
- Взаимодействуйте со сторонними экспертами по безопасности PHP для получения дополнительной поддержки: независимо от размера, разнообразия или обеспеченности ресурсами организации, она всегда может извлечь выгоду из специализированной внешней поддержки. Если позволяет бюджет, привлекайте профессионалов в области безопасности для проверки вашего кода и конфигурации PHP.
И я добавлю еще один совет от Дамьена Сеге (Damien Seguy), старшего разработчика PHP в Exakat: будьте готовы пересобрать или обновить свою инсталляцию в любой момент. Однако находитесь ли вы в положении, позволяющем это сделать? Насколько просты и надежны ваши процедуры развертывания? Это идеальное время, чтобы пересмотреть их, разобраться и при необходимости наметить планы по их улучшению.
Спонсируйте ваши любимые проекты с открытым исходным кодом
PHP лежит в основе множества коммерческих сервисов и проектов, которые существенно (или исключительно) формируют прибыль компаний. Но, несмотря на эту важность, язык по-прежнему критически недофинансирован.
По данным The PHP Foundation, общая сумма поступлений от спонсоров и индивидуальных доноров составила 730 534 доллара США. Сравните это с годовыми — или даже квартальными — доходами компаний из индекса S&P 500. По данным FatFIRE, за последние двенадцать месяцев их выручка составила примерно 18,3 триллиона долларов США.
Было бы здорово, если бы эти компании, а также другие компании и организации, использующие PHP, действительно вносили свой вклад в развитие PHP (и других используемых ими проектов с открытым исходным кодом). А пока, если можете, спонсируйте своего любимого контрибьютора, любимый проект или The PHP Foundation. И по возможности призывайте к этому вашу организацию или компанию.
Это звучит банально, но если бы каждый внес хотя бы небольшую лепту, это имело бы огромное значение.
Несмотря на относительный недостаток финансирования и ресурсов, сообщество PHP показало свою проактивность в обеспечении безопасности интернета. Это продемонстрировано тем, как оно отреагировало на уязвимость PHP2Shell — спокойно, организованно и продуманно. Это был отличный пример того, как следует реагировать в подобных ситуациях.
Не теряйте бдительность
Шум в новостях помог гарантировать, что если вы несли ответственность за сайт на PHP или связанный с ним ресурс, вы знали о необходимости действовать немедленно — иначе ваш сайт был бы взломан!
Однако, как и в случае с большинством событий такого масштаба, сначала возникло всеобщее внимание (даже истерия), а затем новостная повестка сменилась, о чем свидетельствует график ниже от Censys.
Тем не менее, это не значит, что проблема исчезла. По данным Censys, из 46 272 123 инсталляций PHP (с известными версиями), которые они идентифицировали как уязвимые 21 октября, 29 311 837 по-прежнему остаются уязвимыми на момент написания статьи.
К счастью, сервисы, работающие на более новых поддерживаемых версиях PHP, были пропатчены. К сожалению, сервисы под управлением PHP 8.1 и 7.4 все еще уязвимы.
Если вы еще этого не сделали, я настоятельно рекомендую провести полную инвентаризацию ваших систем и убедиться, что они пропатчены. Затем проводите аудиты на регулярной основе. Поступая так и следуя лучшим практикам безопасности PHP, вы будете максимально готовы к появлению следующего эксплойта.
Дополнительное чтение
Мэтью Сеттер — редактор разделов PHP и Go в команде Twilio Voices. Он также является автором книг Mezzio Essentials и Deploy with Docker Compose. С ним можно связаться по адресу msetter@twilio.com. Он также есть в LinkedIn и GitHub.
