# CVE-2026-123613: Rustls TLS 1.3 handshake message encryption level bypass

Source: https://junglewise.ai/threats/cve-2026-123613-rustls-from-0-23-13-before-0-23-45-accepts-tls-1-3-handshake  
Publisher: Junglewise Threat Intelligence, https://junglewise.ai/threats  
Published: 2026-11-08. Updated: 2026-11-08  
License: CC BY 4.0 with a link back

CVE-2026-123613 · Severity: medium · CVSS 5.3 · Published 2026-11-08

Rustls, a widely-used TLS encryption library, incorrectly accepts TLS 1.3 handshake messages that should be encrypted when they are sent in plaintext alongside other messages. An attacker positioned on the network path could send plaintext messages that the library accepts, potentially exposing details about the encrypted connection or enabling protocol manipulation.

Technologies: [Rustls](https://junglewise.ai/threats/technologies/rustls-rustls). Vendors: [Rustls](https://junglewise.ai/threats/vendors/rustls).

## Quick answers

**Is CVE-2026-123613 exploited in the wild?** No. Junglewise Threat Intelligence has no report of CVE-2026-123613 being exploited in the wild.

**How severe is CVE-2026-123613?** Medium severity, with a CVSS score of 5.3, published 8 November 2026.

**Which products and versions are affected?** Rustls 0.23.13 through 0.23.44.

**Is there a fix for CVE-2026-123613?** Yes: fixed in 0.23.45. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.

**How is CVE-2026-123613 attacked?** It is attacked over the network or from the adjacent network, in a software library.

**Am I affected by CVE-2026-123613?** Check whether you run Rustls at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

## How to fix

- Fixed in 0.23.45

## Technical details

Rustls versions 0.23.13 through 0.23.44 fail to enforce RFC 8446 record-boundary alignment during TLS 1.3 handshakes. When a key-changing message (such as ServerHello) is processed, a subsequent EncryptedExtensions message in the same record is incorrectly accepted in plaintext instead of being rejected. The vulnerability requires network-level access but does not allow transcript modification since the handshake remains authenticated.

## Affected products

- Rustls Rustls 0.23.13 through 0.23.44

## Timeline

- 2026-09-14: disclosed: GitHub advisory GHSA-2mjx-qc3c-rqvc published
- 2026-11-08: other: NVD entry published as CVE-2026-123613

## References

- [https://github.com/rustls/rustls/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7](https://github.com/rustls/rustls/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7)
- [https://github.com/rustls/rustls/security/advisories/GHSA-2mjx-qc3c-rqvc](https://github.com/rustls/rustls/security/advisories/GHSA-2mjx-qc3c-rqvc)

## Related threats

- [Rustls session Debug formatting exposes TLS secret keys](https://junglewise.ai/threats/cve-2026-123609-rustls-before-0-23-46-and-0-24-0-dev-1-before-0-24-0-dev-2)
- [Rustls client session debug formatting information disclosure](https://junglewise.ai/threats/rustls-session-debug-formatting-exposes-tls-master-secrets-and-6519d2da)
- [Rustls TLS 1.3 handshake message validation bypass across encryption levels](https://junglewise.ai/threats/rustls-tls-1-3-handshake-messages-incorrectly-accepted-across-4eccbdca)
