CVE-2026-63574 in bc-csharp
Summary
by MITRE • 10/02/2026
Memory allocation with excessive size value in the OpenPGP signature and user attribute subpacket parsers (SignatureSubpacketsParser.ReadPacket, UserAttributeSubpacketsParser.ReadPacket) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote, unauthenticated attacker who can supply a crafted OpenPGP public key, certificate or signature to cause a denial of service (OutOfMemoryException or memory exhaustion in the parsing process) via a subpacket header using the five-octet length form, because the declared length was used to size the subpacket buffer with no upper bound and without being compared with the size of the enclosing subpacket area or packet, so a few bytes of input could demand an allocation of up to about 2 GB before any subpacket data was read.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in Legion of the Bouncy Castle Inc. bc-csharp library prior to version 2.7.0 represents a critical resource management flaw within its OpenPGP implementation, specifically affecting the parsing logic for signature and user attribute subpackets. The core technical deficiency lies in how the SignatureSubpacketsParser.ReadPacket and UserAttributeSubpacketsParser.ReadPacket methods handle length fields encoded using the five-octet format defined by RFC 4880. In this specific encoding scheme, a four-byte unsigned integer follows an initial header byte to indicate the packet's length, allowing for values up to approximately four gigabytes. The parser incorrectly utilizes this declared length value directly as the size parameter for buffer allocation without performing any sanity checks against the actual remaining bytes in the input stream or validating it against the bounds of the enclosing subpacket area. This lack of validation means that a malicious actor can craft an OpenPGP public key, certificate, or signature containing a subpacket header with an excessively large length field, effectively tricking the application into attempting to allocate a massive block of memory based solely on this untrusted input value rather than the actual data present in the stream.
From an operational perspective, this flaw leads directly to severe denial of service conditions characterized by OutOfMemoryException errors or complete system resource exhaustion. Because the allocation occurs before any subpacket data is actually read from the network or file stream, even a minimal amount of crafted input bytes can trigger the allocation of up to two gigabytes of memory on 32-bit systems or significantly more on 64-bit architectures depending on available virtual address space and system limits. This disproportionate response to small inputs allows an unauthenticated remote attacker to exhaust server resources efficiently with low bandwidth requirements, potentially crashing the application process or degrading performance for other users sharing the same host environment. The impact is particularly acute in services that parse OpenPGP messages as part of routine operations, such as email clients, secure messaging platforms, or key management systems, where incoming data must be processed automatically without prior user interaction to verify authenticity.
This vulnerability aligns with CWE-789: Memory Allocation with Excessive Size Value and CWE-400: Uncontrolled Resource Consumption, reflecting a failure to validate input constraints before allocating system resources. In the context of the MITRE ATT&CK framework, this behavior facilitates Denial of Service (T1499) by exhausting computational resources through inefficient resource management rather than exploiting logic flaws or code execution vulnerabilities. The attack vector is classified as remote and unauthenticated, requiring only that the attacker can supply a crafted OpenPGP packet to the vulnerable parser component. To mitigate this risk, organizations relying on bc-csharp must upgrade immediately to version 2.7.0 or later, where the parsing logic has been hardened to enforce strict upper bounds on subpacket sizes relative to the enclosing packet structure. Additionally, defensive coding practices should include implementing explicit length validation checks that compare declared lengths against available buffer space and applying global limits on memory allocation for cryptographic parsing operations to prevent single malicious inputs from monopolizing system resources.