CVE-2026-63566

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.

Is your site exposed to CVE-2026-63566?

Run a free security scan — no signup, results in seconds.

EPSS — Exploit Prediction

0.0037

Probability of exploitation

0.29%

Percentile rank

EPSS estimates the probability that this vulnerability will be exploited in the wild within the next 30 days. A higher score means more likely to be exploited.

Weakness Type (CWE)

CWE-789 CWE-789

References

Other References

https://github.com/bcgit/bc-csharp/commit/212d06474166d5e85be72c2dd4898313aa5dd5f3 https://github.com/bcgit/bc-csharp/commit/99afef612458f70f28e7824a09719bfc3a169bda https://github.com/bcgit/bc-csharp/wiki/CVE-2026-63566

Frequently Asked Questions

What is CVE-2026-63566? +

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.

How do I check if I'm vulnerable to CVE-2026-63566? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

Related Vulnerabilities

CVE-2026-12185

In Bouncy Castle for Java before 1.85, BKS/UBER keystore allocates from untrusted lengths before integrity check. This issue also affects …

CVE-2026-58060

In Bouncy Castle for Java before 1.85, HSS public-key level count unbounded, enabling huge allocation on verify. This issue also …

CVE-2026-12852

In Bouncy Castle for Java before 1.85, MLS wire decoder allocates attacker-declared opaque length before bounds check.

CVE-2026-14682

In Bouncy Castle for Java before 1.85, Possible OOM from unbounded up-front allocation on a definite-length read. This issue also …

CVE-2026-19204

A client may send a WebSocket frame with an unknown opcode and a very large declared payload length, causing Jetty …

CVE-2025-26618

Erlang is a programming language and runtime system for building massively scalable soft real-time systems with requirements on high availability. …