CVE-2023-42811 in aes-gcm
Summary
by MITRE • 09/22/2023
aes-gcm is a pure Rust implementation of the AES-GCM. Starting in version 0.10.0 and prior to version 0.10.3, in the AES GCM implementation of decrypt_in_place_detached, the decrypted ciphertext (i.e. the correct plaintext) is exposed even if tag verification fails. If a program using the `aes-gcm` crate's `decrypt_in_place*` APIs accesses the buffer after decryption failure, it will contain a decryption of an unauthenticated input. Depending on the specific nature of the program this may enable Chosen Ciphertext Attacks (CCAs) which can cause a catastrophic breakage of the cipher including full plaintext recovery. Version 0.10.3 contains a fix for this issue.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 01/01/2026
The vulnerability described in CVE-2023-42811 affects the aes-gcm crate, a pure Rust implementation of the Advanced Encryption Standard with Galois/Counter Mode cipher. This cryptographic library is widely used in Rust applications for secure data encryption and authentication. The flaw exists in versions 0.10.0 through 0.10.2 of the crate, where the decrypt_in_place_detached function exhibits a critical security weakness that undermines the fundamental security guarantees of authenticated encryption. The vulnerability stems from the implementation's failure to properly handle authentication tag verification failures, creating a scenario where plaintext exposure occurs even when decryption should have been rejected.
The technical flaw manifests specifically within the decrypt_in_place_detached function where the cryptographic implementation continues to process and expose the decrypted plaintext even when the authentication tag verification fails. This behavior violates the core principle of authenticated encryption which requires that any modification to the ciphertext or authentication tag should result in complete rejection of the decryption operation. The flaw creates a side-channel exposure where an attacker can potentially extract information about the plaintext through careful analysis of the decryption process, even when the authentication check fails. This issue is classified as a violation of CWE-310, which addresses cryptographic issues related to authentication failures and improper handling of authentication tokens.
The operational impact of this vulnerability is severe and can lead to catastrophic security consequences for affected systems. When a program using the affected aes-gcm crate accesses the decryption buffer after a tag verification failure, it inadvertently exposes the decrypted plaintext of an unauthenticated input. This creates a direct pathway for Chosen Ciphertext Attacks (CCAs) as outlined in the ATT&CK framework under technique T1552.001 for unsecured credentials and T1071.004 for application layer protocol. An attacker exploiting this vulnerability can potentially recover the full plaintext of encrypted data, effectively breaking the confidentiality guarantees provided by the AES-GCM cipher. The vulnerability is particularly dangerous because it allows for information leakage without requiring the attacker to possess the encryption key, making it a significant concern for applications handling sensitive data.
The fix implemented in version 0.10.3 addresses the root cause by ensuring that when authentication tag verification fails, the decryption buffer is not modified or exposed to the calling application. This remediation aligns with cryptographic best practices and proper implementation of authenticated encryption modes as recommended in NIST SP 800-38D and RFC 5116. Organizations using the affected crate should immediately upgrade to version 0.10.3 or later to mitigate this vulnerability. Additionally, security teams should conduct comprehensive audits of applications using this crate to identify any potential code paths that might access decryption buffers after authentication failures, as these applications may be vulnerable to the described attack vectors. The vulnerability demonstrates the critical importance of proper error handling in cryptographic implementations and the necessity of rigorous security testing for cryptographic libraries.