OpenShift 4.16.70 closes an unauthenticated HTTP/2 denial-of-service path

Red Hat has shipped OpenShift Container Platform 4.16.70 with a fix for an HTTP/2 denial-of-service vulnerability in Go. The company rates the update Important and advises every OpenShift 4.16 user to install the updated packages and images as they become available in the appropriate release channel.

What the malformed frame does

CVE-2026-33814 sits in the HTTP/2 implementation used by Go’s standard-library networking stack and golang.org/x/net. A remote, unauthenticated attacker can send a crafted HTTP/2 SETTINGS frame that sets SETTINGS_MAX_FRAME_SIZE to zero.

Red Hat says that zero value can push the vulnerable transport into an infinite loop writing CONTINUATION frames. The loop consumes CPU and other system resources until the affected service loses availability. The vendor scores the flaw 7.5 under CVSS 3.1: network-accessible, low-complexity, requiring neither privileges nor user interaction, with high availability impact but no confidentiality or integrity impact.

Who needs to act

The 4.16.70 advisory applies to OpenShift Container Platform 4.16. Red Hat publishes the RPM portion in RHSA-2026:62551 and points operators to the companion image advisory, RHSA-2026:62550, for the container images in the same release.

This is more than a theoretical malformed-input bug for platform teams: the attack can originate over the network without authentication, and availability is the security property at risk. Red Hat’s CVE record says there is no mitigation that meets its criteria for ease of deployment, broad applicability and stability.

What operators should do

The practical response is therefore an update, not a configuration workaround. OpenShift 4.16 administrators should check the OpenShift CLI or web console for 4.16.70 in their applicable release channel, follow the cluster-update instructions, and verify that the asynchronous errata has been fully applied.

Teams should treat the update as an availability-risk fix and schedule it promptly through their normal cluster change controls. The absence of a workable mitigation is the key operational constraint: delaying the update leaves services that use the vulnerable Go HTTP/2 implementation exposed to a remotely triggered resource-exhaustion path.