Skip to content

aws-kms-tls-auth vulnerable to memory overallocation

Low severity GitHub Reviewed Published Mar 2, 2026 in aws/s2n-tls • Updated Mar 3, 2026

Package

cargo aws-kms-tls-auth (Rust)

Affected versions

< 0.0.3

Patched versions

0.0.3

Description

Summary

aws-kms-tls-auth is an optional utility for s2n-tls that enables customers to use AWS KMS keys as part of the PSK extension field in a TLS 1.3 handshake. An issue exists in this library that can lead to overallocation of memory potentially resulting in a denial of service.

Impact

The PSK extension field in TLS 1.3 uses length-prefixed lists to encode variable-length data. aws-kms-tls-auth interprets the length prefix incorrectly resulting in additional memory allocation. 

s2n-tls limits ClientHello messages to 64 KB. Due to this issue, the server may allocate up to 10× the received size, meaning a single message could trigger an allocation of up to 640 KB. Repeated allocations of this size could exhaust server resources and lead to a denial-of-service.

No AWS services are affected. Applications should continue to follow best practices by limiting the number of in-flight handshakes and concurrent connections. Applications using the aws-kms-tls-auth crate should upgrade to version 0.0.3.

Impacted versions: < 0.0.3

Patches

This issue has been addressed in aws-kms-tls-auth v0.0.3 [1].

Workarounds

There is no workaround. Applications using aws-kms-tls-auth should upgrade to the most recent release.

Acknowledgement

s2n-tls would like to thank Joshua Rogers (https://joshua.hu/) of AISLE Research Team (https://aisle.com/) for collaborating on this issue through the coordinated disclosure process.

If there are any questions or comments about this advisory, contact AWS/Amazon Security via the vulnerability reporting page [2] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] https://crates.io/crates/aws-kms-tls-auth/0.0.3
[2] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

References

@kaukabrizvi kaukabrizvi published to aws/s2n-tls Mar 2, 2026
Published to the GitHub Advisory Database Mar 3, 2026
Reviewed Mar 3, 2026
Last updated Mar 3, 2026

Severity

Low

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
Low

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

EPSS score

Weaknesses

Improper Restriction of Operations within the Bounds of a Memory Buffer

The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data. Learn more on MITRE.

CVE ID

No known CVE

GHSA ID

GHSA-5whh-4q9j-7v28

Source code

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.