aes-gcm

Version	Released
`0.11.1` patch	Aug 21, 2026
`0.11.0` unknown	Jun 28, 2026
`0.11.0-rc.4` unknown	May 25, 2026
`0.11.0-rc.3` unknown	Feb 02, 2026
`0.11.0-rc.2` unknown	Nov 05, 2025
`0.11.0-rc.1` unknown	Sep 03, 2025
`0.11.0-rc.0` unknown	May 30, 2025
`0.11.0-pre.2` unknown	Oct 07, 2024
`0.11.0-pre.1` unknown	Jul 27, 2024
`0.11.0-pre.0` unknown	Jul 26, 2024
`0.10.3` unknown	Sep 21, 2023
`0.10.2` unknown 1 CVE	May 20, 2023
`0.10.1` unknown 1 CVE	Aug 01, 2022
`0.10.0` unknown 1 CVE	Aug 01, 2022
`0.10.0-pre.2` unknown	Jul 20, 2022
`0.10.0-pre.1` unknown	Jul 02, 2022
`0.10.0-pre` unknown	Apr 21, 2022
`0.9.4` unknown	Aug 28, 2021
`0.9.3` unknown	Jul 20, 2021
`0.9.2` unknown	May 31, 2021
`0.9.1` unknown	May 05, 2021
`0.9.0` unknown	Apr 29, 2021
`0.8.0` unknown	Oct 16, 2020
`0.7.0` unknown	Sep 17, 2020
`0.6.0` unknown	Jun 06, 2020
`0.5.0` unknown	Mar 15, 2020
`0.4.2` unknown	Mar 09, 2020
`0.4.1` unknown yanked	Mar 08, 2020
`0.4.0` unknown yanked	Mar 08, 2020
`0.3.2` unknown	Feb 27, 2020
`0.3.1` unknown	Feb 27, 2020
`0.3.0` unknown	Nov 27, 2019
`0.2.1` unknown	Nov 27, 2019
`0.2.0` unknown	Nov 26, 2019
`0.1.1` unknown yanked	Nov 14, 2019
`0.1.0` unknown yanked	Oct 07, 2019
`0.0.0` unknown yanked	Aug 16, 2019

0.11.1 patch

Aug 21, 2026

0.11.0 unknown

Jun 28, 2026

0.11.0-rc.4 unknown

May 25, 2026

0.11.0-rc.3 unknown

Feb 02, 2026

0.11.0-rc.2 unknown

Nov 05, 2025

0.11.0-rc.1 unknown

Sep 03, 2025

0.11.0-rc.0 unknown

May 30, 2025

0.11.0-pre.2 unknown

Oct 07, 2024

0.11.0-pre.1 unknown

Jul 27, 2024

0.11.0-pre.0 unknown

Jul 26, 2024

0.10.3 unknown

Sep 21, 2023

0.10.2 unknown

1 CVE

CVE-2023-42811 RUSTSEC-2023-0096 GHSA-423w-p2w9-r7vq Nov 22, 2023

Plaintext exposed in decrypt_in_place_detached even on tag verification failure

4.7 / 10

Medium

Local High High None Unchanged Low High None

Summary

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.

Impact

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.

Details

As seen in the implementation of decrypt_in_place_detached for AES GCM, if the tag verification fails, an error is returned. Because the decryption of the ciphertext is done in place, the plaintext contents are now exposed via buffer.

This should ideally not be the case - as noted in page 17 of NIST's publication Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC:

In Step 8, the result of Step 7 is compared with the authentication tag that was received as an input: if they are identical, then the plaintext is returned; otherwise,FAIL is returned.

This is seems correctly addressed in the AES GCM SIV implementation, where the decrypted buffer is encrypted again before the error is returned - this fix is straightforward to implement in AES GCM. To ensure that these types of cases are covered during testing, it would be valuable to add test cases like 23, 24 etc from project wycheproof to ensure that when a bad tag is used, there is an error on decryption and that the plaintext value is not exposed.

PoC

To reproduce this issue, I'm using test case 23 from project wycheproof.

    let key = GenericArray::from_slice(&hex!("000102030405060708090a0b0c0d0e0f"));
    let nonce = GenericArray::from_slice(&hex!("505152535455565758595a5b"));
    let tag = GenericArray::from_slice(&hex!("d9847dbc326a06e988c77ad3863e6083")); // bad tag
    let mut ct = hex!("eb156d081ed6b6b55f4612f021d87b39");
    let msg = hex!("202122232425262728292a2b2c2d2e2f");
    let aad = hex!("");
    let cipher = Aes128Gcm::new(&key);
    let _plaintext = cipher.decrypt_in_place_detached(&nonce, &aad, &mut ct, &tag);
    assert_eq!(ct, msg);

Fixed in


          0.10.3

References

Updated Dec 29, 2025 · Source: OSV.dev

May 20, 2023

0.10.1 unknown

1 CVE

CVE-2023-42811 RUSTSEC-2023-0096 GHSA-423w-p2w9-r7vq Nov 22, 2023

Plaintext exposed in decrypt_in_place_detached even on tag verification failure

4.7 / 10

Medium

Local High High None Unchanged Low High None

Summary

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.

Impact

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.

Details

As seen in the implementation of decrypt_in_place_detached for AES GCM, if the tag verification fails, an error is returned. Because the decryption of the ciphertext is done in place, the plaintext contents are now exposed via buffer.

This should ideally not be the case - as noted in page 17 of NIST's publication Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC:

In Step 8, the result of Step 7 is compared with the authentication tag that was received as an input: if they are identical, then the plaintext is returned; otherwise,FAIL is returned.

This is seems correctly addressed in the AES GCM SIV implementation, where the decrypted buffer is encrypted again before the error is returned - this fix is straightforward to implement in AES GCM. To ensure that these types of cases are covered during testing, it would be valuable to add test cases like 23, 24 etc from project wycheproof to ensure that when a bad tag is used, there is an error on decryption and that the plaintext value is not exposed.

PoC

To reproduce this issue, I'm using test case 23 from project wycheproof.

    let key = GenericArray::from_slice(&hex!("000102030405060708090a0b0c0d0e0f"));
    let nonce = GenericArray::from_slice(&hex!("505152535455565758595a5b"));
    let tag = GenericArray::from_slice(&hex!("d9847dbc326a06e988c77ad3863e6083")); // bad tag
    let mut ct = hex!("eb156d081ed6b6b55f4612f021d87b39");
    let msg = hex!("202122232425262728292a2b2c2d2e2f");
    let aad = hex!("");
    let cipher = Aes128Gcm::new(&key);
    let _plaintext = cipher.decrypt_in_place_detached(&nonce, &aad, &mut ct, &tag);
    assert_eq!(ct, msg);

Fixed in


          0.10.3

References

Updated Dec 29, 2025 · Source: OSV.dev

Aug 01, 2022

0.10.0 unknown

1 CVE

CVE-2023-42811 RUSTSEC-2023-0096 GHSA-423w-p2w9-r7vq Nov 22, 2023

Plaintext exposed in decrypt_in_place_detached even on tag verification failure

4.7 / 10

Medium

Local High High None Unchanged Low High None

Summary

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.

Impact

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.

Details

As seen in the implementation of decrypt_in_place_detached for AES GCM, if the tag verification fails, an error is returned. Because the decryption of the ciphertext is done in place, the plaintext contents are now exposed via buffer.

This should ideally not be the case - as noted in page 17 of NIST's publication Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC:

In Step 8, the result of Step 7 is compared with the authentication tag that was received as an input: if they are identical, then the plaintext is returned; otherwise,FAIL is returned.

This is seems correctly addressed in the AES GCM SIV implementation, where the decrypted buffer is encrypted again before the error is returned - this fix is straightforward to implement in AES GCM. To ensure that these types of cases are covered during testing, it would be valuable to add test cases like 23, 24 etc from project wycheproof to ensure that when a bad tag is used, there is an error on decryption and that the plaintext value is not exposed.

PoC

To reproduce this issue, I'm using test case 23 from project wycheproof.

    let key = GenericArray::from_slice(&hex!("000102030405060708090a0b0c0d0e0f"));
    let nonce = GenericArray::from_slice(&hex!("505152535455565758595a5b"));
    let tag = GenericArray::from_slice(&hex!("d9847dbc326a06e988c77ad3863e6083")); // bad tag
    let mut ct = hex!("eb156d081ed6b6b55f4612f021d87b39");
    let msg = hex!("202122232425262728292a2b2c2d2e2f");
    let aad = hex!("");
    let cipher = Aes128Gcm::new(&key);
    let _plaintext = cipher.decrypt_in_place_detached(&nonce, &aad, &mut ct, &tag);
    assert_eq!(ct, msg);

Fixed in


          0.10.3

References

Updated Dec 29, 2025 · Source: OSV.dev

Aug 01, 2022

0.10.0-pre.2 unknown

Jul 20, 2022

0.10.0-pre.1 unknown

Jul 02, 2022

0.10.0-pre unknown

Apr 21, 2022

0.9.4 unknown

Aug 28, 2021

0.9.3 unknown

Jul 20, 2021

0.9.2 unknown

May 31, 2021

0.9.1 unknown

May 05, 2021

0.9.0 unknown

Apr 29, 2021

0.8.0 unknown

Oct 16, 2020

0.7.0 unknown

Sep 17, 2020

0.6.0 unknown

Jun 06, 2020

0.5.0 unknown

Mar 15, 2020

0.4.2 unknown

Mar 09, 2020

0.4.1 unknown yanked

Mar 08, 2020

0.4.0 unknown yanked

Mar 08, 2020

0.3.2 unknown

Feb 27, 2020

0.3.1 unknown

Feb 27, 2020

0.3.0 unknown

Nov 27, 2019

0.2.1 unknown

Nov 27, 2019

0.2.0 unknown

Nov 26, 2019

0.1.1 unknown yanked

Nov 14, 2019

0.1.0 unknown yanked

Oct 07, 2019

0.0.0 unknown yanked

Aug 16, 2019

Activity

Reach

Details

Summary

Impact

Details

PoC

Summary

Impact

Details

PoC

Summary

Impact

Details

PoC

Summary

Impact

Details

PoC