CVE-2026-63566
Received Received - Intake

Memory Exhaustion in Bouncy Castle DTLS Handshake

Publication date: 2026-10-02

Last updated on: 2026-10-02

Assigner: bcorg

Description
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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-10-02
Last Modified
2026-10-02
Generated
2026-10-02
AI Q&A
2026-10-02
EPSS Evaluated
N/A
NVD
CVE-2026-63566
EUVD
EUVD-2026-91217

Affected Vendors & Products

Showing 2 associated CPEs
Vendor Product Version / Range
bouncy_castle_inc bc-csharp to 2.7.0 (exc)
bouncy_castle_inc bc-csharp 2.7.0

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-789 The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability is a memory exhaustion denial-of-service (DoS) flaw in the Bouncy Castle C# library's DTLS handshake reassembly process. It occurs because the reassembly buffer size was set using an attacker-controlled 24-bit handshake message length without proper checks. Attackers can send crafted handshake fragments declaring large message sizes (up to 16 MB per message) before authentication, causing memory exhaustion. The issue affects both DTLS servers and clients using bc-csharp versions before 2.7.0.

Detection Guidance

To detect this vulnerability, monitor for abnormal memory usage spikes during DTLS handshake processes. Check for processes using bc-csharp library versions 2.6.2 or earlier. Use network traffic analysis tools to identify fragmented handshake messages with unusually large declared lengths (up to 16 MB).

Commands: netstat -tulnp | grep bc-csharp to check running services, top or htop to monitor memory usage, tcpdump -i any -w dtls_traffic.pcap 'udp port 443' to capture DTLS traffic for analysis.

Impact Analysis

If you use applications relying on Bouncy Castle C# DTLS (versions 2.6.2 or earlier), an attacker could send specially crafted handshake messages to exhaust system memory. This may lead to service crashes, degraded performance, or complete denial of service for DTLS-based services. Both clients and servers are vulnerable until patched to version 2.7.0 or later.

Mitigation Strategies

Immediately upgrade to BC C# .NET version 2.7.0 or later to apply the memory exhaustion fix. If upgrading is not possible, implement temporary mitigations like setting handshake timeouts, using DtlsVerifier on servers, or limiting concurrent DTLS handshakes.

For unpatched systems, block or rate-limit incoming DTLS traffic from untrusted sources until the library is updated.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-63566. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart