CVE: CVE-2026-71885
Продукт: Ubuntu
Дата публикации: 03.10.2026
Критичность: CRITICAL
CVSS: 9.2 (4.0)
EPSS: 0,19%; процентиль 7,62%
CISA KEV: нет подтверждения в каталоге CISA KEV
Краткое описание
В реализации Messaging Layer Security (MLS, RFC 9420) библиотеки Bouncy Castle for Java до версии 1.86 X.509-credential не привязывался к ключу подписи LeafNode. Участник мог быть принят в MLS-группу под X.509-идентичностью жертвы, расшифровывать последующие групповые сообщения и отправлять сообщения от её имени. В Ubuntu затронут пакет
bouncycastle в нескольких релизах, включая выпуски с поддержкой Ubuntu Pro (ESM).Основные характеристики
Суть риска: участник MLS-группы может выдать себя за другого пользователя — предъявить чужой сертификат как свой credential и подписать LeafNode посторонним ключом. Библиотека принимала такую конструкцию, поскольку не сверяла открытый ключ конечного сертификата с
signature_key.Ключевые параметры:
- Тип ошибки: нарушение привязки credential к ключу подписи; классифицируется как CWE-287 (некорректная аутентификация) и CWE-295 (некорректная проверка сертификата).
- Затронутый компонент: Bouncy Castle for Java до версии 1.86, реализация MLS (RFC 9420); в Ubuntu — пакет
bouncycastleи связанные бинарные пакетыlibbc*-java.
- CVSS v4.0: 9.2, CRITICAL, вектор
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber— сетевой вектор без привилегий и участия пользователя, но с повышенными условиями атаки (AT:P).
- Оценка Ubuntu: severity «medium» по классификации дистрибутива.
- EPSS: 0,19% (0.00188) при процентиле 0,07618 — прогнозируемая вероятность эксплуатации в течение 30 дней низкая.
- CISA KEV: подтверждений внесения в каталог нет.
- Кто не затронут: развёртывания, использующие только basic-credentials без X.509.
Какие продукты и версии затронуты
По данным Ubuntu OSV, уязвим исходный пакет
bouncycastle в следующих релизах Ubuntu (для релизов со стандартной поддержкой исправления предоставляются через Ubuntu Pro / ESM):- Ubuntu Pro 16.04 LTS (xenial):
bouncycastle1.51-4ubuntu1+esm1; бинарные пакетыlibbcmail-java,libbcpg-java,libbcpkix-java,libbcprov-java.
- Ubuntu Pro 18.04 LTS (bionic):
bouncycastle1.59-1ubuntu0.1~esm1; те же четыре бинарных пакета.
- Ubuntu Pro 20.04 LTS (focal):
bouncycastle1.61-1ubuntu0.1~esm1; те же четыре бинарных пакета.
- Ubuntu Pro 22.04 LTS (jammy):
bouncycastle1.68-5ubuntu0.1~esm1; дополнительноlibbctls-java.
- Ubuntu Pro 24.04 LTS (noble):
bouncycastle1.77-1ubuntu0.1~esm1; пакетыlibbcjmail-java,libbcmail-java,libbcpg-java,libbcpkix-java,libbcprov-java,libbctls-java,libbcutil-java.
- Ubuntu 26.04 LTS (resolute):
bouncycastle1.80-3; тот же набор из семи бинарных пакетов.
Уязвимость существует в Bouncy Castle for Java до версии 1.86. Список затронутых версий в других дистрибутивах и апстрим-продуктах в переданных данных не приведён. Официальная страница Ubuntu: ubuntu.com/security/CVE-2026-71885.
Причина уязвимости
Ошибка находится в реализации Messaging Layer Security (MLS, RFC 9420) в Bouncy Castle for Java до версии 1.86. По требованиям RFC 9420 (раздел 5.3) открытый ключ конечного сертификата X.509-credential должен совпадать с ключом подписи
signature_key в LeafNode — это связывает идентичность участника с его криптографическим материалом.В уязвимом коде метод
LeafNode.verify() проверял подпись листа только против signature_key, который сам лист и содержит. Цепочка X.509-сертификатов из credential сохранялась, но никогда не разбиралась и не проверялась: открытый ключ конечного сертификата не сверялся с signature_key.В результате подпись была корректной относительно ключа, предъявленного самим атакующим, а сертификат, удостоверяющий личность, оставался без криптографической связи с этим ключом. Проверки через
KeyPackage.verify() и путь валидации листов в Group пропускали такую конструкцию.Как работает атака
Путь данных выглядит так: участник MLS публикует KeyPackage, содержащий LeafNode с ключом подписи и credential. При присоединении нового участника или обработке внешнего коммита группа вызывает
KeyPackage.verify() и путь валидации листов в Group. Именно на этом этапе должна выполняться привязка credential к signature_key.В уязвимой версии проверка подписи замыкалась «на себя»:
LeafNode.verify() сверял подпись с ключом, который атакующий сам положил в лист. Цепочка X.509-сертификатов из credential хранилась, но не разбиралась, поэтому несоответствие между сертификатом жертвы и посторонним ключом подписи оставалось незамеченным.Итог: атакующий предъявляет сертификат жертвы как свой credential, подписывает LeafNode и охватывающий KeyPackage своим ключом — и принимается под идентичностью жертвы.
В развёртывании, допускающем внешние коммиты без независимой проверки допустимости credential, это позволяет быть принятым в группу от имени жертвы. При ресинхронизации группа сравнивает credential целиком, а не ключи подписи, поэтому жертву можно вытеснить из группы. Получив текущую эпоху, атакующий расшифровывает последующие групповые сообщения и отправляет сообщения, принимаемые как сообщения жертвы.
Условия успешной эксплуатации
Условия, следующие из описания уязвимости:
- приложение использует MLS-реализацию Bouncy Castle for Java до версии 1.86 с X.509-credentials;
- развёртывание допускает внешние коммиты (external commits) без независимой проверки допустимости credential (credential-admission check);
- атакующий располагает сертификатом жертвы, который можно предъявить как credential (сетевой вектор, без привилегий и участия пользователя, но с повышенными условиями атаки — AT:P в CVSS-векторе).
Развёртывания, использующие только basic-credentials, не затронуты. Иные условия в переданных источниках не раскрыты.
Возможный сценарий атаки
Последовательность, следующая из описания уязвимости: атакующий получает X.509-сертификат жертвы и формирует KeyPackage с LeafNode, где credential — сертификат жертвы, а подпись выполнена его собственным посторонним ключом. Поскольку
LeafNode.verify() проверяет подпись только против ключа из самого листа, а цепочка сертификатов не разбирается, проверки KeyPackage.verify() и валидация листов в Group принимают пакет под идентичностью жертвы.Далее, в развёртывании, принимающем внешние коммиты без собственной credential-admission проверки, атакующий входит в группу от имени жертвы. Механизм ресинхронизации сравнивает credential целиком, а не ключи подписи, поэтому жертву можно вытеснить из группы.
Оказавшись в группе, атакующий выводит текущую эпоху, получает возможность расшифровывать последующие групповые сообщения и отправлять сообщения, которые участники принимают как исходящие от жертвы. Это компрометация конфиденциальности и целостности коммуникаций группы, а не исполнение кода на сервере.
Есть ли публичный эксплойт
В переданных источниках нет сведений о публичном PoC, техническом разборе с готовыми инструментами или подтверждённых случаях эксплуатации. Отсутствие таких сведений не означает отсутствия эксплойта: описание уязвимости достаточно детально для самостоятельной реализации атаки квалифицированным злоумышленником. EPSS 0,19% и отсутствие записи в CISA KEV говорят о низкой наблюдаемой активности на момент подготовки материала, но не гарантируют её отсутствия.
Признаки эксплуатации
Специфичные IOC (хэши, IP-адреса, сигнатуры) в переданных источниках отсутствуют. Общие, неспецифичные точки контроля для приложений, использующих MLS на Bouncy Castle:
- внешние коммиты (external commits), принятые от участников с X.509-credentials, особенно с последующим вытеснением легитимного участника;
- события ресинхронизации группы, при которых credential участника изменился, а ключ подписи остался прежним или наоборот;
- аномалии членства: участник «повторно присоединяется» под тем же сертификатом, но с новым ключом подписи.
Эти признаки не являются подтверждёнными индикаторами именно этой уязвимости и требуют интерпретации в контексте конкретного приложения.
Как обнаружить атаку
Обнаружение строится на двух уровнях. Первый — инвентаризация: определить, используется ли в системах Ubuntu пакет
bouncycastle и какие Java-приложения с ним связаны (пакеты libbcprov-java, libbcpkix-java и другие из списка затронутых). Второй — анализ конфигурации приложения: применяется ли MLS (RFC 9420) с X.509-credentials и принимает ли приложение внешние коммиты без независимой проверки credential.Для проверки статуса поддержки и наличия обновлений на хосте используйте
ubuntu-security-status. Журналы самого MLS-приложения стоит просмотреть на предмет описанных выше неспецифичных аномалий членства. Специализированных правил обнаружения именно для CVE-2026-71885 в переданных источниках не приведено.Как проверить свою версию
Проверьте релиз Ubuntu и версию установленного пакета. Команды для безопасной проверки:
bash
cat /etc/os-release
uname -r
Код:
Затем проверьте версию пакета, подставив вместо `<имя-пакета>` конкретное имя, например `libbcprov-java`:
bash
apt-cache policy <имя-пакета>
Для проверки статуса поддержки системы (в том числе наличия Ubuntu Pro / ESM):
bash
ubuntu-security-status
Версии исправленных пакетов по релизам перечислены в разделе «Исправление». Если `apt-cache policy` показывает версию ниже исправленной или пакет не установлен из ESM-репозитория на релизах 16.04–24.04, система требует внимания.
## Исправление
Апстрим-исправление внесено в Bouncy Castle for Java 1.86: `TreeKEM.LeafNode` теперь требует, чтобы открытый ключ конечного сертификата (в сигнатурной кодировке cipher suite) совпадал с `signature_key` для X.509-credential, и отклоняет лист в противном случае — включая пустую цепочку и сертификат с несовместимым типом ключа. Проверка цепочки сертификатов и идентичности до доверенного корня, согласно RFC 9420 sec. 5.3.1, остаётся ответственностью приложения.
В Ubuntu исправленные версии пакета `bouncycastle`:
- **Ubuntu Pro 16.04 LTS:** 1.51-4ubuntu1+esm1;
- **Ubuntu Pro 18.04 LTS:** 1.59-1ubuntu0.1~esm1;
- **Ubuntu Pro 20.04 LTS:** 1.61-1ubuntu0.1~esm1;
- **Ubuntu Pro 22.04 LTS:** 1.68-5ubuntu0.1~esm1;
- **Ubuntu Pro 24.04 LTS:** 1.77-1ubuntu0.1~esm1;
- **Ubuntu 26.04 LTS:** 1.80-3.
Для релизов с Ubuntu Pro обновления доставляются через ESM-репозитории — убедитесь, что подписка активна и репозиторий подключён, после чего обновите пакет штатным менеджером пакетов. После обновления перезапустите Java-приложения, использующие библиотеку. Ссылки на исправление в апстриме: коммит `77632a57edf350a7b5751fca1a5052daffa8dab2` в репозитории bc-java и wiki-страница проекта по данному CVE.
## Временные меры защиты
Полноценной альтернативы обновлению описанные источники не предлагают. Разумные защитные меры, следующие из описания уязвимости:
- если приложение не использует MLS с X.509-credentials, риск через этот путь отсутствует — развёртывания только с basic-credentials не затронуты;
- если MLS используется, включите на уровне приложения независимую проверку допустимости credential (credential-admission check) перед приёмом внешних коммитов — именно её отсутствие делает атаку реализуемой;
- ограничьте приём внешних коммитов, если бизнес-логика это позволяет.
Эти меры являются выводом из механики ошибки, а не подтверждёнными рекомендациями вендора из переданных источников.
## Как проверить устранение уязвимости
После установки обновлений проверьте версию пакета:
bash
apt-cache policy <имя-пакета>
(вместо `<имя-пакета>` подставьте, например, `libbcprov-java`). Версия должна соответствовать исправленной для вашего релиза из раздела «Исправление» — например, `1.77-1ubuntu0.1~esm1` для Ubuntu Pro 24.04 LTS.
Дополнительно убедитесь, что ESM-репозиторий активен (`ubuntu-security-status`), и что Java-приложения, использующие Bouncy Castle, перезапущены и загружают обновлённую версию библиотеки. Функциональную проверку привязки X.509-credential к ключу подписи в вашем MLS-приложении стоит провести по его собственной документации — готовых тестов в переданных источниках нет.
## Вывод
CVE-2026-71885 — ошибка привязки идентичности в MLS-реализации Bouncy Castle for Java до 1.86: X.509-credential не связывался с ключом подписи LeafNode. Это позволяло войти в группу под чужой идентичностью, читать групповые сообщения и писать от имени жертвы.
Для администратора Ubuntu порядок действий прост: определить, используется ли `bouncycastle` и MLS с X.509-credentials, подключить ESM при необходимости и установить исправленную версию пакета для своего релиза.
Развёртывания с basic-credentials не затронуты. Приложениям после обновления по-прежнему нужно самостоятельно проверять цепочку сертификатов до доверенного корня, как того требует RFC 9420.
## Официальные источники
1. [NVD — CVE-2026-71885](https://nvd.nist.gov/vuln/detail/CVE-2026-71885)
2. [Ubuntu OSV — CVE-2026-71885](https://ubuntu.com/security/CVE-2026-71885)
3. [FIRST EPSS — CVE-2026-71885](https://api.first.org/data/v1/epss?cve=CVE-2026-71885)
## История обновлений статьи
- **06.10.2026** — Опубликована первая версия материала.
- **07.10.2026** — Уточнены сведения об уязвимых версиях, оценке риска или исправлении.
Последнее редактирование:
