AWS patches key commitment policy bypass in Encryption SDK for Python
TL;DR — A caching-layer cryptographic downgrade in AWS’s Python Encryption SDK can bypass key commitment policy enforcement when multiple clients share a key cache, enabling ciphertext integrity breaks.
What happened
AWS Encryption SDK (ESDK) for Python is a client-side encryption library used to encrypt/decrypt data in applications (often as a building block in higher-level data-protection pipelines). AWS published Security Bulletin 2026-017-AWS for CVE-2026-6550 on Apr 20, 2026 (Publication Date: 04/20/2026 9:15 AM PDT).
AWS describes the issue as a cryptographic algorithm downgrade in the caching layer that, under certain circumstances, can allow an authenticated local threat actor to bypass key commitment policy enforcement via a shared key cache, producing ciphertext “that can be decrypted to multiple different plaintexts.”
Per the linked GitHub advisory (GHSA-v638-38fc-rhfv), exploitation requires specific conditions (notably: two clients with different commitment policies sharing a single caching materials manager instance, matching encryption contexts, and use of the default algorithm suite). The broader takeaway for platform teams: crypto-policy enforcement can be quietly undermined by shared caches and “mixed-policy” migrations, creating integrity risks even when encryption APIs appear to be used correctly.
Who is impacted
- Projects using
pip aws-encryption-sdkin the impacted version ranges. - Environments that share a key cache / caching crypto materials manager across multiple ESDK clients with different key commitment policy configurations (a pattern that can occur during migrations from older ESDK versions that did not support key commitment).
| Component | Impacted versions (per AWS bulletin) | Patched versions (per AWS bulletin) |
|---|---|---|
aws-encryption-sdk (Python) | 2.0 to 2.5.1 | N/A (upgrade guidance applies) |
aws-encryption-sdk (Python) | 3.0 to 3.3.0 | 3.3.1 |
aws-encryption-sdk (Python) | 4.0 to 4.0.4 | 4.0.5 |
What to do now
- Follow AWS remediation guidance and apply the vendor-provided fixes:
This issue has been addressed in ESDK for Python versions 3.3.1 and 4.0.5. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.
- Inventory where
aws-encryption-sdkis used (services, batch jobs, shared libraries) and identify any in-process reuse of caching components (for example, sharedCachingCryptoMaterialsManagerinstances). - If you operate multiple ESDK clients with different commitment policies in the same process, follow the documented workaround:
If a customer requires operating multiple instances of the Python ESDK each with differently configured key commitment policies, they must not share a key cache.
- Treat this as an integrity issue, not “just” a quality bug: if ciphertext flows across trust boundaries (multi-tenant services, message buses, import pipelines), review for scenarios where a party can influence ciphertext inputs and trigger decryption.
Additional Information
- AWS bulletin reference:
CVE-2026-6550 - Key commitment policy bypass via shared key cache in AWS Encryption SDK for Python(Bulletin ID2026-017-AWS). - GitHub advisory with additional technical conditions and context:
GHSA-v638-38fc-rhfv.
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.