WordPress устраняет критическую уязвимость безопасности

WordPress устранила критическую уязвимость безопасности, которая позволяла неаутентифицированному злоумышленнику выполнять произвольный удаленный код (RCE). Уже зафиксированы случаи атак в реальных условиях.

Учитывая свою популярность, WordPress часто подвергается атакам. В июле была устранена еще одна уязвимость максимальной степени опасности, позволявшая RCE. По данным WordPress, текущая уязвимость, отслеживаемая как CVE-2026-87902, была обнаружена и сообщена компании исследователем безопасности из Швейцарии Робертом Ресслом.

В сообщении о выпуске обновления безопасности WordPress 7.1.2 говорится, что исправление устранило проблему, при которой «неаутентифицированный злоумышленник при определенных условиях может заставить разрешение шаблона страницы включать выбранный локальный PHP-файл, доступный для чтения, за пределами каталогов активной темы. Если соблюдены соответствующие предварительные условия как для серверной среды, так и для активной темы, это может привести к выполнению произвольного удаленного кода (RCE)».

Пользователям настоятельно рекомендовано немедленно обновить свои сайты. Указано, что исправление было обратнопортировано до версии 4.7, поскольку уязвимость затрагивает и многие старые версии WordPress.

Ноа Кенни, ведущий консультант Digital 520, отметил, что его главной заботой является масштаб ущерба, который злоумышленник может нанести с помощью этой уязвимости.

«Как только злоумышленники получают возможность выполнять PHP-код, они могут читать wp-config.php, получать учетные данные базы данных и ключи аутентификации, создавать учетные записи администраторов, изменять формы оплаты или сбора лидов, перенаправлять посетителей и устанавливать постоянный код», — сказал он. «Менее очевидная часть — как они туда попадают. Pearcmd.php — это легитимный инструмент управления пакетами PHP, но злоумышленники могут злоупотреблять его командами конфигурации для записи выбранного контента на диск. Текущие атаки используют его для размещения вредоносного PHP в /tmp, а затем используют уязвимость WordPress для загрузки и выполнения этого файла. Команда безопасности, отслеживающая изменения только в каталоге WordPress, может полностью пропустить этот первый этап».

Новая реальность рисков

Однако IDC и другие эксперты считают скорость начала атак наиболее тревожным элементом этого отчета.

«Эта уязвимость WordPress — классический пример новой реальности рисков: злоумышленники эксплуатируют критические ошибки в течение нескольких часов после их раскрытия, а большинство предприятий не успевают достаточно быстро устанавливать исправления», — заявил директор по исследованиям IDC Филипп Харрис, ссылаясь на отчеты компании Patchstack о том, что злоумышленники воспользовались уязвимостью вскоре после того, как WordPress опубликовала исправление.

Patchstack сообщила: «Когда эта публикация только появилась, все запросы, которые мы видели, были связаны с разведкой в отношении безвредных основных файлов. Теперь это не так. Злоумышленники включают pearcmd.php и используют его для записи PHP-файлов на диск, а инструменты для публичного сканирования этой CVE уже циркулируют».

Харрис из IDC отметил, что телеметрия Patchstack иллюстрирует новую реальность: разведка злоумышленников происходит в течение пяти часов после выпуска исправления, а полная эксплуатация — примерно в течение дня. «Окно между раскрытием и эксплуатацией сжалось до такой степени, что среднее время эксплуатации критических уязвимостей в некоторых случаях стало отрицательным, означая, что эксплойт появляется до или сразу после выпуска исправления», — сказал он. «Эта ошибка WordPress точно соответствует этой схеме: Patchstack зафиксировала первый трафик сканирования менее чем через пять часов после выпуска WordPress 7.1.2, а объем трафика увеличился примерно в десять раз в течение дня, поскольку злоумышленники перешли от сканирования к фактической доставке полезной нагрузки».

Аман Махапатра, директор по стратегии нью-йоркской технологической консалтинговой фирмы Tribeca Softech, согласился.

«Число, которое должно стать якорем этой истории, — это не оценка CVSS 9.2, а разрыв между исправлением и эксплойтом. С этой уязвимостью этот разрыв был фактически нулевым», — сказал он. «WordPress выпустила 7.1.2 22 сентября, а Patchstack заблокировала первую попытку эксплуатации в 11:49 UTC в тот же день, используя полезные нагрузки, которые соответствовали точному кодированию, которое исправление было призвано исправить. Злоумышленники не обнаружили эту ошибку. Они прочитали исправление. Публикация исправления теперь фактически является публикацией руководства по эксплуатации, и любое предприятие, все еще использующее цикл устранения неполадок, измеряемый неделями, работает по графику, который давно устарел».

Требуется более быстрое исправление

Одним из ответов на скорость действий злоумышленников является автоматизация обновлений, но это не обязательно лучший вариант. Некоторые CISO предприятий нервничают из-за чрезмерной автоматизации исправлений; они хотят проверять и утверждать любые изменения системы, в основном чтобы избежать таких катастроф, как инцидент с Crowdstrike в 2024 году.

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

«Наличие автоматических обновлений не означает, что исправление установлено», — сказал он. «Проблемы совместимости и доступности являются законными причинами для тестирования обновлений. Моя рекомендация — быстрое, протестированное развертывание с проверкой на всех доступных установках, включая промежуточные сайты».

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

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

И, как отметил Нидхи Лутра, исполнительный советник Acceligence: «Релиз безопасности может почти мгновенно стать дорожной картой для злоумышленника, поэтому экстренное исправление для систем, доступных из Интернета, требует реакции в течение нескольких часов».

Забытые сайты WordPress могут остаться без исправлений

Махапатра добавил, что еще одна, возможно, более серьезная проблема заключается в том, что многие корпоративные развертывания WordPress происходят незаметно. Это не типичное теневое ИТ, поскольку они полностью авторизованы в момент создания, но они часто остаются неизвестными ИТ-руководству.

В предприятиях, сказал он, «уровень воздействия значительно выше, чем предполагает большинство организаций, потому что большинство предприятий не считают себя «WordPress-магазинами», хотя почти все они ими являются. Риск заключается в веб-среде, которую ИТ никогда не инвентаризировали: маркетинговые микросайты, целевые страницы кампаний, региональные сайты стран, страницы для инвесторов, созданные внешним агентством, и ресурсы компаний, приобретенных три года назад, которые никто не удосужился мигрировать. Затронутый диапазон [версий WordPress] простирается от 4.7.0 до 7.1.1, почти десятилетие установок, и забытые сайты — это именно те, которые все еще работают на старых ветках».

Махапатра сказал, что он особенно видел это на предприятиях в финансовом секторе.

«Когда я провожу обзоры внешних поверхностей атаки с CISO банков, экземпляры WordPress, которые всплывают, почти никогда не являются корпоративным сайтом», — сказал он. «Это сайты, принадлежащие маркетингу, дочерней компании или агентству, чей контракт истек, и ни один из них не отображается в CMDB, против которого команда безопасности устанавливает исправления».