OpenShift 4.22.9 security update reaches cluster control-plane and developer workflows
Red Hat rates the asynchronous update Important; 4.22 users need both the updated images and RPM packages from the supported release channel.
Red Hat has classified the OpenShift Container Platform 4.22.9 asynchronous update as Important, and the practical unit of remediation is the cluster release—not an isolated package. The container-image advisory lists nine CVEs and tells all OpenShift 4.22 users to take the update through an appropriate release channel. A paired RPM advisory supplies the host and control-plane packages needed to complete that update.
What is affected
The RPM payload reaches core Kubernetes and OpenShift components: openshift-kube-apiserver, openshift-kube-controller-manager, openshift-kube-scheduler, openshift-kubelet and openshift-hyperkube, alongside the RHEL kernel packages shipped for OpenShift 4.22. That makes this more than a console-only correction; it crosses API handling, scheduling, node execution and the operating-system layer.
Red Hat identifies two package-side flaws in golang.org/x/crypto/ssh: a denial of service through a crafted SSH certificate (CVE-2026-39835) and another through crafted AES-GCM packet-decoder input (CVE-2026-46597). The container advisory carries seven additional CVEs in the release image set.
The same 4.22.9 payload also fixes defects that developers and platform teams can encounter directly. Red Hat’s issue list includes an OpenShift console pod terminal that does not show a shell prompt until the browser is resized, missing image SHAs in oc-mirror logs, an IBM Cloud installation failure that degrades ingress, an installation deadlock around ManagementCPUsOverride, and FRR-K8s pods entering CrashLoopBackOff at very large routing scale. Those bug fixes are not the reason for the Important rating, but they widen the operational case for testing and adopting the release.
The supported update path
Administrators should not try to reconstruct the fix by replacing individual images. Red Hat publishes architecture-specific release-image digests for x86_64, s390x, ppc64le and aarch64, and directs 4.22 users to check the available update in the OpenShift CLI or web console. The paired advisories divide the payload between release images and RPMs; consuming 4.22.9 from the supported channel applies them as a tested cluster update.
Platform teams should confirm that 4.22.9 is offered on the cluster’s channel, review update preconditions and run the normal staging or canary path before production. Disconnected operators should also verify that the 4.22.9 release payload—and not merely a subset of component images—has been mirrored.
Why this warrants action
An Important Red Hat advisory signals a security impact above routine defect correction, while the affected packages sit in paths every workload depends on. The two documented SSH parser flaws are denial-of-service issues, and the broader image advisory spans nine CVEs. For application teams, the most useful response is not a component-by-component workaround: it is to ask the cluster owner when 4.22.9 will be validated and promoted, and to retest deployment, console-terminal, ingress and image-mirroring workflows against that build.
sources
- RHSA-2026:51038 — OpenShift Container Platform 4.22.9 container imagesaccess.redhat.com
- RHSA-2026:51036 — OpenShift Container Platform 4.22.9 RPM packagesaccess.redhat.com
comments · 0