Bouncy Castle C# EUVD-2026-91233

The affected application must actually use the HSS/LMS (RFC 8554 hash-based) signature verification path in bc-csharp before 2.7.0 and must accept both the HSS public key AND the signature from an untrusted source, since parsing of an attacker-supplied public key's level count L drives the oversized allocation during signature parsing. No authentication or user interaction is required (PR:N/UI:N), and default parsing is vulnerable once this code path is invoked; the principal limiting factor is that HSS/LMS is a niche post-quantum feature not exercised by most deployments, so applications that never verify HSS/LMS signatures or only process trusted keys are not exposed.

This is a genuine but bounded availability-only issue. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) with VC:N/VI:N/VA:H and a base score of 8.7 correctly characterizes it as a remote, unauthenticated, low-complexity denial-of-service with no confidentiality or integrity impact - consistent with CWE-789 (memory allocation with excessive size value) and the description, in which an unchecked HSS level count L (RFC 8554 maximum is 8) drives an allocation of L-1 entries, committing up to ~17 GB or throwing OutOfMemoryException on a single verification. The patch commit (f47ad47) confirms the root cause by adding an explicit L range check. No EPSS score, no CISA KEV listing, and no public exploit code are present in the provided data, so exploitation status is 'no public exploit identified at time of analysis'; absence of EPSS/KEV is not itself a risk-reducer but signals no evidence of active or widespread exploitation. The most important caveat the raw score hides: the high-VA rating assumes the vulnerable HSS/LMS hash-based signature code path is actually reached with attacker-controlled input, which is a comparatively niche feature of the library, so real-world exposure is much narrower than the 8.7 implies.

An application uses bc-csharp (before 2.7.0) to verify HSS/LMS hash-based signatures on untrusted input. An attacker submits a crafted HSS public key whose level count L is set far above the RFC 8554 limit of 8, together with a matching signature; signature parsing then allocates an L-1 entry array before validating further, exhausting memory and taking the process down. No public exploit code is identified at time of analysis, but the trigger is a single verification call with no authentication.