В miniOrange SAML ошибки проверки подписи позволяют войти в WordPress как администратор

В плагине miniOrange SAML 2.0 Single Sign On для WordPress обнаружены две уязвимости с оценкой CVSS 9.8, позволяющие неаутентифицированному злоумышленнику подделать SAML-утверждение и войти в панель управления как любой существующий пользователь, в том числе администратор. Первая уязвимость, CVE-2026-61979, связана с подменой алгоритма подписи, вторая, CVE-2026-15981, - с неправильной обработкой ошибок встроенной криптографической библиотеки OpenSSL. Хотя производитель закрыл обе проблемы, значительная часть сайтов осталась без защиты: публичные бюллетени описывали только бесплатную редакцию плагина, а платные редакции исправлялись без уведомлений, из-за чего ни одна база данных уязвимостей не сигнализировала об опасности.

Детали уязвимостей

Причина первой уязвимости в том, что плагин позволяет входящему SAML-ответу самостоятельно выбирать алгоритм проверки подписи. Злоумышленник указывает алгоритм HMAC-SHA1, после чего плагин использует открытый ключ RSA как секретную часть HMAC-подписи. Открытый ключ доступен всем, поскольку хранится в метаданных поставщика учетных записей (IdP), поэтому атакующий просто забирает его, подписывает собственное SAML-утверждение и отправляет в плагин. Тот проверяет подпись и принимает её как подлинную, после чего предоставляет доступ к учетной записи. Вторая уязвимость возникает из-за функции openssl_verify, которая возвращает одно из трёх значений: единицу при корректной подписи, ноль при несовпадении и минус единицу при внутренней ошибке OpenSSL. Плагин проверял результат как булево значение, а в языке PHP минус единица считается истинной. Поэтому поврежденная подпись, вызывающая сбой в OpenSSL, воспринималась системой как валидная.

Проблема оказалась глубже, чем сами ошибки в коде. Плагин распространяется под одним идентификатором (slug) на WordPress.org, однако содержит семь независимых редакций с собственными номерами версий. Бесплатная, Premium, Standard, Enterprise, All-Inclusive и две версии VIP имеют разные линии версий, и каждая обновляется отдельно. Публичные бюллетени, которые выпускались для этого плагина, касались только бесплатной редакции, доступной для скачивания всеми желающими. В ней уязвимость была исправлена в версии 5.4.5. Платные редакции, включая Standard, исправлялись в других версиях, к примеру 17.0.5 и 17.0.6, но без публичного журнала изменений и без отдельных бюллетеней.

Это привело к тому, что базы уязвимостей, сканеры и панели управления WordPress не могли корректно определить статус платных установок. База данных хранит запись с идентификатором плагина, диапазоном уязвимых версий и версией с исправлением. Диапазон задается одним интервалом, но в данном случае номера версий разных редакций не пересекаются и растут независимо. Например, уязвимая версия 16.1.9 из Standard-редакции имеет номер больше 5.4.5, поэтому автоматические проверки считали её уже исправленной. Расширение диапазона до 17.0.5, чтобы захватить эти версии, приводило к обратной ошибке: обладатели бесплатной редакции на версии 5.4.6 или новее начинали видеть статус уязвимых, хотя уже были защищены. Единый диапазон не мог корректно описать семь параллельных линий версий.

По этой же причине администраторы уязвимых сайтов не видели уведомлений об обновлениях в консоли WordPress. Версия 17.0.6 существует, но система обновления не предлагает перескочить на неё с более старой линии 16.x. Обновление нужно загружать вручную, а сам файл плагина в панели управления отображается как актуальный. Ситуацию усугубило то, что платные редакции исправлялись без публичных оповещений, поэтому у администраторов не было ни одного сигнала о необходимости действий.

Обнаружила уязвимости команда безопасности DigitalOcean, причем сделала это благодаря многоуровневой защите инфраструктуры. В их системе отразилась попытка входа в панель управления WordPress с необычного IP-адреса, находившегося за пределами доверенной сети. Атакующий уже получил сессионную cookie администратора, но не смог выполнить операции, поскольку сами операции были ограничены доступом из доверенного диапазона. Заблокировав атаку, исследователи воспроизвели обход аутентификации на редакции Standard версии 16.1.9, нашли причины обеих ошибок на уровне кода и определили, какие платные версии затронуты. Они также опубликовали индикаторы компрометации - список IP-адресов, с которых велось сканирование уязвимых сайтов. Среди них адреса из Бельгии, Нигерии, США и Германии, преимущественно дата-центры и VPN-сервисы. Такой разброс указывает на оппортунистическое сканирование, а не на адресную кампанию: злоумышленники пытаются использовать уязвимость на всех сайтах с плагином, не разбираясь в редакциях.

Что касается исправлений, производитель закрыл уязвимости во всех редакциях. Для бесплатной версии достаточно обновиться до 5.4.5, для Standard-линии - до 17.0.6, для остальных редакций рекомендованные версии приведены в таблице, опубликованной DigitalOcean и Patchstack. Важно учитывать, что обновление, скорее всего, придется ставить вручную через загрузку файла, а не через стандартный механизм WordPress. Если обновление невозможно установить немедленно, DigitalOcean предлагает два временных и узких исправления: запретить использование алгоритма HMAC-SHA1 в SAML-подписях и ужесточить проверку результата функции openssl_verify, требуя строгого равенства единице. Эти меры блокируют эксплуатируемый путь и дают время для перехода на официальную версию, но не заменяют полноценного исправления, которое должно включать запрет на использование асимметричных ключей в HMAC-операциях и общую проверку библиотеки безопасности.

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

Детали уязвимостей

Ссылки