CVE-2026-103603 in bc-csharp
Summary
by MITRE • 10/02/2026
Memory allocation with excessive size value in the HSS/LMS signature code (HssPublicKeyParameters, HssSignature) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated attacker who can supply both an HSS public key and a signature to cause a denial of service through memory exhaustion via a public key encoding with an excessive level count, because the level count L read when parsing an HSS public key was not checked against the RFC 8554 maximum of 8, and signature parsing then allocated an array of L - 1 entries before reading any further signature data. A single verification can commit up to about 17 GB of memory or fail with an OutOfMemoryException.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in the Legion of Bouncy Castle Inc bc-csharp library prior to version 2.7.0 represents a critical resource management flaw within the implementation of Hash-based Signature Scheme (HSS) and Lamport Signature Scheme (LMS) cryptographic primitives. Specifically, the defect resides in the parsing logic for HssPublicKeyParameters and HssSignature classes, where the system fails to validate input parameters against established cryptographic standards before allocating memory resources. This oversight allows a remote unauthenticated attacker who can supply both an HSS public key and a corresponding signature to trigger a denial of service condition through severe memory exhaustion. The core technical flaw is that when parsing an HSS public key, the level count L read from the encoded data was not checked against the maximum limit defined in RFC 8554, which restricts this value to eight levels for standard compliance and security reasons.
The operational impact of this vulnerability stems directly from how the signature verification process handles memory allocation based on the unvalidated level count. Upon receiving a maliciously crafted public key with an excessively high level count L, the subsequent parsing of the associated HSS signature attempts to allocate an array containing L minus one entries before any further validation or reading of actual signature data occurs. Because there is no upper bound check on L during this initial phase, an attacker can specify a value that forces the application to request an enormous amount of contiguous memory. In practical exploitation scenarios, a single verification operation using such a crafted input can commit approximately 17 gigabytes of system memory or result in an OutOfMemoryException crash, effectively rendering the service unavailable to legitimate users and consuming significant server resources even if it does not lead to immediate code execution.
From a classification perspective, this vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, as well as CWE-1321, specifically referring to Improperly Controlled Memory Allocation of Structures or Arrays. The attack vector is categorized under ATT&CK technique T1498, Network Denial of Service, where the adversary leverages resource exhaustion rather than traditional exploitation methods like buffer overflows to disrupt service availability. This distinction highlights that while the vulnerability does not compromise confidentiality or integrity directly in this instance, it poses a severe risk to system reliability and operational continuity by targeting the underlying infrastructure's capacity to handle cryptographic operations efficiently.
Mitigation strategies for this issue primarily involve upgrading the bc-csharp library to version 2.7.0 or later, where the developers have implemented proper validation checks to ensure that the level count L does not exceed the RFC 8554 maximum of eight before any memory allocation takes place. For organizations unable to immediately patch their dependencies, implementing input sanitization at the application layer is recommended as a temporary countermeasure. This includes validating cryptographic parameters against expected ranges and limits prior to passing them to the library functions. Additionally, deploying resource monitoring tools that can detect abnormal spikes in memory usage during signature verification processes may help identify potential exploitation attempts in real-time, allowing for automated responses such as process termination or request rejection before system stability is compromised.