Azure SDK for Java CVE-2026-33117: Brief Summary of a Critical Authentication Tag Bypass in Key Vault Cryptography

Introduction

A single variable name in the Key Vault cryptography code of the Azure SDK for Java made HMAC authentication tags completely useless. Any tampered ciphertext passed the integrity check without raising an error. Disclosed in Microsoft's May 2026 Patch Tuesday, CVE-2026-33117 has a CVSS 3.1 base score of 9.1 and affects any Java application that uses the azure-security-keyvault-keys library for authenticated encryption and decryption.

The root cause is almost comically simple. A variable shadowing bug made the decryption routine compare the computed authentication tag with itself instead of with the tag the sender provided. The result is a complete bypass of the integrity guarantee that authenticated encryption is supposed to provide.

Technical Information

Root Cause

The vulnerability is in the doFinal() method of the inner Decryptor in the AesCbcHmacSha2 class, part of the azure-security-keyvault-keys package. This method implements authenticated decryption for the AES-CBC-HMAC-SHA2 family of algorithms: A128CBC-HS256, A192CBC-HS384, and A256CBC-HS512.

Decryption is supposed to work like this:

1. Receive ciphertext along with an authentication tag from the sender.
2. Compute a fresh HMAC authentication tag over the received ciphertext.
3. Compare the freshly computed tag against the received tag using a constant-time comparison.
4. If they do not match, reject the data as tampered. If they match, proceed with decryption.

The bug was a classic copy-paste error with severe cryptographic consequences. The local variable holding the computed tag was named tag, which shadowed the outer-scope variable, also named tag, that held the received authentication tag. The vulnerable code looked like this:

// VULNERABLE — tag compared to itself, always true
byte[] tag = new byte[hmacKey.length];
System.arraycopy(hash, 0, tag, 0, hmacKey.length);

if (!CryptographyUtils.sequenceEqualConstantTime(tag, tag)) {
    throw LOGGER.logExceptionAsWarning(new IllegalArgumentException("Data is not authentic"));
}

Because sequenceEqualConstantTime(tag, tag) passes the same array reference as both arguments, the comparison is trivially always true. With the negation, the exception is never thrown. The AEAD scheme loses its authentication guarantee entirely, and any ciphertext is accepted and decrypted without complaint, whether or not it was modified in transit.

The bug maps to two CWE classifications: CWE-287 (Improper Authentication) and CWE-347 (Improper Verification of Cryptographic Signature).

Attack Flow

An attacker can exploit this vulnerability as follows:

1. The attacker identifies a target application that uses the vulnerable azure-security-keyvault-keys library to decrypt data received over a network.
2. The attacker intercepts or crafts encrypted data destined for the application and modifies the ciphertext payload, for example by flipping bits or substituting blocks.
3. The attacker sends the tampered ciphertext (with the original or an arbitrary authentication tag) to the target application.
4. The application's decryption routine computes a new HMAC tag from the tampered ciphertext, but because of the variable shadowing bug, it compares that tag against itself.
5. The integrity check passes unconditionally. The tampered ciphertext is decrypted and processed as if it were authentic.

According to the CVSS vector, the attack has low complexity and needs no user interaction and no elevated privileges. The attack vector is network based, so any application that exposes this decryption path over a network interface is potentially vulnerable.

Successful exploitation leaves the system unable to tell whether encrypted content was tampered with before decryption, which undermines the basic purpose of authenticated encryption.

Patch Information

Microsoft fixed CVE-2026-33117 with a targeted code change in the azure-security-keyvault-keys library, released as version 4.10.6. The fix was merged on February 25, 2026 in PR #48090. The library version was formally released on March 23, 2026, and the MSRC advisory disclosed the vulnerability publicly on May 12, 2026. The patched artifact is available on Maven Central as com.azure:azure-security-keyvault-keys:4.10.6.

The fix itself is a one-variable rename. The locally computed tag is now called authTag instead of tag, which removes the shadowing and restores the intended comparison against the received tag:

// FIXED — computed authTag compared against received tag
byte[] authTag = new byte[hmacKey.length];
System.arraycopy(hash, 0, authTag, 0, hmacKey.length);

if (!CryptographyUtils.sequenceEqualConstantTime(tag, authTag)) {
    throw LOGGER.logExceptionAsWarning(new IllegalArgumentException("Data is not authentic"));
}

The same PR applied the fix to both the v1 (com.azure.security.keyvault.keys) and v2 (com.azure.v2.security.keyvault.keys) SDK codepaths.

Alongside the code change, the PR added a new test class, AesCbcHmacSha2Test, with two parameterized tests covering all three AES-CBC-HMAC-SHA2 algorithm variants:

• decryptorDoFinalRoundTrip: checks that encrypting and then decrypting with the correct tag produces the original plaintext.
• decryptorDoFinalFailsWithWrongTag: flips a byte in the authentication tag and asserts that an IllegalArgumentException is thrown. This confirms that the integrity check now rejects tampered data.

The release PR #48476 packaged the fix into version 4.10.6. It bumped versions across all four Key Vault libraries and updated the CHANGELOGs and POM files to match. The MSRC advisory confirms the Remediation Level as "Official Fix" with build number 4.10.6.

No workarounds or temporary mitigations are available for this vulnerability. Upgrading to version 4.10.6 is the only remediation path.

Affected Systems and Versions

The vulnerability affects the azure-security-keyvault-keys package in the Azure SDK for Java:

• Affected package: com.azure:azure-security-keyvault-keys
• Affected versions: Versions prior to 4.10.6
• Affected codepaths: Both v1 (com.azure.security.keyvault.keys) and v2 (com.azure.v2.security.keyvault.keys) SDK implementations
• Affected algorithms: AES-CBC-HMAC-SHA2 family, including A128CBC-HS256, A192CBC-HS384, and A256CBC-HS512
• Fixed version: 4.10.6

Any Java application that uses the affected library for local AES-CBC-HMAC-SHA2 authenticated decryption is vulnerable. Organizations should audit every application that includes this dependency, whether directly or transitively through other Azure SDK components.

Vendor Security History

As of Q1 2026, Microsoft Azure holds a 21 percent share of the global cloud market, and its Intelligent Cloud segment brought in nearly 34.7 billion dollars in quarterly revenue. With that footprint, a vulnerability in a foundational tool like the Azure SDK can affect a wide range of enterprise environments.

Microsoft's recent progress reports on its Secure Future Initiative describe work to enforce secure defaults, expand hardware-based trust, and update security benchmarks. The prompt release of version 4.10.6 and the new regression tests for this specific bug class fit those stated goals.

CVE-2026-33117 was part of the May 2026 Patch Tuesday update, which fixed 120 flaws across Microsoft products. No active zero-day exploits were reported in that cycle.

References

• MSRC Advisory: CVE-2026-33117
• NVD Entry: CVE-2026-33117
• GitHub PR #48090: Fix for AesCbcHmacSha2 tag comparison
• GitHub PR #48090 Diff
• GitHub PR #48476: Key Vault stable release preparation
• GitHub PR #48476 Files
• CHANGELOG for azure-security-keyvault-keys
• Maven Central: azure-security-keyvault-keys 4.10.6
• Bleeping Computer: Microsoft May 2026 Patch Tuesday fixes 120 flaws
• Bleeping Computer: Microsoft Patch Tuesday May 2026 Report
• Zero Day Initiative: May 2026 Security Update Review