OpenShift 4.19.44 closes 11 Important-rated security flaws
The asynchronous update addresses code-execution, privilege-escalation, policy-bypass and denial-of-service risks across supported OpenShift 4.19 architectures.
Red Hat has released OpenShift Container Platform 4.19.44 as an asynchronous security and bug-fix update, rating the advisory Important and advising every OpenShift 4.19 user to move to the updated packages and images when they reach the appropriate release channel. The RHSA-2026:57402 advisory, issued August 26, lists 11 vulnerabilities across the release payload.
What changed
The fixes span several layers of the OpenShift host and tooling stack. Red Hat lists a Linux kernel privilege-escalation issue affecting AMD Zen 2 cache isolation, two GnuTLS denial-of-service flaws, and a GnuTLS name-constraints policy bypass. The same advisory also names a systemd issue that can permit arbitrary code execution or denial of service through malformed IPC API data.
Developer and administrative tooling accounts for another part of the update. Three Vim vulnerabilities cover a modeline sandbox bypass, path traversal in the zip plugin and command injection through malicious tag files; a fourth covers command injection while decompressing .tgz archives. Red Hat also includes an out-of-bounds read in the kernel CIFS client and a heap buffer overflow in libsolv’s handling of compressed repository data.
OpenShift 4.19.44 ships updated release images for x86_64, aarch64, ppc64le and s390x. Red Hat points users to a separate RPM advisory for the matching package updates, so administrators should treat the container-image and RPM portions as one maintenance event rather than applying only the release image.
Who is affected
The advisory covers OpenShift Container Platform 4.19 deployments on RHEL 8 and RHEL 9 across x86_64, ARM64, Power and IBM Z/LinuxONE. Exposure to an individual vulnerability depends on the workloads, host hardware and components in use, but the vendor’s instruction is not conditional: all 4.19 users should upgrade.
The mix matters operationally. Some flaws require crafted files or protocol traffic, while the systemd and kernel issues sit below application workloads. Platform teams therefore cannot reduce this release to a single exposed service or application dependency.
What to do
Administrators should monitor the OpenShift update channel, inspect the offered 4.19.44 payload with the oc CLI or web console, and follow Red Hat’s linked cluster-update procedure. The advisory publishes architecture-specific image digests, which can be checked against the release selected for rollout.
Normal OpenShift update discipline still applies: confirm operator and workload health, stage the update where the deployment model permits, and verify nodes and cluster operators after completion. Teams that mirror release content should also make sure both the updated images and associated RPM content are available before scheduling the maintenance window.
sources
comments · 0