bc-csharp: Memory exhaustion via unchecked DTLS handshake fragment length
Summary
The bc-csharp .NET cryptography library allocates DTLS handshake reassembly buffers based on an attacker-controlled 24-bit length field before the peer is authenticated. A remote unauthenticated DTLS peer can send crafted handshake fragments, with a single small datagram possibly causing about 256 MB of allocation, which can exhaust process memory and crash the whole application. Only applications using DTLS (DtlsServerProtocol or DtlsClientProtocol) are affected; TLS is not.
Affected
- BouncyCastle.Cryptography / bc-csharp versions 2.6.2 and earlier
- 2.7.0-beta.98 pre-release
- The CNA record lists all versions below 2.7.0
Fixed in
- BC C# .NET 2.7.0 (BouncyCastle.Cryptography 2.7.0)
Workaround
- Set a finite handshake timeout through GetHandshakeTimeoutMillis() so memory of stalled handshakes is released
- On DTLS servers, use DtlsVerifier
- Limit the number of DTLS handshakes in progress at the same time
- These measures reduce exposure but are not a full fix; the vendor recommends upgrading
Exploitation
- CISA SSVC: exploitation none, automatable yes, technical impact partial
- No evidence of exploitation in the wild was found
- No public proof of concept was found in the searches performed
- EPSS probability 0.37% (third-party figure, may have changed)
Our recommendation
- Check whether any in-house or third-party .NET application uses BouncyCastle.Cryptography with DTLS
- Upgrade to bc-csharp 2.7.0 or later in the next regular update cycle; escalate if a DTLS endpoint is internet-facing and the upgrade is delayed
- Until the upgrade, set a finite handshake timeout and limit concurrent DTLS handshakes
- Monitor memory usage and restarts of affected applications
Public exploits
PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.
Research sources
- Vendor wiki: CVE-2026-63566 github.com
- Fix commit: bound DTLS handshake reassembly buffer github.com
- Fix commit: shared minimum helper github.com
- OSV: CVE-2026-63566 osv.dev
- BouncyCastle C# 2.7.0 release notes www.bouncycastle.org
- BouncyCastle C# download page www.bouncycastle.org
Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 1 Nov 2026, 06:15.
Original description (NVD)
Memory allocation with excessive size value in the DTLS handshake reassembly (DtlsReliableHandshake, DtlsReassembler) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated DTLS peer to cause a denial of service through memory exhaustion via crafted handshake message fragments, because the reassembly buffer for each incoming handshake message was allocated at the 24-bit length declared in the fragment header, without the check against the peer's maximum handshake message size that TLS already applied. A fragment carrying no payload can force an allocation of almost 16 MB, for each of up to 16 pending messages per handshake, before the handshake is authenticated. DTLS servers and DTLS clients are both affected; TLS is not.
Sources
The tracker combines official, freely usable data sources – updated continuously:
- NVD (NIST) – CVEs, rating (CVSS), affected products
- CISA KEV – vulnerabilities confirmed by CISA as actively exploited
- CISA Vulnrichment – CISA assessment (SSVC) in the official CVE record
- FIRST EPSS – probability of exploitation
- Microsoft MSRC – Patch Tuesday: vulnerabilities, severity, updates
- PoC-in-GitHub – public proof-of-concept repositories
- Metasploit (Rapid7) – modules of the Metasploit Framework
- Exploit-DB (OffSec) – archive of public exploits (links only)
- Patch days: official vendor pages (linked per vendor) (Vendor patch days)
This product uses data from the NVD API but is not endorsed or certified by the NVD. EPSS data © FIRST.org.
Affected? We can help.
We check whether your systems are affected, install updates and close the gap – continuously with the System Health Checker if you wish.