Bouncy Castle Java CVE-2026-59647

The vulnerable code path is triggered only when a server verifies an incoming CMP message protected with a passwordBasedMac (ProtectedPKIMessage.verify(PBEMacCalculatorProvider, char[]) call path through PKMACBuilder). Applications must be actively processing inbound CMP messages from untrusted or network-accessible sources for the attack to apply. PKMACBuilder instances constructed with an explicit maxIterations ceiling (via the constructor overload) are not vulnerable regardless of library version. Applications using Bouncy Castle exclusively for non-CMP operations (TLS, S/MIME, PGP, JCE provider usage) are not exposed. No authentication is required - the PBMParameter field containing the malicious iterationCount is in the unauthenticated portion of the CMP message, consumed before any MAC verification. Exploitation is further limited to network paths that can reach the CMP service; the CVSS 4.0 vector confirms AC:L/AT:N, meaning no race condition or special timing is required.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms remote, unauthenticated exploitation with low attack complexity and no prerequisites - an ideal profile for automated abuse. The official scoring rates vulnerable-system availability at VA:L, which appears conservative given the commit documentation describes an attacker driving the verifying system into 'billions of hash iterations,' which in practice would block request-handling threads and could render the CMP endpoint completely unresponsive under sustained attack. An independent assessment of A:H is arguable for any multi-threaded server without connection-level rate limiting. No EPSS score is available in the provided data. The vulnerability is not listed in CISA KEV and no public proof-of-concept exploit has been identified, reducing urgent remediation pressure. However, the attack primitive is trivially constructable - a crafted CMP message with an oversized iterationCount field requires no cryptographic knowledge to weaponize. The primary limiting factor is deployment context: only systems that receive and verify passwordBasedMac-protected CMP messages are exposed; Java applications using Bouncy Castle solely for TLS, S/MIME, or PGP are unaffected.

An attacker targeting a Java application that exposes a CMP endpoint - such as a private certificate authority, SCEP gateway, or EST server built on Bouncy Castle - crafts a CMP message with a passwordBasedMac ProtectionAlgorithm whose PBMParameter iterationCount is set to a value near 2,147,483,647 (2^31-1). When the server calls ProtectedPKIMessage.verify(PBEMacCalculatorProvider, char[]), the unpatched PKMACBuilder enters an iterated hash loop executing billions of iterations per message, consuming 100% of a CPU core for the duration. Submitting a stream of such messages from a single client can saturate all available threads, causing a complete denial of service for legitimate CMP clients. No public proof-of-concept exploit has been identified, but the crafted message requires no cryptographic secrets - only knowledge of CMP message structure.