CVE-2026-123613ModerateNetworkRevised 13 Nov

Rustls 0.23.13 before 0.23.45 TLS 1.3 Handshake Encryption Level Bypass

No KEV listing collectedCVSS 5.3Fix not stated

MSRC advisory NVD CVE.org

Assessment

Severity: Moderate
CVSS base score: 5.3
Impact: Not stated
Exploitation detected: Unknown: not stated by MSRC
Exploitability: Not assessed
Publicly disclosed: Unknown: not stated by MSRC
EPSS · 30-day forecast: No EPSS score collected
Customer action: Required: follow the MSRC remediation guidance

More details

CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Public detection template: No Nuclei template is listed in the current collected catalog
Component: Mariner
Weakness: CWE-20: Improper Input Validation
Issued by: VulnCheck
Published: 11 Nov 2026 · November 2026
Last revised: 13 Nov 2026Information published.

CVSS 3.1 base metricsRed raises the risk · green lowers it

Attack vector: NetworkAV:N
Attack complexity: LowAC:L
Privileges required: NonePR:N
User interaction: NoneUI:N
Scope: UnchangedS:U
Confidentiality: LowC:L
Integrity: NoneI:N
Availability: NoneA:N

Updates that fix it

0 KBs

No KB listed

No KB update is listed in the collected MSRC record. Check the MSRC advisory for product releases and other remedies.

Affected products

Open Source Software

7 affected products

azl3 kata-containers 4.1.0.kata1-2 on Azure Linux 3.0
azl3 kata-containers 4.1.0.kata2-1 on Azure Linux 3.0
azl3 kata-containers-cc 3.15.0.aks0-23 on Azure Linux 3.0
azl3 kata-containers-cc 3.15.0.aks0-24 on Azure Linux 3.0
azl3 rust 1.75.0-31 on Azure Linux 3.0
azl3 rust 1.98.1-1 on Azure Linux 3.0
azl3 rust-afterburn 5.8.2-2 on Azure Linux 3.0

What changed

Affected products: azl3 kata-containers 4.1.0.kata1-2 on Azure Linux 3.0, azl3 kata-containers-cc 3.15.0.aks0-23 on Azure Linux 3.0, azl3 rust 1.75.0-31 on Azure Linux 3.0, azl3 rust 1.98.1-1 on Azure Linux 3.0, azl3 rust-afterburn 5.8.2-2 on Azure Linux 3.0 → azl3 kata-containers 4.1.0.kata1-2 on Azure Linux 3.0, azl3 kata-containers 4.1.0.kata2-1 on Azure Linux 3.0, azl3 kata-containers-cc 3.15.0.aks0-23 on Azure Linux 3.0, azl3 kata-containers-cc 3.15.0.aks0-24 on Azure Linux 3.0, azl3 rust 1.75.0-31 on Azure Linux 3.0, azl3 rust 1.98.1-1 on Azure Linux 3.0, azl3 rust-afterburn 5.8.2-2 on Azure Linux 3.0
14 Nov 2026
Detection template: Unknown: detection-template evidence is incomplete or retained → No Nuclei template listed
13 Nov 2026 · 12:10:20 UTC
Detection template: No Nuclei template listed → Unknown: detection-template evidence is incomplete or retained
13 Nov 2026 · 11:07:20 UTC

Page history

Changes are dated when recorded; day views use the last saved version from that UTC day, and citations stay fixed.

Cite this version

Field-level log (10)

Up to 100 recent field edits are shown; older edits may be outside retention.

14 Nov 2026 · 08:16:23 UTC Last revised12 Nov 2026 01:48 UTC → 13 Nov 2026 14:46 UTC
14 Nov 2026 · 08:16:23 UTC Affected productsazl3 kata-containers 4.1.0.kata1-2 on Azure Linux 3.0, azl3 kata-containers-cc 3.15.0.aks0-23 on Azure Linux 3.0, azl3 rust 1.75.0-31 on Azure Linux 3.0, azl3 rust 1.98.1-1 on Azure Linux 3.0, azl3 rust-afterburn 5.8.2-2 on Azure Linux 3.0 → azl3 kata-containers 4.1.0.kata1-2 on Azure Linux 3.0, azl3 kata-containers 4.1.0.kata2-1 on Azure Linux 3.0, azl3 kata-containers-cc 3.15.0.aks0-23 on Azure Linux 3.0, azl3 kata-containers-cc 3.15.0.aks0-24 on Azure Linux 3.0, azl3 rust 1.75.0-31 on Azure Linux 3.0, azl3 rust 1.98.1-1 on Azure Linux 3.0, azl3 rust-afterburn 5.8.2-2 on Azure Linux 3.0
13 Nov 2026 · 12:10:20 UTC Public detection templateUnknown: detection-template evidence is incomplete or retained → No Nuclei template listed
13 Nov 2026 · 12:10:20 UTC Source coverage: public-exploit-codeIncomplete → Current
13 Nov 2026 · 12:10:20 UTC Source coverage: first-epssIncomplete → Current
13 Nov 2026 · 12:10:20 UTC Source coverage: msrc-cvrfIncomplete → Current
13 Nov 2026 · 11:07:20 UTC Public detection templateNo Nuclei template listed → Unknown: detection-template evidence is incomplete or retained
13 Nov 2026 · 11:07:20 UTC Source coverage: public-exploit-codeCurrent → Incomplete
13 Nov 2026 · 11:07:20 UTC Source coverage: first-epssCurrent → Incomplete
13 Nov 2026 · 11:07:20 UTC Source coverage: msrc-cvrfCurrent → Incomplete

Explore global source statements, affected packages and advisory history for CVE-2026-123613. The catalog has a separate collection scope from Microsoft release records.

More advisories, affected versions and source history

Exploitation and risk

Source status

CISA KEV lists vulnerabilities known to be exploited. FIRST EPSS estimates the likelihood of exploitation in the next 30 days. An unavailable score does not mean zero risk.

Which CVEs have scores here?

This view includes predictions for CVE identifiers explicitly listed in public NuGet advisories. Microsoft release pages have their own prediction coverage. Check source status for the scope and latest checks.

No exploitation or prediction data is available here for these CVEs. This does not mean they are safe or unlikely to be exploited.

cve-program · CVE-2026-123613

Published

Rustls 0.23.13 before 0.23.45 TLS 1.3 Handshake Encryption Level Bypass

Rustls from 0.23.13 before 0.23.45 accepts TLS 1.3 handshake messages at the wrong encryption level when they follow a key-changing message in the same record, because Deframer::aligned does not enforce RFC 8446 record-boundary alignment. A peer or on-path attacker can pack a plaintext EncryptedExtensions with the ServerHello, which rustls accepts unencrypted.

Source published: 8 Nov 2026 01:38:37 UTC
Source modified: 10 Nov 2026 17:56:44 UTC
Saved here: 10 Nov 2026 19:21:22 UTC
Source terms: CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

Source: cve-program · CVE Program Terms of Use. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS 4.0 · 6.9 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

CVSS 3.1 · 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

euvd · EUVD-2026-119372

Published

Rustls from 0.23.13 before 0.23.45 accepts TLS 1.3 handshake messages at the wrong encryption level when they follow a key-changing message in the same record, because Deframer::aligned does not enforce RFC 8446 record-boundary alignment. A…

Additional publisher context

EUVD source date text has no stated timezone and is retained without inventing a UTC instant. Related bulletin membership is not an alias, common cause or applicability claim. A missing vector with a zero score is treated as unrated. Complete vendor/product and underlying source evidence remains in the original JSON.

Original publisher date fields

datePublished: Nov 8, 2026, 1:38:37 AM

dateUpdated: Nov 10, 2026, 5:56:44 PM

1 related source bulletins · separate from aliases

msrc_CVE-2026-123613: Rustls 0.23.13 before 0.23.45 TLS 1.3 Handshake Encryption Level Bypass

CVE-2026-123613

Source published: Nov 8, 2026, 1:38:37 AM (timezone not stated)
Source modified: Nov 10, 2026, 5:56:44 PM (timezone not stated)
Saved here: 14 Nov 2026 11:58:47 UTC
Source terms: ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

Source: euvd · ENISA EUVD · source terms and attribution apply. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

EUVD CVSS 4.0 · 6.9 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

nvd · CVE-2026-123613

Published

Rustls from 0.23.13 before 0.23.45 accepts TLS 1.3 handshake messages at the wrong encryption level when they follow a key-changing message in the same record, because Deframer::aligned does not enforce RFC 8446 record-boundary alignment. A…

Additional publisher context

NVD analysis and CPE criteria are source context, not proof that a package or your environment is affected. Complete affected data, logical configurations and SSVC are retained in the original JSON.

Source analysis status: Awaiting Analysis

Weakness classifications: CWE-20

Original publisher date fields

published: 2026-11-08T02:16:56.780

lastModified: 2026-11-12T20:28:31.817

Source published: 8 Nov 2026 02:16:56 UTC
Source modified: 12 Nov 2026 20:28:31 UTC
Saved here: 14 Nov 2026 12:57:57 UTC
Source terms: NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

Source: nvd · NIST NVD usage terms; underlying source attribution retained. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS 4.0 · [email protected] · Secondary · 6.9 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

CVSS 3.1 · [email protected] · Secondary · 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

osv · GHSA-2mjx-qc3c-rqvc

Published

Rustls: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries

Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level when they followed a key-changing message in the same record. The handshake transcript is still authenticated, so a network-position attacker cannot use this to alter or complete a handshake; the practical effect is that a peer could send handshake messages that should be encrypted in plaintext without rustls rejecting the connection. This issue affects rustls versions 0.23.13 through 0.23.44 inclusive. # Original report ### Summary Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello. This is very similar to Go's CVE-2025-61730 fixed in https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7 ### Details It appears `Deframer::aligned` considers itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer. This is insufficient per RFC 8446 section 5.1's > Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary. ### Impact An on path attacker can inject plaintext messages that are accepted. ### Tool Use Disclosure This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.

Source published: 5 Oct 2026 23:30:17 UTC
Source modified: 8 Nov 2026 10:55:54 UTC
Saved here: 8 Nov 2026 11:07:08 UTC
Source terms: GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

Source: osv · GitHub Advisory Database · CC-BY-4.0. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Publisher rating · MODERATE

osv · RUSTSEC-2026-0285

Published

TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries

Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level when they followed a key-changing message in the same record. For example, a plaintext `EncryptedExtensions` message packed into the same record as the `ServerHello` was accepted. RFC 8446 section 5.1 requires that handshake messages do not span key changes, and that implementations terminate the connection with an "unexpected_message" alert if they do. The handshake transcript is still authenticated, so a network-position attacker cannot use this to alter or complete a handshake; the practical effect is that a peer could send handshake messages that should be encrypted in plaintext without rustls rejecting the connection. This is functionally the same bug as Go's [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).

Source published: 14 Sep 2026 12:00:00 UTC
Source modified: 9 Nov 2026 09:21:20 UTC
Saved here: 9 Nov 2026 10:04:30 UTC
Source terms: OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

Source: osv · OSV · upstream source license applies. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N