OpenShift 4.17.57 patches TLS validation and Go denial-of-service flaws
Red Hat rates the asynchronous update Important and tells 4.17 operators to apply both its package and container-image payloads.
Red Hat has shipped OpenShift Container Platform 4.17.57 as an asynchronous security update, with fixes split across an RPM advisory and a companion container-image advisory. The company rates the package advisory Important and advises every OpenShift 4.17 operator to move to the updated payload when it reaches the appropriate release channel.
What changed
The package advisory names seven vulnerabilities in Go libraries used by OpenShift components. The most consequential is CVE-2025-68121, an incorrect certificate-validation condition during TLS session resumption. The remaining fixes address an IPv6 host-literal parsing error and denial-of-service paths in certificate-chain construction, CNAME lookup, email-address parsing and MIME-header handling.
Red Hat’s advisory covers OpenShift 4.17 deployments on x86_64, Arm64, IBM Power, and IBM Z and LinuxONE. It points to RHSA-2026:60023 for the matching container images, which include refreshed control-plane, networking, storage, monitoring and installer components. That split matters operationally: administrators should treat the release payload as a unit rather than assuming that installing only the listed RPMs completes remediation.
Who is affected
The update applies to clusters that remain on the 4.17 stream. Exposure depends on which OpenShift services exercise the affected Go packages and whether an attacker can supply the crafted network, certificate, email or MIME input required by a particular flaw. Red Hat nevertheless recommends the update for all 4.17 users rather than limiting it to a narrower configuration.
The TLS-session-resumption issue deserves particular attention because it concerns certificate validation, while several other CVEs can consume resources through deliberately pathological input. The advisory does not describe a configuration-only mitigation that substitutes for installing the update.
What operators should do
Platform teams should check the OpenShift update graph with the web console or oc, confirm that 4.17.57 is offered in the cluster’s channel, and schedule the normal cluster-update process. Before proceeding, they should verify that earlier applicable errata are installed and that workload owners are prepared for the usual node and control-plane rollout.
After the update, operators should confirm that the ClusterVersion reports 4.17.57 and that all cluster operators return to an available, non-degraded state. Teams that mirror release content into disconnected environments should ensure the complete 4.17.57 image set is present; the companion image advisory is part of the remediation, not optional background detail.
sources
comments · 0