Услуги Портфолио Контакты БлогНовости +7 (800) 511‑32‑27 Обсудить проект
Безопасность

Bouncy Castle для Java 1.86 закрыла 13 CVE, включая критическую подмену личности в MLS

5 октября 2026·6 мин чтения
CVE-2026-71885Криптобиблиотеки
Bouncy Castle для Java 1.86: треснувший цифровой замок среди потоков зашифрованных данных

Коротко о главном

3 октября 2026 года в NVD появились 13 уязвимостей Bouncy Castle для Java, закрытых в версии 1.86. Самая опасная — CVE-2026-71885 (CVSS 9.2): реализация протокола MLS не сверяла X.509-сертификат участника с его ключом подписи, и атакующий мог войти в группу под чужим именем. Решение — обновиться до 1.86.

Bouncy Castle — одна из самых распространённых криптобиблиотек в мире Java: она приезжает транзитивной зависимостью в серверные фреймворки, почтовые и PKI-системы, банковские бэкенды и Android-приложения. Поэтому начинать стоит не с патча, а с инвентаризации: где библиотека есть и каких модулей это касается — эту работу удобно вести вместе с командой информационной безопасности.

Критическая CVE задевает узкий круг проектов — только тех, кто использует модуль MLS с X.509-учётными данными. Но остальные дефекты с оценками 6.9–8.7 бьют по массовым сценариям: проверке цепочек сертификатов, OpenPGP и CMS. Это уже задача владельцев сервисов и backend-разработки, а не только администраторов.

Что нашли в Bouncy Castle для Java до версии 1.86

Релиз 1.86 вышел ещё в середине сентября, и на странице проекта перечислены 13 исправленных CVE. Подробные описания и оценки CVSS стали публичными 3 октября — именно тогда записи появились в NVD и в GitHub Advisory Database. Ключевые пункты:

  • CVE-2026-71885, CVSS 9.2 — модуль MLS (RFC 9420, пакет bcmls) не привязывал X.509-учётку к ключу подписи участника. LeafNode.verify() проверял подпись ключом, который лежит в самом листе, а цепочку сертификатов сохранял, но не разбирал.
  • CVE-2026-71890, CVSS 8.7 — ещё одна ошибка MLS: при внешнем коммите не проверялось, что удаляемый участник связан с тем, кто присоединяется.
  • CVE-2026-71889, CVSS 8.7 — PKIXCertPathReviewer (обе копии класса, включая legacy) не применял ограничения имён (name constraints) к конечному сертификату цепочки.
  • CVE-2026-71888, CVSS 8.7 — потоковый парсер CMS AuthenticatedData принимал сообщения с рассогласованными полями digestAlgorithm и authAttrs.
  • CVE-2026-71886, CVE-2026-71887 и CVE-2026-85515, CVSS 8.2 — три дефекта OpenPGP: принималась сертификация от подключа без права сертифицировать, подпись подключа без перекрёстной сертификации и усечённое зашифрованное сообщение — на пути SEIPDv1 вообще без проверки целостности.
  • CVE-2026-71891 и CVE-2026-71892 — проверка публичных ключей BLS12-381 и опциональная проверка длины ключа в CMS, которая не срабатывала при выводе ключа по RFC 9709.
  • Утечки через побочные каналы — по описанию релиза, реализации постквантовых NTRU и HQC раскрывали сведения о закрытом ключе через непостоянное по времени деление и таблицы с секретными индексами.

Как работает подмена личности в MLS

MLS — стандарт IETF для группового сквозного шифрования в мессенджерах и корпоративных чатах. RFC 9420 требует, чтобы публичный ключ в сертификате участника совпадал с ключом, которым подписан его лист в дереве группы. Bouncy Castle этого не проверял.

По описанию в NVD, атакующий мог предъявить чужой сертификат, а лист и KeyPackage подписать своим ключом — и библиотека принимала его под личностью жертвы. Если сервис разрешает внешние коммиты без отдельной проверки допуска, сценарий доходит до конца: злоумышленник входит в группу под именем жертвы, вытесняет её, получает ключи текущей эпохи, читает последующие сообщения и пишет от её имени.

В версии 1.86 лист с X.509-учёткой отклоняется, если ключ сертификата не совпадает с ключом подписи, цепочка пуста или тип ключа не соответствует набору шифров. Проверка цепочки до доверенного корня по-прежнему остаётся на стороне приложения — так требует сам стандарт. Проекты, где используются только базовые (basic) учётные данные, не затронуты.

Кого это касается на практике

Критичность CVE-2026-71885 высокая, но аудитория узкая: MLS-модуль Bouncy Castle применяют в основном разработчики защищённых мессенджеров и коммуникационных платформ. Сведений об эксплуатации на 5 октября 2026 года нет, в каталог CISA KEV уязвимости не внесены.

Шире круг у остальных дефектов. Пропуск ограничений имён в PKIXCertPathReviewer важен для тех, кто валидирует клиентские сертификаты через этот класс — например, во внутренних PKI и при mTLS между сервисами. Ошибки OpenPGP касаются систем шифрования почты, подписи релизов и обмена файлами с контрагентами, а ошибки CMS — электронной подписи и защищённых сообщений S/MIME.

Отдельный риск — сторонние продукты. Bouncy Castle зашит в серверы приложений, интеграционные шины и SDK платёжных провайдеров, поэтому вслед за проектом стоит ждать бюллетеней от вендоров, которые встраивают библиотеку, и отслеживать их.

Что сделать командам разработки сейчас

Найти библиотеку. Проверьте SBOM или дерево зависимостей: артефакты org.bouncycastle:bcprov-*, bcpkix-*, bcpg-*, bcmls-*, bctls-* в Maven и Gradle. Команды mvn dependency:tree и gradle dependencies покажут и транзитивные копии. Не забудьте про контейнерные образы и толстые JAR-файлы.

Обновить все модули согласованно. Поднимите все артефакты Bouncy Castle до 1.86 одновременно: смешивать версии bcprov и bcpkix — частая причина ошибок загрузки классов. Если версию тянет фреймворк, зафиксируйте её через dependencyManagement или constraints.

Закрыть экспозицию, пока обновление в пути. Для MLS — включите на сервере собственную проверку допуска участников и запретите внешние коммиты без неё. Для PKI — проверяйте сертификаты штатным CertPathValidator, а не PKIXCertPathReviewer. Для OpenPGP — отклоняйте сообщения без MDC и не отдавайте расшифрованный текст до полной проверки целостности.

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

Часто задаваемые вопросы

Какие версии уязвимы? По данным NVD, все версии Bouncy Castle для Java до 1.86. Исправления есть только в 1.86 и новее.

Затронута ли версия для C# (.NET)? Опубликованные записи NVD описывают только Java-реализацию (BC-JAVA). О версии для .NET в этой партии CVE не сообщалось.

Мы не используем MLS — можно не обновляться? Нет. Критическая CVE касается только MLS, но дефекты в проверке цепочек сертификатов, OpenPGP и CMS с оценками до 8.7 затрагивают куда больше проектов.

Есть ли активные атаки? На 5 октября 2026 года сведений об эксплуатации нет, уязвимости не включены в каталог CISA KEV.

Источники

Bouncy Castle — New Release: Bouncy Castle Java 1.86, список исправленных CVE и изменений (первоисточник).

NIST NVD — CVE-2026-71885, опубликовано 3 октября 2026 года.

GitHub Advisory Database — GHSA-jch3-5j66-88vx (CVE-2026-71885), 3 октября 2026 года.

NIST NVD — CVE-2026-71889, опубликовано 3 октября 2026 года.

IETF RFC 9420 — The Messaging Layer Security (MLS) Protocol, раздел 5.3.

Материал подготовлен редакцией YuSMP Group по открытым источникам. Нужна экспертиза по теме или разработка под задачу — обсудим проект.

Не знаете, сколько копий Bouncy Castle живёт в ваших сервисах?

Проведём аудит кода и зависимостей: найдём все версии криптобиблиотек в репозиториях и образах, обновим их согласованно, проверим работу подписи, шифрования и mTLS после обновления.

Заказать аудит кода