GHSA-5whh-4q9j-7v28 aws-kms-tls-auth vulnerable to memory overallocation

Not scored Published

A memory overallocation flaw in aws-kms-tls-auth allows remote attackers to cause denial of service via crafted TLS handshakes.

Exploited in the wild
Not known
Login needed
Not needed
Attackable
Over the internet
Victim action needed
Not needed
Fix
Available

What is GHSA-5whh-4q9j-7v28?

GHSA-5whh-4q9j-7v28 is a denial of service vulnerability in aws-kms-tls-auth, published on 3 Mar 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

Official 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 [email protected]. 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

Which versions are affected by GHSA-5whh-4q9j-7v28?

2 open source packages ship an affected version, including aws-kms-tls-auth.

PackageAffectedFixed in
aws-kms-tls-auth crates.ioAll versions0.0.3
aws-kms-tls-auth crates.ioAll versions0.0.3

How do I fix GHSA-5whh-4q9j-7v28?

Upgrade aws-kms-tls-auth to 0.0.3 or later.

Upgrade, then put limits on request size, rate and nesting depth so one client cannot exhaust the service. More about Denial of service.

Is GHSA-5whh-4q9j-7v28 being exploited?

There is no known exploitation of GHSA-5whh-4q9j-7v28 in the wild and no public exploit code.

Sources

Is GHSA-5whh-4q9j-7v28 in your software?

Upload an SBOM and sbomify checks it against every vulnerability here, every day.

Check your SBOMs for free