CODERED VTA

Red Hat Patches Important HTTP2 Denial of Service Flaw in Skopeo Container Tooling

High
Security camera on a concrete wall
Photo by Scott Webb on StockSnap

Red Hat published security advisory RHSA-2026:74581 on 1 October 2026, delivering an updated skopeo package for Red Hat Enterprise Linux 9.6 Extended Update Support. The advisory addresses a single issue, CVE-2026-33814, a denial-of-service weakness in the Go HTTP/2 implementation found in net/http/internal/http2 and the golang.org/x/net module. Skopeo is the command-line utility administrators use to inspect container images in remote registries, copy images and image layers between registries and local storage, and create or verify image signatures, so the affected code sits directly in the network path of everyday container operations. Red Hat has rated the update as Important. The fix ships as skopeo-1.18.1-6.el9_6.1 and is published for x86_64, s390x, ppc64le and aarch64 across Extended Update Support, Server AUS, Update Services for SAP Solutions, four-years-of-updates and Extended Life Cycle channels for RHEL 9.6.

Red Hat describes the defect as a denial of service triggered by a malformed SETTINGS_MAX_FRAME_SIZE frame, and the errata itself does not publish a step-by-step exploitation walkthrough or a numeric CVSS base score in its body, pointing instead to the CVE page for scoring detail. SETTINGS frames are the parameter-negotiation messages that HTTP/2 peers exchange when a connection is established, and MAX_FRAME_SIZE is the value that tells the other side how large a single frame may be. Because the flawed handling lives in Go's bundled HTTP/2 code and in golang.org/x/net rather than in skopeo's own source, any Go program compiled against the affected library versions inherits the weakness; skopeo is exposed through the HTTP/2 client it uses to talk to container registries. Red Hat tracks the issue internally as Bugzilla 2467815 and has not stated in this advisory that any configuration is immune, so all RHEL 9.6 systems carrying an earlier skopeo build are in scope. Beyond that mechanism, the vendor has not published further exploitation details with this errata.

The practical exposure here is availability rather than data loss. Skopeo is rarely an interactive tool on a single workstation; it is wired into build servers, CI/CD runners, registry mirroring jobs and image-promotion pipelines, frequently pulling from third-party or public registries that an operator does not control. That makes a hostile or compromised registry endpoint the most plausible way a malformed HTTP/2 frame would ever reach the vulnerable parser, and the realistic consequence is a crashed or hung image operation rather than code execution or credential theft. The fleet affected is also a conservative one by definition: EUS, AUS, Update Services for SAP Solutions and Extended Life Cycle subscriptions are bought by organisations running long-lived, change-controlled estates such as banks, telcos and government platforms, where a pipeline stall during a release window carries real operational cost. On current exploitation status, FIRST EPSS puts CVE-2026-33814 at a 0.8 percent probability of exploitation in the next 30 days, and Red Hat reports no in-the-wild activity in this advisory. There is no indication of an active campaign, which places this firmly in the category of scheduled maintenance rather than incident response, though the shared-library nature of the Go HTTP/2 bug means further Red Hat errata for other Go-based packages on the same release are a reasonable expectation.

Attack Surface

Server OS, Infrastructure

Tactics

Impact

Techniques

  • T1499 – Endpoint Denial of Service
  • T1499.004 – Application or System Exploitation

SuperPRO's Threat Countermeasures Procedures

  1. Update skopeo to version 1.18.1-6.el9_6.1 or later on all RHEL 9.6 hosts, using the architecture-specific packages published in RHSA-2026:74581 (skopeo-1.18.1-6.el9_6.1.x86_64.rpm, .s390x.rpm, .ppc64le.rpm, .aarch64.rpm) and apply the matching skopeo-debuginfo, skopeo-debugsource and skopeo-tests packages where those are deployed.
  2. Verify downloaded RPMs against the SHA-256 digests in the errata before installation, for example 232d745aee4e922e5d4623b164d016043195a27b5d6a8db753e176dcc6d2c6e3 for skopeo-1.18.1-6.el9_6.1.x86_64.rpm and f098606996924059355806d84ab6c95d25368b9b4f09b6c749a2e4b3da41177b for the source RPM.
  3. Run Red Hat Lightspeed patch analysis or an equivalent Satellite/Insights report against RHSA-2026:74581 to enumerate which RHEL 9.6 EUS, Server AUS, Update Services for SAP Solutions, four-years-of-updates and Extended Life Cycle systems still carry a pre-1.18.1-6.el9_6.1 skopeo build.
  4. Prioritise CI/CD runners, build servers and registry mirroring hosts in the patch window, since these are the systems where skopeo copy and skopeo inspect routinely connect to third-party registries over HTTP/2.
  5. Restrict skopeo egress to an allow-list of approved registry endpoints at the proxy or firewall rather than permitting arbitrary outbound registry access, so that a malformed SETTINGS_MAX_FRAME_SIZE frame cannot be served from an unvetted host.
  6. Add alerting for abnormal termination or hang of skopeo processes and for pipeline jobs that fail at the image copy or inspect stage, and treat repeated crashes against a single registry endpoint as worth investigating.
  7. Track Bugzilla 2467815 and CVE-2026-33814 for follow-on Red Hat errata, as the same golang.org/x/net HTTP/2 defect affects other Go-based packages beyond skopeo on the same release.

Source

Code Red Cyber / VTA – coderedcyber.ai