OpenShift 4.19.45 security fixes require the full release payload
The update spans RPM packages and container images; Red Hat advises all 4.19 clusters to move to 4.19.45 and provides no general workaround for most flaws.
OpenShift Container Platform 4.19.45 is a split security update: one Red Hat advisory carries RPM packages and another carries the release’s container images. Operators need the complete 4.19.45 payload rather than a hand-picked package update.
RHSA-2026:60452 is rated Important and fixes two package-level issues. The CRI-O fix prevents an /etc/passwd injection path using the HOME environment variable. The Go JOSE libraries fix a denial of service triggered by a crafted JSON Web Encryption object.
RHSA-2026:60454 supplies the container images and identifies four additional CVEs. Red Hat’s image advisory lists the full set of refreshed platform images, including control-plane operators, networking, monitoring, console, OAuth and bare-metal components, but it does not map each CVE to one image in the overview.
What the image CVEs affect
Two flaws are unauthenticated resource-exhaustion paths in Go libraries. CVE-2026-33814 lets a remote peer send an HTTP/2 settings frame that drives the Go transport into an infinite continuation-frame loop. CVE-2026-39829 lets an unauthenticated SSH client submit an oversized RSA or DSA public key and consume CPU during verification.
The higher-impact conditional exposure is CVE-2026-43003 in ironic-python-agent: a malicious partition image can cause code execution when the agent runs grub-install inside that image’s chroot. That matters specifically to bare-metal provisioning workflows that accept or process an attacker-controlled image.
CVE-2026-59869 is a denial of service in js-yaml when an application parses a crafted chain of YAML mappings with merge keys. Red Hat’s CVE page suggests restricting untrusted YAML processing as a way to reduce exposure.
Is there a mitigation short of upgrading?
For the Go HTTP/2, Go SSH and ironic-python-agent flaws, Red Hat says no mitigation is available that meets its criteria for broad, stable deployment. The js-yaml page offers exposure reduction—restrict and validate untrusted YAML—but that is not a replacement for the fixed image. The release advisories therefore tell all OpenShift 4.19 users to upgrade when 4.19.45 is available in their release channel.
What operators should verify
Before starting, confirm the cluster is on the 4.19 minor and that 4.19.45 is offered in the configured channel. Review cluster health and degraded operators, then start the normal OpenShift update rather than updating host RPMs or platform images independently.
After completion, verify that ClusterVersion reports 4.19.45 and that all ClusterOperator resources are Available without Progressing or Degraded conditions. Check MachineConfigPool completion where applicable, and verify bare-metal provisioning and ingress/API availability. Clusters that process untrusted bare-metal images or YAML should treat those workflows as the priority validation paths.
The operational answer is straightforward: there is no extra universal mitigation package for 4.19 operators. Move the cluster to the full 4.19.45 release payload and verify that both node/package changes and refreshed platform images converged.
sources
- RHSA-2026:60452 — OpenShift Container Platform 4.19.45 packages and security updateaccess.redhat.com
- RHSA-2026:60454 — OpenShift Container Platform 4.19.45 images and security updateaccess.redhat.com
- CVE-2026-33814 — Go HTTP/2 denial of serviceaccess.redhat.com
- CVE-2026-39829 — Go SSH public-key denial of serviceaccess.redhat.com
- CVE-2026-43003 — ironic-python-agent image code executionaccess.redhat.com
- CVE-2026-59869 — js-yaml denial of serviceaccess.redhat.com
comments · 0