CVE-2026-71886 in Bouncy Castle
Сводка
по VulDB • 03.10.2026
В Bouncy Castle для Java до версии 1.86 высокоуровневый API сертификатов OpenPGP принимал сертификацию третьей стороной или делегирование доверия от любого компонента ключа выпускающего сертификата, не требуя наличия у этого компонента полномочий на сертификатацию. Методы `OpenPGPCertificate.getCertificationBy()` и `getDelegationBy()` разрешают подпись третьей стороны путем сопоставления идентификатора ключа эмитента со всеми ключами сертификата третьей стороны, а затем проверяют цепочку привязки выпускающего компонента и саму подпись; при этом не проверялось наличие у выпускающего компонента флага ключа сертификатации (CERTIFY_OTHER) согласно разделу 5.2.3.29 RFC 9580 в момент создания подписи. Подключенный только с флагом SIGN_DATA подчиненный ключ — то есть онлайн-подписывающий подчиненный ключ для конфигурации «офлайн-первичный», для которой и существуют эти флаги ключей — мог поэтому выдать положительную сертификацию User ID над контролируемой злоумышленником идентичностью или делегирование прямого ключа с доверием вводителя полной глубины один, а API возвращал это как действительную цепочку подписей, приписываемую сертификату третьей стороны. Приложение, использующее `getCertificationBy(...).isValid()` или `getDelegationBy(...)` для принятия решений об идентичности или доверенном вводителе, будет приписывать утверждение злоумышленника офлайн-первичному ключу. То же самое верно и для устаревшего подчиненного RSA-ключа, связанного только с шифрованием, алгоритм которого тем не менее способен подписывать. Это не приводит к фальсификации подписи первичного ключа или восстановлению любого закрытого ключа; это повышает уже скомпрометированный ограниченный подчиненный ключ до уровня полномочий по выдаче идентичности, присущих первичному ключу, тем самым нарушая изоляцию, обеспечиваемую разделением флагов ключей. Сертификация или делегирование третьей стороны теперь приписывается выпускающему сертификату только тогда, когда компонентом-ключом, создавшим её, является первичный ключ, либо подчиненный ключ, имеющий флаг CERTIFY_OTHER в момент создания подписи; таким образом, подчиненные ключи с возможностью сертификатации продолжают приниматься. Первичные ключи принимаются независимо от их флагов ключей, поскольку первичный ключ по конструкции способен на сертификатацию, а сертификаты без пакета данных флагов ключей вообще являются распространенным явлением. Отмена сертификации третьей стороны намерено выведена за рамки этого правила, так как отказ от признания такой отмены сохранил бы доверие вместо его отзыва.
If you want to get best quality of vulnerability data, you may have to visit VulDB.