CVE-2026-63566: DTLS handshake reassembler allocates buffer from unchecked 24-bit length
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.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this denial of service?
DTLS servers and DTLS clients using affected bc-csharp versions are exposed. TLS-only deployments are not affected.
Does an attacker need credentials or a completed handshake?
No. A remote unauthenticated DTLS peer can trigger the allocations before the handshake is authenticated.
How much memory pressure can a single handshake create?
A payload-free crafted fragment can request an allocation of almost 16 MB. Up to 16 pending messages per handshake can be reassembled, allowing repeated large allocations during one handshake.
What version contains the fix?
The issue affects bc-csharp versions before 2.7.0, so upgrading to 2.7.0 or later addresses the vulnerable reassembly behavior.