WordPress устранила серьёзную уязвимость в безопасности, которая давала злоумышленникам возможность выполнять произвольный код на удалённом сервере, даже без доступа к учетной записи. Об этом уже сообщалось в случаях реальных атак.
Учитывая широкую популярность платформы, WordPress неоднократно становилась объектом атак. В июле была исправлена ещё одна критическая уязвимость, позволяющая выполнять код на удалённом сервере. Компания сообщила, что данная уязвимость, идентифицированная как CVE-2026-87902, была обнаружена и сообщена разработчикам WordPress исследователем из Швейцарии, Робертом Ресслом.
В объявлении о выпуске обновления безопасности WordPress 7.1.2 говорится, что исправление устраняет проблему, при которой "неавторизованный злоумышленник, в определенных условиях, может заставить процесс разрешения шаблона страницы включать выбранный, читаемый, локальный PHP-файл вне директорий активной темы. Если соблюдены соответствующие условия для серверной среды и активной темы, это может привести к выполнению кода на удалённом сервере (RCE)."
Компания настоятельно рекомендует пользователям немедленно обновить свои сайты, подчеркнув, что исправление применимо и к версиям WordPress, старше 4.7, поскольку данная уязвимость также затрагивает многие старые версии платформы.
Ноа Кенни, ведущий консультант Digital 520, подчеркнул, что его основная тревога связана с потенциально огромными последствиями, которые может повлечь за собой эта уязвимость.
«После того, как злоумышленник получает возможность выполнять PHP-код, он может получить доступ к файлу wp-config.php, извлечь учетные данные и ключи для доступа к базе данных, создать учетные записи администраторов, изменить формы оплаты или сбора лидов, перенаправлять пользователей и установить вредоносный код», — заявил он. «Менее очевидный аспект заключается в том, как злоумышленники достигают этой цели. Файл Pearcmd.php – это стандартный инструмент управления пакетами PHP, но злоумышленники могут использовать его команды для записи произвольного содержимого на диск. В текущих атаках он используется для размещения вредоносного PHP в каталоге /tmp, а затем используется уязвимость WordPress для загрузки и выполнения этого файла. Команда безопасности, которая отслеживает только изменения в директории WordPress, может полностью пропустить этот начальный этап».
Новый риск: как ИИ меняет правила игры в IT
Аналитики 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 в тот же день, используя те же параметры, которые были предусмотрены в обновлении. Злоумышленники, таким образом, не смогли воспользоваться этой уязвимостью. Они ознакомились с описанием исправления. Публикация обновления фактически превращается в публикацию инструкции по эксплуатации, и все компании, которые продолжают использовать устаревший процесс обновления, занимающий несколько недель, работают по неэффективной схеме, которая давно устарела».
Ускорение процесса обновления безопасности
Одним из подходов к борьбе с быстро меняющимися угрозами является автоматизация установки обновлений, однако этот метод не всегда является самым эффективным. Некоторые руководители информационной безопасности крупных компаний выражают обеспокоенность из-за чрезмерной автоматизации установки патчей, стремясь тщательно проверять и утверждать любые изменения в системах, чтобы избежать подобных инцидентов, например, произошедших в Crowdstrike в 2024 году.
В интервью Рессл отметил, что еще одной проблемой автоматической установки обновлений является недостаточная проверка того, были ли обновления установлены корректно.
«Автоматическая установка обновлений не гарантирует, что патч был установлен правильно», – подчеркнул он. «Вопросы совместимости и доступности – это вполне оправданные причины для тестирования обновлений. Я рекомендую быстрое и тщательное внедрение, с обязательной проверкой во всех установленных системах, включая тестовые среды».
Махапатха добавил, что проблема с автоматизацией установки обновлений особенно актуальна для крупных компаний.
WordPress автоматически применяет небольшие обновления безопасности по умолчанию, что означает, что даже небольшие, личные блоги, скорее всего, уже защищены», – отметил эксперт. «В крупных компаниях обычно отключают автоматические обновления, чтобы контролировать изменения, поэтому организации с наиболее развитой системой управления, вероятно, все еще уязвимы на этой неделе, поскольку их собственный процесс удерживает исправление в очереди, пока злоумышленники сканируют. Система контроля изменений, которая не может отличить уязвимость, возникающую в результате неавторизованного выполнения кода, от обычной обновления плагина, защищает процесс, а не саму компанию, и именно эта уязвимость делает такое различение дорогостоящим».
И, как отметила Ниди Лютра, исполнительный советник Acceligence: «Обновление безопасности может стать практически мгновенной дорожной картой для злоумышленников, поэтому для систем, работающих в интернете, требуется оперативное реагирование в течение нескольких часов».
Заброшенные сайты WordPress могут оставаться уязвимыми из-за отсутствия обновлений
Махапатх подчеркнул, что еще одной, возможно, более серьезной проблемой является то, что многие развертывания WordPress в корпоративной среде происходят "в скрытом режиме". Они не являются типичным примером "скрытого IT", поскольку изначально были официально санкционированы, но при этом часто остаются неизвестными для IT-менеджмента.
По его словам, "риск значительно выше, чем большинство организаций предполагают, поскольку большинство компаний не считают себя "платформами WordPress", и почти все они таковыми являются. Проблема заключается в веб-активах, которые IT никогда не инвентаризировало: маркетинговые микросайты, страницы целевых кампаний, региональные сайты, страницы для инвесторов, созданные сторонними компаниями, и активы компаний, приобретенных три года назад, которые никто не удосужился перенести на более новые версии. Затронутые версии WordPress охватывают период от 4.7.0 до 7.1.1, что составляет почти десятилетие, и забытые сайты все еще работают на устаревших версиях."
Махапатх отметил, что особенно часто он сталкивается с этой проблемой в компаниях финансового сектора.
При анализе уязвимостей, который я провожу для руководителей информационной безопасности банков, я часто обнаруживаю, что WordPress-серверы, которые попадают в поле зрения, практически никогда не связаны с корпоративным сайтом», — отметил эксперт. «Как правило, это сайты, принадлежащие отделам маркетинга, дочерним компаниям или агентствам, чьи контракты уже истекли, и которые не внесены в базу данных конфигурации (CMDB), с которой работает команда безопасности».
Статья изначально была опубликована на CSOonline.
