Bouncy Castle C# EUVD-2026-91217

The target must be using the DTLS protocol handlers (DtlsServerProtocol or DtlsClientProtocol) in bc-csharp before 2.7.0 and be reachable on its DTLS/UDP endpoint; both DTLS servers and DTLS clients are affected. No authentication, no special configuration, and no user interaction are required - the flawed allocation happens on default DTLS handshake processing before the peer is authenticated. The key LIMITING factor is that the deployment must actually use DTLS: pure TLS usage of bc-csharp is explicitly NOT affected, so consumers not exposing a DTLS endpoint are not exploitable via this flaw.

This is a genuine availability risk but not a top-tier emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, impact VA:H with VC:N/VI:N) is internally consistent and matches the description: a remote, unauthenticated DTLS peer can trigger memory exhaustion with low complexity and no user interaction, but there is NO confidentiality or integrity impact - purely denial of service. The vendor-assigned 8.7 (CVSS 4.0 'High') is defensible because exploitation occurs before the handshake is authenticated and amplification is significant (~16 MB per message × up to 16 pending messages ≈ 256 MB per handshake from tiny, empty-payload fragments). Tempering signals: no EPSS score is provided, this is NOT in CISA KEV, and no public POC is referenced, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The real-world blast radius is also constrained because only DTLS deployments are affected - TLS is explicitly not - so the exposure is limited to the subset of bc-csharp consumers that actually use DtlsServerProtocol/DtlsClientProtocol. Net: a real priority for anyone running bc-csharp DTLS on exposed UDP endpoints (where low-effort amplification DoS is attractive), but lower urgency for the much larger population using only TLS.

An attacker who can reach a bc-csharp (<2.7.0) DTLS server or client on its UDP port initiates a handshake and sends crafted handshake-message fragments whose 24-bit length header declares a near-maximum size (~16 MB) while carrying little or no payload. Because the reassembly buffer is allocated at the declared length before any signature/Finished verification, each of up to 16 pending messages forces a large allocation, exhausting memory and denying service. No public exploit is identified at time of analysis, but the technique is simple and the attack is unauthenticated.