Overview of CVE-2026-62903: Microsoft.Data.SqlClient Enclave Key Binding Gap Enables Capture Replay Information Disclosure

Introduction

Always Encrypted with secure enclaves rests on one guarantee: column encryption keys only ever reach a genuine, attested enclave inside SQL Server. CVE-2026-62903 weakened that guarantee in the .NET driver. A network attacker positioned between an application and its database could replay a legitimate signed enclave report with their own public key attached and potentially receive the keys that protect sensitive columns.

Microsoft published the advisory on November 10, 2026 as the "Microsoft.Data.SqlClient Information Disclosure Vulnerability." NVD lists a CVSS 3.1 base score of 7.4 (High), and Microsoft assigns its own severity category of Important. The two come from different rating systems and do not conflict. Although the CVE description mentions SQL Server, the affected products are the Microsoft.Data.SqlClient release families 6.1, 7.0 and 7.1, the .NET data provider applications use to reach SQL Server and Azure SQL. This post summarizes the advisory, the code change we believe is the fix, and the versions to look for.

Technical information

Weakness class and prerequisite

MITRE classifies the weakness as CWE-294, Authentication Bypass by Capture Replay. An attacker captures valid messages and resends them, sometimes with small changes, so the recipient accepts an operation without the intended authentication guarantee. Microsoft's advisory narrows the prerequisite considerably. The attacker must insert themselves into the logical network path between the target and the requested resource, a machine-in-the-middle position that allows reading or modifying communications. Reaching a listening server is not enough.

The published base vector:

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

• AC:H: exploitation is not a straightforward remote request. The interception position is a real constraint.
• PR:N / UI:N: the scoring model requires no database account and no user action, so "authentication bypass" here does not imply a stolen login.
• C:H / I:H / A:N: the score includes integrity impact even though the FAQ focuses on disclosure. We do not extrapolate that into a database modification or code execution scenario, because the sources do not describe one.

How the enclave session is established

Always Encrypted with secure enclaves using VBS/HGS attestation follows this handshake:

1. SQL Server sends the client a health report, a signed enclave report, the enclave's public key (info.Identity) and Diffie-Hellman info.
2. The client checks the attestation and the report signature.
3. The client derives a shared secret from the enclave public key and its own ECDH key.
4. Column encryption keys are later sent to the enclave over a channel protected by that secret.

Root cause

Microsoft has not named a commit for this CVE. The advisory FAQ says a successful attacker "could obtain the encryption keys that protect data secured by Always Encrypted with secure enclaves," and only one fix in the 6.1.7 and 7.0.3 release notes matches that description: "Enhance VSM/HGS enclave session key binding validation" (dotnet/SqlClient PR #4532). This mapping is our inference from the FAQ and release notes. Microsoft has not confirmed it.

In the unpatched driver, step 2 confirmed that the enclave report was genuine and signed, but nothing confirmed that the public key used in step 3 was the key that report vouched for. The report and the key traveled together, yet the client treated them as independent. A genuine VBS enclave writes the SHA256 hash of its public key into the first 32 bytes of the report's EnclaveData, and the report signature covers that field. The old HGS code path never compared the two. According to the patch's code comments, the Azure Attestation (AAS) path already performed this key binding, which makes the HGS path the gap.

Attack flow

Based on the handshake above and the advisory's description, the attack proceeds as follows:

1. The attacker gains a machine-in-the-middle position on the logical network path between a .NET application using an affected driver and SQL Server.
2. The attacker obtains a valid, signed enclave report produced by a real enclave. This is the capture half of CWE-294.
3. When the victim client sets up an enclave session, the attacker forwards the genuine health report and signed enclave report but substitutes its own public key for the enclave's.
4. The client's attestation and signature checks succeed, because the report itself is authentic.
5. The client derives the session secret from the attacker-supplied key, so it agrees a secret with the attacker instead of the enclave.
6. Column encryption keys subsequently sent "to the enclave" are protected by a secret the attacker holds. Per Microsoft's FAQ, access to those keys could expose plaintext from protected database columns.

The advisory does not publish a packet format, a reproducible exploit sequence, or the exact replayed message, and it does not describe every condition required for the scenario to succeed. The flow above reflects the documented handshake and the fix, not a reconstructed exploit.

Exploitation status

At publication Microsoft recorded "Publicly disclosed: No", "Exploited: No" and "Exploitation Less Likely". The temporal vector is:

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N/E:P/RL:O/RC:C

E:P denotes proof-of-concept maturity, RL:O an official fix, and RC:C confirmed report confidence. Proof-of-concept maturity and no reported exploitation can coexist. The first describes exploit development, the second observed attacks. The available material associates no threat actor, campaign, or indicator set with this CVE. Microsoft credits William Conlon for the report.

Patch information

Driver packages

Microsoft's advisory lists Remediation Level "Official Fix" and points to three NuGet builds of Microsoft.Data.SqlClient. Any build below the listed version on the matching line is affected.

• 6.1.7 (LTS line)
• 7.0.3
• 7.1.0-preview3 (NuGet build 7.1.0-preview3.26238.4, a prerelease)

The driver packages were published to NuGet on September 10, 2026, two months before the CVE was disclosed on November 10, 2026. The GitHub release entry for 6.1.7 does not name this CVE, so do not treat the package dates as November patch dates.

If an application references Microsoft.Data.SqlClient.Extensions.Azure, the official changelog states that upgrading the driver to 7.1.0-preview3 also requires upgrading that companion package to 7.1.0-preview3. That is compatibility guidance rather than a separate security fix.

SQL Server updates in the same advisory

The advisory also covers November 10, 2026 SQL Server security updates, selected by your current build number:

• SQL Server 2025: KB5129299, KB5132748
• SQL Server 2022: KB5129300, KB5132747
• SQL Server 2019: KB5132745, KB5132751
• SQL Server 2017: KB5132746, KB5132749

The available material does not establish that applying only an engine update remediates client applications, so driver updates remain a distinct task.

The code change

The fix we mapped to this CVE is commit ee6fabd, merged to main under the 7.1.0-preview3 milestone and cherry-picked to release/6.1 as PR #4552 and to release/7.0 as PR #4553. It inserts a check in VirtualSecureModeEnclaveProviderBase.cs immediately after attestation and before the shared secret is derived:

                         VerifyAttestationInfo(enclaveSessionParameters.AttestationUrl, info.HealthReport, info.EnclaveReportPackage);
 
+                        // Verify the enclave public key is bound to the signed report, before it is used for key exchange
+                        VerifyEnclavePublicKeyBinding(info.EnclaveReportPackage, info.Identity);
+
                         // Set up shared secret and validate signature
                         byte[] sharedSecret = GetSharedSecret(info.Identity, info.EnclaveDHInfo, clientDHKey);

The new VerifyEnclavePublicKeyBinding method first rejects missing or malformed inputs:

byte[] reportData = enclaveReportPackage?.Report?.EnclaveData;
byte[] publicKey = enclavePublicKey?.PublicKey;

if (reportData == null || reportData.Length < ReportDataLength || publicKey == null || publicKey.Length == 0)
{
    throw new ArgumentException(Strings.VerifyEnclaveKeyBindingFailed);
}

It then computes the SHA256 hash of publicKey and compares it with the first 32 bytes of reportData:

• On .NET, the comparison uses CryptographicOperations.FixedTimeEquals.
• On .NET Framework, where that API does not exist, the patch adds its own constant-time comparison:

int accumulator = 0;
for (int index = 0; index < length; index++)
{
    accumulator |= left[index] ^ right[index];
}

return accumulator == 0;

The constant-time comparison prevents timing from revealing how many leading bytes matched. If the key is missing, the data is malformed, or the hashes differ, the driver throws a new localized VerifyEnclaveKeyBindingFailed error and stops before any secret is derived. A substituted key can no longer ride on a replayed report.

Tests

The commit adds 197 lines and removes 1, including a new VirtualSecureModeEnclaveProviderTest.cs. GenuineKey_Succeeds checks that a matching key is accepted. SwappedKey_Throws builds a report committing to one key, offers a different key, and expects the binding failure exception, which models the attack described above.

Related hardening in 6.1.7 and 7.0.3

These changes are not tied to this CVE but are relevant in machine-in-the-middle scenarios:

• ServerCertificate pinning on managed SNI (#4445, #4583, #4584; .NET 8 and 9 only): the driver now compares the configured certificate even when chain validation passes. A missing or mismatched certificate fails the TLS handshake.
• AccessTokenCallback behavior (#4520, #4560, #4561): it now follows the same certificate validation and Transparent Network IP Resolution (TNIR) defaults as AccessToken.
• SNI dependencies updated to 6.0.3.

For context, MITRE's general CWE-294 guidance recommends incorporating sequence or timestamp data into an integrity check and signing it cryptographically. Microsoft does not present such design measures as a substitute for the listed updates, and no configuration workaround is documented.

Affected systems and versions

The CVE record encodes a lower bound of 1.0.0.0 for each named product family, with the family label defining the range:

• Microsoft.Data.SqlClient 6.1: versions before 6.1.7
• Microsoft.Data.SqlClient 7.0: versions before 7.0.3
• Microsoft.Data.SqlClient 7.1: versions before 7.1.0-preview3

Vulnerable configuration: the documented impact concerns applications using Always Encrypted with secure enclaves. Based on our mapping to the fix, the missing key binding was on the VBS/HGS attestation path. Code comments state the Azure Attestation path already performed the check. The advisory additionally lists November 10, 2026 security updates for SQL Server 2025, 2022, 2019 and 2017. Because the named affected component is a driver, inventories should cover application dependencies, not only database servers.

Vendor security history

Microsoft is the vendor and assigning CNA. SQL Server ranks third in the DB Engines popularity ranking for November 2026. That signals broad use of the ecosystem SqlClient serves, though it is not a count of vulnerable installations.

The Cyber Safety Review Board's review of the Summer 2023 Microsoft Exchange Online intrusion described that intrusion as "avoidable." It concerns Exchange Online and has no connection to this CVE. Microsoft's July 2026 Secure Future Initiative progress report claims 99.97% phishing-resistant multifactor authentication coverage, 98.7% cross-boundary credential isolation, public access removed from 732,000 resources, more than 550,000 critical and high-risk open-source vulnerability instances remediated, and automated container patching addressing about 3 million vulnerability instances each month. These are vendor-reported program metrics and do not establish anything about the exploitability of a specific SqlClient deployment.

References

• Microsoft Security Update Guide advisory for CVE-2026-62903
• NVD entry for CVE-2026-62903
• CVE.org record for CVE-2026-62903
• SqlClient 6.1.7 release notes
• SqlClient 7.0.3 release notes
• dotnet/SqlClient PR #4532: enclave session key binding validation
• dotnet/SqlClient PR #4552: backport to release/6.1
• dotnet/SqlClient commit ee6fabd
• dotnet/SqlClient #4583: ServerCertificate pinning on managed SNI
• dotnet/SqlClient #4561: AccessTokenCallback defaults
• MITRE CWE-294: Authentication Bypass by Capture Replay
• NuGet: Microsoft.Data.SqlClient 6.1.7
• NuGet: Microsoft.Data.SqlClient 7.0.3
• NuGet: Microsoft.Data.SqlClient 7.1.0 preview3
• GitHub release v6.1.7
• dotnet/SqlClient releases
• dotnet/SqlClient CHANGELOG
• Microsoft Learn: Always Encrypted with secure enclaves
• Microsoft Learn: Plan for Secure Enclaves in Azure SQL Database
• Microsoft SQL Server product page
• DB Engines Ranking
• Microsoft SFI Progress Report, July 2026
• Microsoft Security Blog: July 2026 SFI progress report
• CSRB Review of the Summer 2023 Microsoft Exchange Online Intrusion
• CISA Known Exploited Vulnerabilities Catalog
• Casco summary of CVE-2026-62903
• DataComm Networks summary of CVE-2026-62903