MicroShift 4.16.69 fixes Go privilege-escalation and denial-of-service flaws
The Important-rated update covers a Punycode privilege-escalation issue and three denial-of-service flaws across MicroShift 4.16 packages and images.
Red Hat has released MicroShift 4.16.69, an Important-rated security update for its lightweight OpenShift distribution for edge devices. The Aug. 26 advisory updates the MicroShift RPM set and directs users to a companion advisory for the release’s container images.
What changed
The update fixes four vulnerabilities in Go components used by MicroShift. The highest-consequence issue described by Red Hat is CVE-2026-39821, a privilege-escalation flaw caused by incorrect Punycode label processing in golang.org/x/net/idna.
Three denial-of-service flaws are also included: CVE-2026-33814 in Go’s HTTP/2 handling of malformed SETTINGS_MAX_FRAME_SIZE frames, plus CVE-2026-39820 and CVE-2026-42499 in net/mail parsing of crafted or pathological email input.
Red Hat’s advisory contains the MicroShift 4.16.69 RPMs and points to RHSA-2026:56854 for the corresponding container images. The release is available across x86_64, Arm 64, IBM Power and IBM Z/LinuxONE variants of OpenShift Container Platform 4.16 for RHEL 9.
Who it affects
The update applies to operators running MicroShift 4.16 at the edge. Red Hat rates the advisory Important and explicitly advises all MicroShift 4.16 users to move to the updated packages and images when they are available in the RPM repository.
The Punycode issue is the item to prioritize in change review because Red Hat classifies its impact as privilege escalation. The other three fixes address availability risks rather than code execution.
What to do
MicroShift 4.16 operators should inventory affected edge clusters, apply the 4.16.69 RPM set, and use the companion image advisory to keep package and container-image levels aligned. Red Hat also links the advisory to its Lightspeed patch analysis for identifying affected systems.
Teams should validate the update through their normal edge rollout path before broad deployment, with particular attention to networking and workload availability after the package-and-image update. The advisory does not describe a configuration workaround, so patching is the direct remediation path.
sources
comments · 0