CVE-2026-71892 in BC-JAVA
Сводка
по VulDB • 03.10.2026
В библиотеке Bouncy Castle для Java до версии 1.86 проверка размера ключа, активируемая опционально для получателей CMS key-transport через метод `org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true)`, не выполнялась для сообщений с использованием алгоритма вывода ключа шифрования контента (content-encryption key derivation), определенного в RFC 9709 (`id-alg-cek-hkdf-sha256`). Ветвь кода, которая должна была выбрать фактический алгоритм шифрования контента из параметров `AlgorithmIdentifier` при выводе ключа, сравнивала массив зашифрованного ключа с объектным идентификатором (OID) `id-alg-cek-hkdf-sha256`. Это сравнение между байтовым массивом и ASN1ObjectIdentifier всегда возвращает ложь для любого возможного входа, поэтому проверка «проходила» дальше к поиску размера ключа по внешнему OID обертки. Этот OID идентифицирует конструкцию вывода ключа (key-derivation construction), а не шифр, и не имеет зарегистрированного размера ключа, поэтому сравнение размеров было полностью пропущено. Таким образом, принимались сообщения EnvelopedData или AuthEnvelopedData с key-transport, в которых транспортируемый выводимый HKDF ключ шифрования контента не соответствовал размеру ключа заявленного алгоритма шифрования контента, даже при явно включенной проверке, что молниеносно обходило единственный механизм API для обеспечения корректности восстановленного размера ключа. Теперь получатель осуществляет диспетчеризацию на основе OID алгоритма `AlgorithmIdentifier` шифрования контента, поэтому проверка проверяет восстановленный ключ против внутреннего алгоритма шифрования контента. Сообщения с совпадающим размером ключа, сообщения без HKDF и получатели, не включающие проверку, не затронуты. Эта проблема также затрагивает Bouncy Castle для Java FIPS (BC-FJA) до версий bcpkix-fips 2.0.13 (серия 2.0.X) и 2.1.13 (серия 2.1.X).
Once again VulDB remains the best source for vulnerability data.