Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

Skip to content
Check your stack
CVE-2026-123612

rustls: ECH rejection can expose buffered application data to authenticated outer server before `ech_required` alert

Products / packages rustls

Published

Share

Severity and exploitation

Not in CISA KEV

KEV coverage does not rule out exploitation.

KEV checked 15/11/2026, 00:45:32 UTC
OSV · CVSS:3.1 · 2.3
Assessment vectorCVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N
OSV · CVSS:3.1 · 2.3
Assessment vectorCVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N
VulnCheck · CVSS:4.0 · 4.6
Assessment vectorCVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
VulnCheck · CVSS:3.1 · 2.3
Assessment vectorCVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N
The headline uses the highest imported catalog score. Assessments can differ by source and CVSS version.

Severity

medium4.6

CVSS measures technical severity, not the likelihood of an attack.

Known exploitation

Not listed in the checked CISA KEV catalog

Absence from CISA KEV does not rule out attacks.

Public exploit

Not established by this record

Missing evidence does not mean no public exploit exists.

Remediation

Package fixes recorded

Fix versions are recorded for 1 of 1 mapped packages. Check each release branch and any separate product guidance.

What this means

When a server rejects Encrypted Client Hello (ECH), the client completes the handshake using the outer ClientHello and authenticates the server against the ECH config's public_name. At the end of that handshake, rustls encrypted and queued any application data buffered via ClientConnection::writer() before queueing the ech_required alert.

Source excerpt · OSV

Attack conditions

That server is authenticated, so this is not exploitable by an unauthenticated party, but it violates RFC 9849 section 6.1.6, which requires the client to abort with ech_required "before sending any application data to the server".

Excerpt from the original source description below.

Review supporting sources →

Affected versions

Check the exact model, release, and any platform requirements against your installation.

rustls · VulnCheck

rustls

2 ranges

Package identity

pkg:cargo/rustlsExplore rustls →

Identity supplied by VulnCheck. Version matching requires compatible range evidence.

Compare with this publisher’s ranges. This does not inspect your installation.

affected

0.23.44 → before 0.23.46

semver versions

unaffected

0.23.46

semver versions

unknown

Other versions: unaffected

Packages

Compare each installed version with the publisher’s affected ranges. Where a fix is recorded, choose the appropriate release branch and test compatibility before upgrading.

rustls crates.io
Affected range Recorded fix
From 0.23.44 before 0.23.46Semantic versions0.23.46
From 0.24.0-dev.1 before 0.24.0-dev.2Semantic versions0.24.0-dev.2

Version evidence: OSV · GHSA-vp88-798v-h67fOSV · RUSTSEC-2026-0347

View original version evidence (0 explicit versions)

What to do

Compare your installed product and version with the affected versions above. A matching product name alone does not confirm exposure.

Use the recorded fix for your release branch. Review the publisher’s instructions and test compatibility before upgrading.

cve.new guidance unless attributed to a publisher. This page does not inspect your installation.

Public exploit evidence

No public exploit reference is identified in the imported evidence. This is not a claim that no exploit exists.

Original source description

Read the full publisher description

When a server rejects Encrypted Client Hello (ECH), the client completes the handshake using the outer ClientHello and authenticates the server against the ECH config's public_name. At the end of that handshake, rustls encrypted and queued any application data buffered via ClientConnection::writer() before queueing the ech_required alert.

The application correctly receives Error::PeerIncompatible(ServerRejectedEncryptedClientHello), but the next write_tls() call (needed to send the alert) also sends the buffered application data. Plaintext meant for the inner server therefore goes to the client-facing server named by public_name.

That server is authenticated, so this is not exploitable by an unauthenticated party, but it violates RFC 9849 section 6.1.6, which requires the client to abort with ech_required "before sending any application data to the server".

This affects only clients that:

  • use EchMode::Enable (GREASE ECH is not affected),
  • write application data before the handshake completes, and
  • connect to a server that rejects their ECH config (for example, because it is stale).

The underlying ordering bug is older, but before 0.23.44 the client checked the server certificate against the inner server name rather than public_name, so certificate verification failed first and no data was sent.

References

11 sources

Inside the record

Evidence available

Package identity
Version evidence
Remediation guidance · not supplied
Weakness classification
Additional publishers

Describes the evidence in this view, not whether the product is safe.

Original records

CVE-2026-123612

View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.

cve.new JSON →

Underlying weaknesses

The source’s classification of what caused the vulnerability.

CWE-696 ↗

Incorrect Behavior Order

VulnCheck

Related →

Environment requirements

These conditions apply together as specified by the publisher. A matching product name alone does not establish exposure.

VulnCheck · platform conditions

Any condition may hold

Vulnerable product

cpe:2.3:a:rustls_project:rustls:*:*:*:*:*:*:*:*

From (inclusive): 0.23.44

Before: 0.23.46

Applicability preview
[
  {
    "nodes": [
      {
        "operator": "OR",
        "negate": false,
        "cpeMatch": [
          {
            "vulnerable": true,
            "criteria": "cpe:2.3:a:rustls_project:rustls:*:*:*:*:*:*:*:*",
            "versionStartIncluding": "0.23.44",
            "versionEndExcluding": "0.23.46"
          }
        ]
      }
    ]
  }
]
Contributing organizations · 2
VulnCheck

Assigning organization

2026-11-08
CISA-ADP

Additional data publisher

2026-11-12

Timeline

All times UTC
  1. Advisory published

    Publication date supplied by the source.

  2. Source updated

    Latest modification date supplied by the source.

  3. Last imported by cve.new

    Latest catalog import, not the date we first saw this advisory.

What changed

Follow changes
  1. CVE · CVE-2026-123612

    Observed 2026-11-12T21:52:35.217Z · upstream updated 2026-11-12T13:40:04.848Z

    Prioritization updated

    before

    []

    after

    [
      {
        "source": "CISA-ADP",
        "type": "SSVC",
        "role": "CISA Coordinator",
        "timestamp": "2026-11-12T13:38:50.344082Z",
        "decisions": [
          {
            "name": "Exploitation",
            "value": "none"
          },
          {
            "name": "Automatable",
            "value": "no"
          },
          {
            "name": "Technical Impact",
            "value": "partial"
          }
        ]
      }
    ]

Large field values are marked as truncated previews. Original source snapshots remain retained.

Showing up to 50 most recent observed changes.