Introduction
A single variable name in the Azure SDK for Java's Key Vault cryptography implementation rendered HMAC authentication tags completely useless, allowing any tampered ciphertext to pass integrity checks without raising an error. Disclosed as part of Microsoft's May 2026 Patch Tuesday, CVE-2026-33117 carries a CVSS 3.1 base score of 9.1 and affects any Java application relying on the azure-security-keyvault-keys library for authenticated encryption and decryption operations.
The root cause is almost comically simple: a variable shadowing bug caused the decryption routine to compare a computed authentication tag with itself instead of the tag provided by the sender. The result is a complete bypass of the integrity guarantee that authenticated encryption is supposed to provide.
Technical Information
Root Cause
The vulnerability sits in the AesCbcHmacSha2 class within the azure-security-keyvault-keys package, specifically in the inner Decryptor's doFinal() method. This method implements authenticated decryption using the AES-CBC-HMAC-SHA2 family of algorithms, covering A128CBC-HS256, A192CBC-HS384, and A256CBC-HS512.
The intended behavior during decryption is straightforward:
- Receive ciphertext along with an authentication tag from the sender.
- Compute a fresh HMAC authentication tag over the received ciphertext.
- Compare the freshly computed tag against the received tag using a constant time comparison.
- 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 locally declared 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. The negation means the exception is never thrown. This completely nullifies the authentication guarantee of the AEAD scheme: any ciphertext, regardless of whether it has been modified in transit, will be accepted and decrypted without complaint.
This 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 through the following sequence:
- The attacker identifies a target application that uses the vulnerable
azure-security-keyvault-keyslibrary for decrypting data received over a network. - The attacker intercepts or crafts encrypted data destined for the application. They modify the ciphertext payload, for example by flipping bits or substituting blocks.
- The attacker sends the tampered ciphertext (with the original or arbitrary authentication tag) to the target application.
- The application's decryption routine computes a new HMAC tag from the tampered ciphertext, but due to the variable shadowing bug, compares this computed tag against itself.
- The integrity check passes unconditionally. The tampered ciphertext is decrypted and processed as if it were authentic.
The attack requires no user interaction, no elevated privileges, and involves low attack complexity according to the CVSS vector. The attack vector is network based, meaning any application exposing this decryption path over a network interface is potentially vulnerable.
The impact is significant: successful exploitation prevents the system from identifying whether encrypted content has been tampered with before decryption. This undermines the fundamental purpose of authenticated encryption.
Patch Information
Microsoft addressed CVE-2026-33117 through a targeted code fix in the azure-security-keyvault-keys library, released as version 4.10.6. The fix was merged on February 25, 2026 via PR #48090, with the library version formally released on March 23, 2026 and publicly disclosed through the MSRC advisory 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 renamed from tag to authTag, eliminating the variable shadowing and restoring 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")); }
This fix was applied across both the v1 (com.azure.security.keyvault.keys) and v2 (com.azure.v2.security.keyvault.keys) SDK codepaths in the same PR.
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: validates that encrypt then decrypt with the correct tag produces the original plaintext.decryptorDoFinalFailsWithWrongTag: flips a byte in the authentication tag and asserts that anIllegalArgumentExceptionis thrown, ensuring the integrity check now actually rejects tampered data.
The release PR #48476 packaged this fix into version 4.10.6, bumping versions across all four Key Vault libraries and updating CHANGELOGs and POM files accordingly. The MSRC advisory confirms the Remediation Level as "Official Fix" with build number 4.10.6.
There are no available workarounds or temporary mitigations 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. Specifically:
- 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 cryptographic operations involving AES-CBC-HMAC-SHA2 authenticated decryption is vulnerable. Organizations should audit all applications that include this dependency, including transitive dependencies pulled in through other Azure SDK components.
Vendor Security History
Microsoft Azure holds a 21 percent share of the global cloud market as of Q1 2026, generating nearly 34.7 billion dollars in quarterly revenue for its Intelligent Cloud segment. This market footprint means vulnerabilities in foundational tools like the Azure SDK have widespread potential impact across enterprise environments.
Microsoft has been actively advancing its Secure Future Initiative, with recent progress reports highlighting efforts to enforce secure defaults, expand hardware based trust, and update security benchmarks. The prompt release of version 4.10.6 and the addition of targeted regression tests for this specific bug class align with those stated goals.
CVE-2026-33117 was part of the May 2026 Patch Tuesday update, which addressed 120 total flaws across Microsoft products with zero active zero day exploits 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



