GHSA-xmrv-pmrh-hhx2

What it actually does

A flaw in the AWS SDK for Go v2's EventStream header decoder allows a malformed response frame to cause a panic. This occurs because the decoder does not properly validate the header value type byte. An attacker can send a crafted frame with a type byte outside the valid range, leading to an unhandled error that terminates the entire host application process.

Why it matters to the business

This vulnerability can lead to a denial-of-service (DoS) condition for any application utilizing the vulnerable AWS Go SDK. If an attacker can manipulate the data stream from an AWS service (e.g., via a Man-in-the-Middle attack), they can repeatedly crash client applications. This results in service unavailability, disruption of data processing pipelines, and reduced reliability for systems that depend on these applications.

How an attack unfolds

An attacker must first position themselves to intercept and modify traffic between a target application and an AWS service that uses the EventStream protocol (such as S3 Select or Kinesis). The attacker would capture a legitimate response from the AWS service and alter a specific byte in an EventStream message header, setting it to an invalid value. When this malicious response is forwarded to the target application, the vulnerable AWS SDK for Go v2 attempts to parse it. The invalid header value triggers a panic within the SDK's decoder, which is not caught, causing the entire Go application to crash immediately.

How to fix it

To remediate this vulnerability, developers must update the `aws-sdk-go-v2` module in their Go applications to the version tagged `release-2026-03-23` or a later version. Update the dependency in your `go.mod` file and run `go mod tidy` and `go get` to ensure the patched version is downloaded and used in the build.

How to confirm the fix worked

To confirm remediation, verify that the version of `aws-sdk-go-v2` in your application's `go.mod` and `go.sum` files is `release-2026-03-23` or newer. Security teams can use Software Composition Analysis (SCA) tools or custom scripts to scan their organization's source code repositories and build artifacts to find any instances of vulnerable versions of the SDK.

Typical attack path

1. Attacker gains a Man-in-the-Middle (MitM) position to intercept traffic between an application and an AWS endpoint.
2. The application, using a vulnerable AWS SDK for Go v2, communicates with an AWS service utilizing the EventStream protocol.
3. Attacker intercepts a valid EventStream response from the AWS service.
4. Attacker modifies the response, crafting a header with an invalid value type byte.
5. The malicious response is sent to the application.
6. The application's SDK attempts to parse the response, triggers a panic, and crashes.

How to detect it

Exploitation of this vulnerability would manifest as an unexpected crash of a Go application. To detect if this has occurred, administrators should review application logs and system logs for evidence of process termination. Specifically, look for Go panic stack traces originating from the `aws-sdk-go-v2` library, particularly within code related to `eventstream` decoding. Network-level detection is difficult due to TLS encryption, so host-based and application-level monitoring are the most effective methods.

What your security team should do

• Immediately prioritize updating all Go applications using the `aws-sdk-go-v2` library to a patched version (`release-2026-03-23` or later).
• Deploy Software Composition Analysis (SCA) tools to identify and inventory all uses of this library across your software portfolio.
• Advise development teams to implement process supervision and automated restart mechanisms for critical services to minimize downtime from unexpected crashes, as a defense-in-depth measure.