GHSA-PXH5-6RRC-8RJV: Client-Side Denial of Service in OpenTofu via Crafted HTTP/2 SETTINGS Frame

The vulnerability, tracked as GHSA-PXH5-6RRC-8RJV, affects OpenTofu, an open-source infrastructure as code (IaC) tool. The issue surfaces during the execution of the tofu init command, which is responsible for resolving and downloading required modules and providers. When communicating with an external registry over HTTP/2, the OpenTofu client relies on the underlying Go standard library to parse network frames.

The specific flaw is located in the Go net/http2 implementation utilized by OpenTofu. When the client establishes an HTTP/2 connection with an upstream registry, it expects to receive a valid configuration preface. An attacker-controlled server can manipulate this exchange by supplying a malformed parameter.

According to RFC 7540, the HTTP/2 specification mandates strict bounds for connection parameters. The OpenTofu client fails to enforce the minimum allowable boundary for the SETTINGS_MAX_FRAME_SIZE parameter. By exploiting this oversight, a malicious server can induce abnormal state handling within the client's network parsing logic.

Processing the crafted frame results in uncontrolled resource consumption (CWE-400) and an infinite loop condition (CWE-835). The OpenTofu client process hangs indefinitely, consuming all available cycles on a single CPU core. This state persists until the user manually terminates the application.

The root cause resides in the lack of boundary validation for incoming HTTP/2 configuration parameters within the Go toolchain. Upon establishing an HTTP/2 connection, the client and server exchange SETTINGS frames to negotiate connection parameters. The SETTINGS_MAX_FRAME_SIZE parameter indicates the maximum size of a frame payload that the sender is willing to receive.

RFC 7540 explicitly dictates that the valid range for SETTINGS_MAX_FRAME_SIZE is between 16,384 (2^14) and 16,777,215 (2^24 - 1) octets. In the vulnerable implementation, the parser accepts the value 0 without immediately generating a protocol error. The zero value is then incorrectly applied to the connection state variables.

Once the maximum frame size is set to zero, subsequent read operations fail to advance the internal read pointer. The network parsing loop continuously attempts to read and process zero-length data chunks. Because the exit condition of the loop requires advancing past the current frame length, the loop becomes unreachable, resulting in an infinite execution cycle.

This behavior is documented in the Go vulnerability database under GO-2026-4918. Because OpenTofu is compiled using the Go toolchain, the vulnerable logic from the net/http and golang.org/x/net/http2 packages is statically linked directly into the resulting OpenTofu binary.

The remediation for this vulnerability does not require structural changes to the OpenTofu codebase itself. Instead, the fix entails upgrading the underlying Go toolchain used to compile the project. Pull Request #4098 bumps the Go compiler to version 1.25.10 or a functionally equivalent patched minor release containing the corrected HTTP/2 parser.

In the vulnerable golang.org/x/net/http2 implementation, the framer parses incoming SETTINGS frames without enforcing the lower bound. The parser reads the 32-bit value from the frame payload and directly assigns it to the internal state tracking variable. This allows the zero value to bypass standard validation checks and pollute the active connection configuration.

The updated Go toolchain introduces explicit boundary checks aligned with RFC 7540. If a remote server attempts to negotiate a SETTINGS_MAX_FRAME_SIZE less than 16,384, the parser correctly identifies the violation. The following conceptual diff demonstrates the added validation logic:

// Patched Go http2 framer logic
func (fr *Framer) readSettings(...) error {
    // ...
    for i := 0; i < numSettings; i++ {
        id := SettingID(binary.BigEndian.Uint16(buf[i*6 : i*6+2]))
        val := binary.BigEndian.Uint32(buf[i*6+2 : i*6+6])
        
        // Added validation enforcing RFC 7540 boundaries
        if id == SettingMaxFrameSize && (val < 16384 || val > 16777215) {
            return ConnectionError(ErrCodeProtocol)
        }
        settings = append(settings, Setting{ID: id, Val: val})
    }
}

When the patched parser encounters the zero value, it immediately returns an ErrCodeProtocol error. This terminates the connection gracefully, preventing the infinite loop and mitigating the resource exhaustion vector.

Exploitation requires the attacker to host a malicious registry infrastructure and trick a victim into referencing it. The attack sequence initiates when the targeted user executes tofu init in a directory containing an OpenTofu configuration file. This file must contain a module or provider block pointing to the attacker-controlled server.

Upon execution, the OpenTofu client resolves the registry domain and initiates a standard TLS connection. During the Application-Layer Protocol Negotiation (ALPN) phase of the TLS handshake, the client and server agree to utilize HTTP/2 for transport. The OpenTofu client transmits its initial connection preface and waits for the server's configuration parameters.

The attacker's server responds with a specifically crafted HTTP/2 SETTINGS frame. Within this frame, the SETTINGS_MAX_FRAME_SIZE parameter is explicitly set to 0. The malicious server is not required to transmit any subsequent payload data to trigger the vulnerability.

The OpenTofu client processes the invalid SETTINGS frame and updates its connection state. The application immediately enters the infinite loop condition while attempting to parse the remainder of the stream. The client process hangs, consuming a full CPU core until manual intervention occurs.

The direct impact of GHSA-PXH5-6RRC-8RJV is a complete Denial of Service (DoS) localized to the machine executing the OpenTofu client. The vulnerable process enters an unrecoverable state and consumes maximum processing cycles on a single CPU core. The process will run indefinitely until the operating system sends a termination signal (e.g., SIGKILL).

This vulnerability poses a notable disruption to automated Continuous Integration and Continuous Deployment (CI/CD) pipelines. When a pipeline runner executes the initialization step against a malicious repository, the infinite loop consumes allocated runner resources. This blocks subsequent deployment workflows and prevents the pipeline job from failing gracefully or timing out correctly.

The scope of the exploitation is strictly limited to application-level resource exhaustion. The vulnerability does not allow for remote code execution, arbitrary memory corruption, or information disclosure. The attacker gains no access to the host system or internal network resources.

The CVSS 3.1 score of 3.1 (Low) accurately reflects the limited impact and high complexity required for exploitation. The attacker cannot actively target arbitrary OpenTofu clients. Instead, the victim must explicitly configure their environment to fetch dependencies from a remote source completely controlled by the adversary.

The primary remediation for this vulnerability is upgrading the OpenTofu client binary to version 1.11.8 or later. This version is compiled with an updated Go toolchain that natively prevents the HTTP/2 infinite loop condition. No modifications to OpenTofu configuration files (.tf files) are required to implement the fix.

Administrators must audit their infrastructure deployment environments to ensure the updated binaries are active. This entails updating base Docker images, CI/CD pipeline configurations, and developer workstations. Utilizing package managers or automated dependency tracking tools will facilitate the distribution of the patched client across the organization.

To establish defense-in-depth, network egress restrictions should be applied to CI/CD runners. Implementing an allowlist for trusted provider and module registries restricts the client from communicating with unverified external servers. This mitigates the risk of social engineering attacks directing developers to malicious infrastructure.

Additionally, code review practices should mandate strict scrutiny of external module sources. All module source paths in OpenTofu configurations must point to trusted, verified entities. Employing cryptographic checksum verification for providers further ensures the integrity of the downloaded dependencies.