OpenShift 4.19.43 closes three Go denial-of-service paths across core binaries

Red Hat’s OpenShift Container Platform 4.19.43 update fixes three remotely triggerable denial-of-service flaws in Go’s standard library. The affected payload is broader than a single operator: the RPM advisory publishes rebuilt OpenShift, client, CRI-O, CRI tools, Skopeo and AWS ECR credential-provider packages, including the Kubernetes API server, controller manager, scheduler and kubelet binaries.

Red Hat rates the advisory Important and tells all OpenShift 4.19 users to move to the updated packages and images when 4.19.43 is available in their release channel.

Three input paths, different exposure

CVE-2026-33811 affects Go’s LookupCNAME when an application uses the cgo DNS resolver. A long CNAME response can trigger a double-free and crash the process. Red Hat scores it 7.5 and says no privileges or user interaction are required. Using the pure-Go resolver through GODEBUG=netdns=go is a temporary mitigation, but it changes resolver behavior and requires process restarts.

CVE-2026-39820 targets net/mail functions that parse addresses, address lists or dates. Crafted email input can consume excessive CPU and memory. CVE-2026-42499 is a second net/mail resource-exhaustion path: pathological addresses trigger quadratic work in phrase parsing. Red Hat lists no generally applicable mitigation for either mail-parser flaw.

The advisory identifies the rebuilt packages but does not provide a per-binary call-path map. That means “included in the payload” should not be read as “every component exposes every parser.” The CNAME issue requires attacker influence over DNS answers seen by a cgo-resolving process; the mail flaws require a reachable path that feeds untrusted strings into the affected net/mail functions. Administrators should prioritize externally reachable cluster services and integrations that ingest identity or notification addresses, while applying the release as a cluster-wide payload rather than attempting component-by-component exceptions.

Upgrade and verify convergence

OpenShift’s update documentation says administrators can inspect offered targets with oc adm upgrade; the Cluster Version Operator then applies the selected release image and waits for operators in each run level to stabilize. The Machine Config Operator subsequently updates node configuration and operating-system content.

Before starting, confirm that 4.19.43 is a recommended target for the cluster’s configured channel and investigate any reported conditional risks. After selecting it, watch oc get clusterversion until the desired version is 4.19.43 and the update is no longer progressing. Then inspect oc get clusteroperators: every operator should be Available, not Progressing and not Degraded. Finally, check machine configuration pools and nodes so a partially rolled node payload does not masquerade as a completed control-plane update.

For disconnected environments, mirror the exact 4.19.43 release payload used for the cluster’s architecture. The RPM advisory points to the matching container-image advisory and release metadata; verification should be against the cluster version and operator state, not just the presence of newer RPM files on an administrative host.