GHSA-mhgm-52vg-pvvc
Privilege escalation in Strongbox
Impact
An attacker with read-only access to a Strongbox secret could craft a valid encrypted secret (same id/version). It also makes the audit logs from KMS less useful. The issue is caused by a bug in the underlying AWS Encryption SDK.
By default, the encrypted secrets are stored in DynamoDB and an attacker with read-only access would not be able to write the encrypted secret to DynamoDB. So in practice the impact should be limited for most users.
Strongbox supports storing data in files as an alternative to DynamoDB. If the attacker had write access to where the files are stored they could make the attack work end-to-end. Similarly, any custom storage backend could also be affected.
In order to be backwards compatible Strongbox will not make use of key commitments (another improvement to the AWS Encryption SDK). Strongbox enforces that only one KMS key can be used, and it must match the expected one. This means that an attacker needs write access to both KMS and DynamoDB (or other storage backend) to stage an attack, which is not a scenario Strongbox is designed to protect against.
Patches
Fixed in version 0.5.0.
Workarounds
None
References
What each source reports
GitHub AdvisoriesNo score
Privilege escalation in Strongbox
Impact
An attacker with read-only access to a Strongbox secret could craft a valid encrypted secret (same id/version). It also makes the audit logs from KMS less useful. The issue is caused by a bug in the underlying AWS Encryption SDK.
By default, the encrypted secrets are stored in DynamoDB and an attacker with read-only access would not be able to write the encrypted secret to DynamoDB. So in practice the impact should be limited for most users.
Strongbox supports storing data in files as an alternative to DynamoDB. If the attacker had write access to where the files are stored they could make the attack work end-to-end. Similarly, any custom storage backend could also be affected.
In order to be backwards compatible Strongbox will not make use of key commitments (another improvement to the AWS Encryption SDK). Strongbox enforces that only one KMS key can be used, and it must match the expected one. This means that an attacker needs write access to both KMS and DynamoDB (or other storage backend) to stage an attack, which is not a scenario Strongbox is designed to protect against.
Patches
Fixed in version 0.5.0.
Workarounds
None
References
- Record
GHSA-mhgm-52vg-pvvc- Weakness
- CWE-269
- Updated
- 2026-11-02
OSVNo score
Privilege escalation in Strongbox
Impact
An attacker with read-only access to a Strongbox secret could craft a valid encrypted secret (same id/version). It also makes the audit logs from KMS less useful. The issue is caused by a bug in the underlying AWS Encryption SDK.
By default, the encrypted secrets are stored in DynamoDB and an attacker with read-only access would not be able to write the encrypted secret to DynamoDB. So in practice the impact should be limited for most users.
Strongbox supports storing data in files as an alternative to DynamoDB. If the attacker had write access to where the files are stored they could make the attack work end-to-end. Similarly, any custom storage backend could also be affected.
In order to be backwards compatible Strongbox will not make use of key commitments (another improvement to the AWS Encryption SDK). Strongbox enforces that only one KMS key can be used, and it must match the expected one. This means that an attacker needs write access to both KMS and DynamoDB (or other storage backend) to stage an attack, which is not a scenario Strongbox is designed to protect against.
Patches
Fixed in version 0.5.0.
Workarounds
None
References
- Record
GHSA-mhgm-52vg-pvvc- Weakness
- CWE-269
- Updated
- 2026-11-02
Affected packages
| Package | Affected | Fixed |
|---|---|---|
com.schibsted.security:strongbox-sdkMaven | before 0.5.0 | 0.5.0 |
com.schibsted.security:strongbox-sdkMaven | before 0.5.0, plus listed versions 0.4.0 | 0.5.0 |
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | GitHub Advisories, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
GHSA-mhgm-52vg-pvvc is a vulnerability with no CVSS score yet in com.schibsted.security:strongbox-sdk, published February 16, 2023. No source lists public exploit code. Fixed in com.schibsted.security:strongbox-sdk 0.5.0.