GHSA-xmrv-pmrh-hhx2: Remote Denial of Service via EventStream Decoder Panic in AWS SDK for Go v2

The AWS SDK for Go v2 relies on the eventstream package to parse binary data streams returned by various AWS services. These streams transport real-time or chunked data blocks for operations involving services such as Amazon S3 Select, Amazon Bedrock, and AWS CloudWatch Logs. The decoder processes individual frames, which contain metadata headers and data payloads.

GHSA-xmrv-pmrh-hhx2 represents a Denial of Service (DoS) vulnerability triggered by an unhandled panic within this parsing logic. The defect specifically exists in how the decoder evaluates the data type of incoming header values. When the parser receives a type byte that falls outside the recognized specification, it defaults to triggering a runtime panic rather than returning a structured error.

Because Go applications natively terminate upon encountering an unrecovered panic across standard goroutines, successful exploitation results in immediate service degradation. The affected microservice or application process crashes instantly, dropping all current connections and operations. This creates a severe availability impact for any backend service reliant on the AWS SDK for Go v2.

Exploitation requires the attacker to supply a malformed EventStream frame to the target client. This restricts the attack vector to scenarios where the adversary can manipulate the network traffic or control the endpoint that the AWS SDK communicates with. The vulnerability is classified under CWE-248 (Uncaught Exception) and CWE-20 (Improper Input Validation).

The AWS EventStream protocol provides a binary data streaming format designed for efficient data transfer between AWS components and client software. Each data transmission is broken down into discrete messages or frames. A standard frame contains a prelude (specifying total length and header length), followed by the headers, and finally the payload.

Headers within an EventStream frame consist of a name and a value. To optimize parsing, the header value is strictly typed using a single prefixed byte. For example, the byte 0x00 denotes a boolean true, while 0x07 denotes a signed 32-bit integer. The decoder uses this type byte to determine how to read the subsequent bytes in the frame.

The vulnerability resides in the decoder's error handling for unrecognized type bytes. When the parser extracts a byte that does not map to any enumerated constant in the EventStream specification, it fails to fall back to a safe error state. Instead, the developers implemented a panic call for the default case, effectively turning a simple data validation failure into a fatal process event.

The fundamental flaw involves the use of panic for standard control flow during untrusted data ingestion. In Go, panics should be reserved for unrecoverable state corruption, not for handling malformed input from network streams. The vulnerable code path evaluates the header type byte via a switch statement.

func decodeHeaderValue(r io.Reader, typeByte byte) (interface{}, error) {
    switch typeByte {
    case boolTrueType:
        return true, nil
    case stringType:
        return readString(r)
    // ... valid type cases ...
    default:
        // VULNERABLE CODE: Triggers fatal application termination
        panic(fmt.Sprintf("unknown eventstream header type: %d", typeByte))
    }
}

Pull Request #3355 addresses this defect by replacing the panic call with an explicit error return. This allows the calling SDK service to handle the malformed frame gracefully. The calling function receives the error, abandons the current stream processing, and bubbles the error up to the application developer without terminating the entire Go runtime.

func decodeHeaderValue(r io.Reader, typeByte byte) (interface{}, error) {
    switch typeByte {
    case boolTrueType:
        return true, nil
    case stringType:
        return readString(r)
    // ... valid type cases ...
    default:
        // PATCHED CODE: Returns a standard Go error interface
        return nil, fmt.Errorf("unknown eventstream header type: %d", typeByte)
    }
}

This remediation aligns with secure coding practices for protocol parsers in Go. By converting the panic into a standard error, the availability impact is neutralized. The connection will fail gracefully, but the host application remains active to process subsequent requests.

To exploit this vulnerability, an attacker must successfully deliver a malformed EventStream frame to the target application. The target must be actively utilizing the AWS SDK for Go v2 to communicate with an endpoint that streams data via the EventStream protocol. The application expects standard API responses but receives the malicious payload instead.

The CVSS Attack Complexity is rated High (AC:H) because the attacker cannot generally send this frame directly to the AWS SDK application under normal operating conditions. The attacker requires a Man-in-the-Middle (MitM) position to intercept and modify the legitimate AWS response, or they must manipulate DNS/routing to point the SDK at a malicious server acting as a spoofed AWS endpoint.

The malicious payload construction requires satisfying the initial protocol checks. The attacker crafts a valid frame prelude, calculating the correct CRC32 checksums for the frame length and header length. This ensures the decoder accepts the frame structure and proceeds to the header parsing logic.

Once the prelude validation passes, the decoder evaluates the crafted headers. The attacker inserts a header where the type byte is set to an undefined value, such as 0xFF. Upon processing this specific byte, the Go runtime triggers the panic, immediately crashing the client application. No authentication is required (PR:N), as the flaw occurs during the structural parsing of the response.

In the Go programming language, an unrecovered panic cascades up the call stack, bypassing standard return values. If a panic reaches the top of a goroutine's stack without being intercepted by a recover() function, the entire runtime forcefully terminates. The AWS SDK eventstream package did not employ recover() mechanisms internally for this parsing routine.

Because the AWS SDK is typically embedded within a larger backend service, this single panic terminates the entire host application. All active connections, stateful memory transactions, and unrelated background processes running in that specific binary are abruptly destroyed. This results in a complete loss of availability for the affected system.

Applications leveraging services like Amazon Bedrock for generative AI, Amazon S3 Select for partial data retrieval, or AWS CloudWatch Logs for stream monitoring are specifically vulnerable. These services rely heavily on the EventStream protocol to deliver chunked data over long-lived connections.

The impact is strictly limited to availability (A:H). There is no mechanism within this vulnerability to achieve Remote Code Execution (RCE) or read arbitrary memory. The confidentiality (C:N) and integrity (I:N) of the system remain intact, as the process halts before any corrupted state can be exploited for further access.

The complete resolution for GHSA-xmrv-pmrh-hhx2 requires upgrading the AWS SDK for Go v2 dependencies within the vulnerable project. Software developers and security engineers must update their go.mod files and rebuild the application binary to integrate the patched decoder logic.

Specifically, developers must ensure that the github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream package is updated to version 1.7.8 or later. Because Go modules manage dependencies hierarchically, updating the top-level SDK package will generally pull in the correct transitive dependencies.

In addition to the core protocol package, several service-specific clients must be updated to their corresponding fixed versions. Critical service updates include service/s3 (v1.97.3), service/bedrockruntime (v1.50.4), and service/lambda (v1.88.5). Comprehensive audits of the Go module graph using go list -m all will confirm the presence of the patched versions.

No viable configuration workarounds exist within the SDK itself to prevent the panic. If patching is temporarily impossible, network-level mitigations such as strict TLS validation and certificate pinning must be enforced to reduce the risk of Man-in-the-Middle attacks, thereby elevating the difficulty of supplying the malicious payload.