Staging Environment: Content and features may be unstable or change without notice.

Advisory Weakness Curation

GHSA-4ph2-8337-hm62

Progress 0 / 0

Advisory Summaries

github_osv/GHSA-4ph2-8337-hm62

Key Caching behavior in the DynamoDB Encryption Client. ### Impact This advisory concerns users of MostRecentProvider in the DynamoDB Encryption Client with a key provider like AWS Key Management Service that allows for permissions on keys to be modified. When key usage permissions were changed at the key provider, time-based key reauthorization logic in MostRecentProvider did not reauthorize the use of the key. This created the potential for keys to be used in the DynamoDB Encryption Client after permissions to do so were revoked at the key provider. ### Patches Fixed as of 1.3.0. We recommend users to modify their code and adopt `CachingMostRecentProvider`. ### Workarounds Users who cannot upgrade to use the `CachingMostRecentProvider` can call `clear()` on the cache to manually flush all of its contents. Next use of the key will force a re-validation to occur with the key provider.

gitlab/pypi/dynamodb-encryption-sdk/GMS-2021-10

Key Caching behavior in the DynamoDB Encryption Client. ### Impact This advisory concerns users of MostRecentProvider in the DynamoDB Encryption Client with a key provider like AWS Key Management Service that allows for permissions on keys to be modified. When key usage permissions were changed at the key provider, time-based key reauthorization logic in MostRecentProvider did not reauthorize the use of the key. This created the potential for keys to be used in the DynamoDB Encryption Client after permissions to do so were revoked at the key provider. ### Patches Fixed as of We recommend users to modify their code and adopt `CachingMostRecentProvider`. ### Workarounds Users who cannot upgrade to use the `CachingMostRecentProvider` can call `clear()` on the cache to manually flush all of its contents. Next use of the key will force a re-validation to occur with the key provider.