Две критические уязвимости miniOrange в плагине SAML 2.0 Single Sign On для WordPress уже пытаются использовать в реальных атаках, чтобы входить на сайты под учётной записью администратора. Для компаний, которые завязали вход в WordPress на Microsoft Entra ID, Okta, Google Workspace или OneLogin, история неприятная: компрометация здесь бьёт не по форме логина, а по доверенной схеме единого входа.
О происходящем сообщает BleepingComputer. Речь идёт о двух багах с идентификаторами CVE-2026-61979 и CVE-2026-15981, которые можно объединить в одну цепочку и подделать SAML-ответ так, чтобы WordPress принял злоумышленника за легитимного пользователя, включая администратора.
Сам плагин miniOrange SAML SSO превращает WordPress в SAML service provider: сайт не хранит отдельный набор логинов и паролей для пользователей, а делегирует вход корпоративному провайдеру идентификации. Это удобный сценарий для компаний, где WordPress работает как внутренний портал, маркетинговая платформа или часть клиентского кабинета. Но если в таком звене ломается проверка подписи, удобство мгновенно превращается в короткий путь к админке.
Первая проблема, CVE-2026-61979, связана с тем, что плагин принимает алгоритм подписи прямо из входящего SAML-ответа вместо того, чтобы жёстко использовать заранее настроенный. На практике это позволяет атакующему выбрать HMAC-SHA1. Дальше начинается криптографический абсурд, который не должен был попасть в прод: плагин использует открытый RSA-ключ провайдера идентификации как общий секрет. Поскольку открытый ключ по определению не секрет, злоумышленник может сгенерировать подпись, которую система сочтёт корректной.
Вторая уязвимость, CVE-2026-15981, добивает защиту сверху. Если OpenSSL возвращает ошибку проверки подписи с кодом -1, плагин трактует это как успешный результат. То есть даже некорректная или повреждённая подпись может пройти валидацию. В паре эти уязвимости miniOrange дают именно тот сценарий, который администраторы WordPress обычно считают самым неприятным: не подбор пароля, не фишинг редактора, а прямой обход аутентификации с получением доступа под высокими правами.
Где именно сломалось обновление
По данным Patchstack, обе проблемы были публично раскрыты и исправлены ещё в июле 2026 года. Но дальше началась типичная для экосистемы плагинов история про «обновление вроде есть, а патч поставили не все». Консультативное сообщение вендора, как пишет издание, касалось только бесплатной версии, хотя исправления выпустили и для шести платных редакций. В результате часть владельцев сайтов на коммерческих версиях просто не узнала, что обновление закрывает критический обход аутентификации, а не очередные косметические правки.
Исправленные версии выглядят так: Free single site — 5.4.5, Premium single site — 13.0.4, Standard single site — 17.06, Premium/Enterprise/All-Inclusive multisite — 20.2.8, Enterprise/All-Inclusive single site — 26.0.3, VIP single site — 32.0.8, VIP multisite — 35.0.7. Это важная деталь: в платных редакциях предупреждения об обновлении в панели администратора WordPress могут не появиться, поэтому владельцам сайтов нужно проверять версию вручную и обновляться без подсказок со стороны CMS.
Именно этот пробел между наличием патча и реальным внедрением, похоже, и открыл окно для атак. Patchstack приводит конкретный эпизод: 16 августа DigitalOcean заблокировал подозрительную сессию администратора WordPress, пришедшую извне доверенной сети. Разбор показал, что атакующие использовали обе уязвимости в связке против версии 16.1.9 плагина Standard edition, чтобы получить cookie административной сессии. Это уже не теоретический риск из CVE-базы, а рабочая эксплуатация в бою.
Отдельно настораживает масштаб разведки. По данным Patchstack, уже идут и попытки эксплуатации, и оппортунистическое сканирование с шести IP-адресов в Европе, Африке и США. Плюс в открытом доступе есть proof-of-concept для бесплатной версии. Обычно после публикации PoC вопрос не в том, начнут ли массово проверять интернет на уязвимые сайты, а в том, сколько часов или дней это займёт. Для WordPress-экосистемы с её привычкой откладывать ручные обновления ответ обычно не слишком оптимистичный.
Почему эта история важна не только для админов WordPress
На первый взгляд новость выглядит узкоспециальной: ещё один баг в ещё одном WordPress-плагине. Но на деле это хороший пример того, как ломается современная «корпоративная удобная безопасность». SSO-плагины часто ставят именно там, где хотят уменьшить поверхность атаки: убрать локальные пароли, завязать доступ на Entra ID или Okta, централизовать отключение сотрудников и MFA. Если же такой мост между WordPress и IdP реализован с ошибками в криптографической проверке, организация получает обратный эффект: единая точка доверия становится единым способом входа для постороннего.
Для разработчиков и DevOps-команд здесь несколько практических выводов. Во-первых, коммерческий плагин не означает лучшую прозрачность обновлений: если вендор слабо коммуницирует риск по платным версиям, патч просто не доедет до продакшена. Во-вторых, все интеграции вокруг SAML, OAuth и OpenID Connect стоит инвентаризировать так же строго, как VPN-шлюзы и IAM-конфигурации. Их часто воспринимают как «настройку логина», а не как критичную часть perimeter security. В-третьих, мониторинг аномальных административных сессий остаётся обязательным даже там, где есть SSO и много красивых диаграмм про zero trust.
Для бизнеса последствия тоже вполне прикладные. Захват админки WordPress — это не только дефейс или спам. Если сайт связан с лидогенерацией, контентом, SEO-трафиком, формами заявок, веб-аналитикой или клиентскими кабинетами, злоумышленник получает удобную точку для подмены контента, внедрения вредоносных скриптов, кражи данных и дальнейшего закрепления. В случае внутреннего портала или B2B-сайта добавляется ещё и репутационный ущерб: взлом через SSO-интеграцию выглядит куда хуже, чем банальная слабая парольная политика.
История с уязвимостями miniOrange, вероятно, быстро выйдет за пределы одного плагина и станет ещё одним аргументом в пользу более жёсткой политики вокруг сторонних модулей аутентификации. Когда инфраструктура входа зависит от WordPress-расширения, вопрос уже не в том, бесплатное оно или платное, а в том, насколько быстро вендор сообщает о риске, насколько заметно доставляет обновление и насколько честно объясняет, какие редакции затронуты. На рынке, где SSO продают как способ снизить риск, именно эта часть теперь выглядит самой уязвимой.