Уязвимость PHP2Shell

21–22 октября 2026 года государственные порталы, медицинские сервисы и инструменты Wikimedia оказались в центре международной операции по срочному обновлению PHP. Часть ресурсов временно отключили сами владельцы.

Категории: Технологии Экономика Наука

Причиной стали две критические уязвимости, допускающие выполнение постороннего кода на сервере. Эта история показала, насколько доступность повседневных цифровых услуг зависит от безопасности общего программного основания.

Почему мир отключал сайты и что две уязвимости рассказали об устройстве интернета

Когда отключение становится защитой

Что увидели пользователи

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

Правительство Нидерландов сообщило о предупредительном отключении Overheid.nl, MijnOverheid.nl и DigiD. Национальный центр кибербезопасности NCSC временно вывел из сети даже собственный сайт. Причиной была необходимость сократить риск до установки исправлений. [1, 2]

Это не доказывает, что перечисленные системы были взломаны. Отключение ограничивало доступ потенциального атакующего к опасному компоненту. Для пользователей результатом становился простой, но его назначением была защита сервисов и данных.

Тезис 1: В этой истории недоступность сайта часто была следствием защитного решения. Масштаб отключений нельзя автоматически приравнивать к масштабу успешных взломов.

Почему заголовок требует точности

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

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

Общая зависимость, которую обычно не видно

Что такое PHP

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

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

WordPress, Drupal, Joomla и MediaWiki входят в число известных систем этой экосистемы. Однако принадлежность сайта к определённой CMS не исчерпывает вопрос безопасности: PHP используется и в самостоятельно разработанных приложениях. [3]

Что действительно означает цифра «70%»

По данным W3Techs на 22 октября 2026 года, PHP использовали 69,3% сайтов, серверный язык которых удалось определить. Важна вся формулировка: речь идёт о наблюдаемой группе сайтов с установленной технологией, а не о 69,3% всего интернет-трафика или всех цифровых сервисов планеты.

Внутри PHP-сегмента распределение выглядело так: PHP 8 — 65,3%, PHP 7 — 26,9%, PHP 5 — 7,7%, PHP 4 — 0,1%. Суммарно поколения ниже PHP 8 составляли около 34,7% наблюдаемых PHP-сайтов. Это показатель распространённости старых технологий, а не подсчёт взломанных ресурсов. [4]

Тезис 2: Массовое использование общей технологии превращает ошибку одного компонента в распределённый риск для множества независимых организаций.

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

Две ошибки памяти с большим радиусом действия

Почему программной памяти нужна строгая дисциплина

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

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

Первая уязвимость: незавершённые структуры

CVE-2026-109618 связана с обработкой нехватки памяти. Прерывание может произойти, пока внутренние данные ещё не полностью инициализированы. Последующая очистка запроса способна обработать их как корректные.

В официальном бюллетене подтверждено выполнение кода без аутентификации в конфигурации Apache mod_php. Опасная последовательность может начаться ещё до выполнения кода сайта. Результат — код с правами рабочего процесса, что не равнозначно автоматическому получению административных прав root. Надёжность атаки зависит от сборки PHP, расширений и расположения данных в памяти. [5]

Вторая уязвимость: след предыдущего запроса

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

Этот класс ошибок называется use-after-free — использованием памяти после освобождения. Важно, что речь идёт о состоянии самого процесса PHP, а не только о пользовательской сессии или ошибке прикладного кеширования. [6]

Тезис 3: Уязвимость среды выполнения способна поставить под угрозу приложение даже тогда, когда его собственный код написан аккуратно и своевременно обновляется.

Чем опасно выполнение постороннего кода

Remote code execution, RCE, означает возможность заставить удалённую систему выполнять код атакующего. Дальнейшие последствия зависят от прав процесса и доступных ему ресурсов.

Исследователи Wiz описали демонстрации атак на WordPress, Drupal и Joomla, а также раскрытие памяти процесса. В ней могут находиться пароли, токены и API-ключи. Названные CMS служили исследовательскими целями; наличие именно этих продуктов не является обязательным условием риска. [3]

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

Почему опасность различалась между серверами

Один язык — несколько способов запуска

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

Официальное предупреждение включает PHP-FPM, mod_php, php-cgi, FrankenPHP и LiteSpeed. Наибольший риск разработчики выделили для mod_php. Это не делает остальные варианты безопасными. [7]

Тезис 4: Различия серверных конфигураций меняют условия эксплуатации уязвимости, но не отменяют необходимость исправить уязвимый компонент.

Почему нельзя обещать универсальный сценарий атаки

В раннем техническом описании первой CVE отмечалось отсутствие продемонстрированного полного эксплойта для FPM в рамках изложенного анализа. В последующей ретроспективе PHP Foundation сообщалось о подтверждении RCE через прикладные пути на PHP-FPM. [5, 8]

Такое расхождение показывает, как уточняется знание во время инцидента. Для статьи корректно фиксировать источники и границы доказанного. Для оператора практический вывод устойчив: PHP-FPM официально находится в зоне риска.

Фраза «любой PHP-сайт взламывается одним запросом» чрезмерно упрощает ситуацию. Наличие уязвимого кода, доступность конкретного пути атаки и успешность эксплуатации — разные условия.

От ранних признаков до экстренного выпуска

Почему исправление заняло время

PHP Foundation сообщила, что первые признаки проблемы с нехваткой памяти были выявлены ещё в 2024 году, при работе с результатами аудита Quarkslab. Однако тогда не был установлен конкретный путь практической эксплуатации.

Фонд признал задержку структурной проблемой: конкурирующие решения создавали риски несовместимости и нарушения работы расширений, а специалистов с глубоким знанием ядра не хватало. [8]

Тезис 5: Найти ошибку и безопасно исправить её во всей экосистеме — разные задачи. Между ними находятся проверка совместимости, инженерные решения и доступность специалистов.

Это не снимает ответственности за задержку. Но объясняет, почему сопровождение базовой технологии нельзя свести к вопросу «почему разработчик просто не исправил строку». В фундаментальном компоненте локальная правка способна изменить поведение большого числа зависимых продуктов.

Что ускорило выпуск

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

Первоначальный выпуск, намеченный на 22 октября, перенесли на 21 октября. Публичный анонс устанавливал время 14:00 UTC — 17:00 МСК. ENISA указывает, что обновления появились в 13:40 UTC — 16:40 МСК. [8, 9, 10]

Таким образом, на 22 октября новость уже состояла не в ожидании исправлений, а в их распространении, установке и восстановлении отключённых сервисов.

География отключений: конкретные услуги вместо общего счётчика

Нидерланды: затронуты не все государственные ресурсы

Наряду с крупными государственными порталами часть ресурсов отключила судебная система. Недоступными стали Werkenbijderechtspraak.nl, SSR.nl / MijnSSR, а также файловый сервис с информацией о заседаниях для журналистов.

Основные Rechtspraak.nl и Mijn Rechtspraak продолжали работать: по сообщению судебной системы, они не использовали PHP. Аналогичное уточнение правительство сделало для Rijksoverheid.nl. [1, 11]

Эти примеры не позволяют говорить о полной остановке электронного государства. Они показывают неоднородность его инфраструктуры: разные услуги могут иметь разные технологии и зоны ответственности.

Бельгия: медицинский портал вернулся через несколько часов

Официальная страница состояния eHealth фиксирует инцидент 21 октября с 15:45 до 21:00 по времени страницы. Продолжительность составила 5 часов 15 минут. После приоритетной установки исправлений портал вернулся в сеть.

Оператор уточнил последствия: приложения были недоступны через портал. Это не утверждение об остановке всех медицинских информационных систем Бельгии. [12]

Финляндия: отключение без установленного взлома

Финский CSC — центр информационных технологий для науки — временно остановил часть сервисов. Организация прямо объяснила, что это предупредительная мера, а не следствие известных ей случаев эксплуатации. [13]

Германия: восстановление началось в тот же день

По сообщению dpa, в Тюрингии временно отключали сайты земельной администрации, полиции и МВД. Многие ресурсы снова работали поздним вечером 21 октября. Сайт земельного парламента оставался доступным. [14]

Тезис 6: Последствия цифрового инцидента следует измерять через конкретные услуги, продолжительность простоя и условия восстановления, а не только через громкие названия стран и организаций.

Wikimedia: сложность распределённого управления

Wikimedia Foundation подтвердила отключение вспомогательных сервисов, включая Toolforge и Cloud VPS, и предупредила о возможных перебоях в работе вики.

Часть инструментов поддерживают добровольные разработчики, самостоятельно управляющие версиями PHP. Поэтому восстановление зависело не только от центральной технической команды, но и от владельцев отдельных сервисов. [15]

Это характерная проблема больших цифровых экосистем: общая инфраструктура не обязательно означает единый порядок обновления всех размещённых в ней приложений.

Угроза вышла за пределы лаборатории

Что зафиксировала Amazon

Amazon Threat Intelligence обнаружила в телеметрии сети ловушек MadPot попытку эксплуатации от 17 октября 2026 года, до выпуска исправлений и подробного публичного раскрытия. Запрос исходил из инфраструктуры коммерческой анонимизации.

Дополнительные попытки наблюдались 21 октября. Различия в нагрузках и сетевой инфраструктуре, по оценке AWS, указывали на нескольких участников. При этом компания оговорила: неизвестно, были бы ранние попытки успешны против реальных систем. После раскрытия AWS сообщила о широком использовании уязвимостей в атаках. [16]

Тезис 7: Дата публикации предупреждения не обязательно совпадает с началом атак. Проверка безопасности должна учитывать период до официального раскрытия.

Установка исправления устраняет известный путь будущей эксплуатации, но сама по себе не отвечает на вопрос, происходило ли вмешательство раньше. Поэтому AWS рекомендует начинать ретроспективную проверку как минимум с 17 октября.

Что увидела Cloudflare

Cloudflare сообщила об атакующем трафике и изменении запросов в попытках обойти защиту. По данным компании, автоматические правила для клиентов WAF начали действовать 21 октября с 03:02 UTC.

Компания также подчеркнула, что защитные фильтры не отменяют обновления PHP. Фильтр анализирует взаимодействие с сервером, тогда как исправление меняет опасное поведение самой среды выполнения. [17]

Какую роль сыграл искусственный интеллект

Сложность перестала быть достаточным препятствием

Исследователи Wiz связывают практическую разработку атак с применением современных моделей и автоматизированных исследовательских инструментов. По их оценке, ИИ помог работать со сложными цепочками ошибок и адаптировать демонстрации к приложениям. [3]

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

Тезис 8: Развитие ИИ меняет цену и скорость исследования уязвимостей. Ошибка, эксплуатация которой раньше требовала исключительных усилий, может стать доступнее для практической атаки.

Автоматизация не заменяет сопровождение

Из этого не следует, что «ИИ самостоятельно отключил интернет». Решения об остановке принимали организации. Исправления выпускали разработчики. Исследовательские результаты проверяли специалисты.

Полезно разделять автоматизацию поиска и ответственность за безопасный выпуск. Модель может ускорить анализ, но выбор между совместимостью, производительностью и изменением поведения среды требует инженерной оценки.

Почему обновление сайта не всегда обновляет PHP

Несколько независимых слоёв

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

WordPress отдельно сообщил, что специальное обновление самого WordPress для этих уязвимостей не требуется и не планируется. Исправлять необходимо PHP на сервере. [18]

Тезис 9: Своевременное обновление CMS не гарантирует актуальности среды выполнения. Ответственность за каждый слой должна быть определена отдельно.

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

Старые версии создают отдельную трудность

Исправленные поддерживаемые ветки получили версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35. PHP 8.1 и более старые ветки не получают обычных обновлений проекта. Для 7.4, 8.0 и 8.1 предоставлены минимальные исправления исходников; возможны также пакеты с перенесёнными исправлениями от поставщиков. [7]

Поэтому проверка безопасности не всегда сводится к сравнению короткого номера версии. Backport позволяет исправить старую ветку без перехода на новую основную версию. Подтверждением в таком случае служит информация поставщика о конкретном пакете.

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

Международный ответ и пределы временной защиты

Почему требовалась координация

Еврокомиссия, ENISA, CERT-EU, Europol EC3 и сеть национальных CSIRT ЕС выпустили совместное обращение. Организациям рекомендовали выявить PHP-приложения, согласовать действия с поставщиками, обновить системы и в первую очередь защитить ресурсы, доступные из интернета.

Если быстрое исправление невозможно, предлагалось рассмотреть изоляцию уязвимых приложений от публичной сети. [10]

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

Почему одной настройки недостаточно

PHP прямо предупреждает: полной защиты одними обходными настройками нет. Временные меры ограничивают отдельные пути эксплуатации, но не превращают неисправленную установку в безопасную. [7]

Тезис 11: Временная фильтрация может дать время для обновления, но должна сопровождаться сроком и ответственным за окончательное исправление.

Такая постановка вопроса помогает избежать типичной ошибки: аварийная мера остаётся навсегда, а исходный дефект перестаёт восприниматься как незавершённая работа.

Что этот инцидент меняет для владельцев цифровых сервисов

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

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

Для государственных и муниципальных сервисов особенно важна понятная коммуникация: какая услуга недоступна, что продолжает работать и где получать информацию. Формулировка «технические работы» слишком мало объясняет, когда пользователю необходимо выполнить обязательное действие в установленный срок.

Тезис 12: Устойчивость цифрового сервиса определяется не только качеством его кода, но и способностью владельца обнаружить зависимость, быстро исправить её и сохранить управляемость услуги во время инцидента.

По состоянию на 22 октября проверенные источники не дают единого мирового числа отключённых сайтов, подтверждённых компрометаций или суммарного ущерба. Не установлена и сопоставимая картина последствий для России и Подмосковья. Эти пробелы нельзя заполнять пересчётом доли PHP в условное число жертв.

Главное изменение состоит в сокращении времени на реакцию. Когда исследование и подготовка атак ускоряются, безопасное обслуживание общей программной основы становится повседневной обязанностью владельца цифровой услуги.

Краткая фактология

Определения

PHP — язык программирования и среда выполнения, широко используемые для серверной логики веб-приложений.
PHP2Shell — название группы рассматриваемых критических уязвимостей PHP.
CVE — стандартизированный идентификатор известной уязвимости.
CVSS — система оценки технической серьёзности уязвимости; оценка не является подсчётом ущерба или жертв.
RCE — удалённое выполнение кода на целевой системе.
OOM, out of memory — состояние нехватки памяти.
Use-after-free — обращение к памяти после её освобождения.
PHP-FPM — менеджер процессов PHP для обработки запросов через FastCGI.
mod_php — способ выполнения PHP в составе веб-сервера Apache.
WAF — межсетевой экран для веб-приложений, анализирующий и фильтрующий HTTP-взаимодействия.
Backport — перенос исправления в более старую ветку программного обеспечения.
Honeypot — специально подготовленная система-ловушка для наблюдения за атакующей активностью.

Основные факты

Две уязвимости: CVE-2026-109618 и CVE-2026-109619.
Серьёзность: 9,2 из 10 по CVSS 4.0, категория Critical. [9]
Риск: выполнение кода без аутентификации; исследователи также описали раскрытие памяти. [3, 5, 6]
Обновления: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35. [7]
Характер отключений: многие организации временно ограничивали доступ предупредительно.
Реальные атаки: AWS и Cloudflare сообщили о попытках эксплуатации. [16, 17]
Доля PHP: 69,3% сайтов с определённым серверным языком по данным W3Techs на 22 октября. [4]
Чего не установлено: единого мирового числа взломанных ресурсов и общего ущерба.

Хронология

2024 год: выявлены ранние признаки проблемы с нехваткой памяти. [8]
11 августа 2026 года: по ретроспективе Foundation, получены сообщения Calif и OpenAI о практической опасности общей первопричины. [8]
17 октября: датирована ранняя попытка эксплуатации, позднее выявленная AWS. [16]
20 октября: распространение сведений и предварительное предупреждение PHP. [8, 9]
21 октября: предупредительные отключения, выпуск исправлений, международные рекомендации и начало восстановления сервисов. [7, 10]
22 октября: продолжается освещение последствий и уточнение картины атак; выпуск исправлений уже состоялся.

Что нельзя смешивать

Использование PHP не равно доказанному взлому. Попытка атаки не равна успешной компрометации. Отключение сервиса не обязательно вызвано действиями атакующего. Доля технологии не является долей пострадавших сайтов.

Источники

Опубликовано: 22.10.2026 13:18:22

Категории материала:
Технологии
Экономика
Наука

Репозитории

@mosregdata

ВКонтакте