RHSA-2026:95611HighCVSS 7.9

Red Hat Security Advisory: Red Hat Hardened Images RPMs Security Update

Published
November 5, 2026
Last Modified
November 6, 2026

🔗 CVE IDs covered (2)

CVE-2026-121520 →CVE-2026-121522 →

📋 Description

CVE-2026-121520 — github.com/moby/buildkit: BuildKit: Privilege escalation via unauthorized extended file attribute modification CVE-2026-121522 — github.com/moby/buildkit: BuildKit: Denial of Service via duplicate Git source metadata resolution

🎯 Affected products16

  • Red Hat Hardened Images
  • podman-5:6.1.4-1.3.hum1@aarch64 as a component of Red Hat Hardened Images
  • podman-5:6.1.4-1.3.hum1@s390x as a component of Red Hat Hardened Images
  • podman-5:6.1.4-1.3.hum1@src as a component of Red Hat Hardened Images
  • podman-5:6.1.4-1.3.hum1@x86_64 as a component of Red Hat Hardened Images
  • podman-docker-5:6.1.4-1.3.hum1@noarch@public-hummingbird-aarch64-rpms as a component of Red Hat Hardened Images
  • podman-docker-5:6.1.4-1.3.hum1@noarch@public-hummingbird-s390x-rpms as a component of Red Hat Hardened Images
  • podman-docker-5:6.1.4-1.3.hum1@noarch@public-hummingbird-x86_64-rpms as a component of Red Hat Hardened Images
  • podman-machine-5:6.1.4-1.3.hum1@aarch64 as a component of Red Hat Hardened Images
  • podman-machine-5:6.1.4-1.3.hum1@x86_64 as a component of Red Hat Hardened Images
  • podman-remote-5:6.1.4-1.3.hum1@aarch64 as a component of Red Hat Hardened Images
  • podman-remote-5:6.1.4-1.3.hum1@s390x as a component of Red Hat Hardened Images
  • podman-remote-5:6.1.4-1.3.hum1@x86_64 as a component of Red Hat Hardened Images
  • podmansh-5:6.1.4-1.3.hum1@aarch64 as a component of Red Hat Hardened Images
  • podmansh-5:6.1.4-1.3.hum1@s390x as a component of Red Hat Hardened Images
  • podmansh-5:6.1.4-1.3.hum1@x86_64 as a component of Red Hat Hardened Images

✅ Remediation

For details on how to apply this update, which includes the changes described in this advisory, refer to: https://images.redhat.com/ Workaround: Restrict access to the BuildKit control API socket and network endpoints to trusted administrative operators using strict file system permissions and mutual TLS. In multi-tenant environments, isolate build execution within dedicated, ephemeral virtual machines rather than sharing the daemon across untrusted tenants. --- CME Mitigation Guidance (2026-11-04) --- Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from https://cmetaxonomy.org. Customers are advised to independently evaluate and test these temporary mitigations within their own infrastructure. The highest-value action is to confine all extended attribute modifications within BuildKit strictly to the internal state directory and prevent following symlinks outside the build boundary: upgrade to BuildKit v0.34.1 (or the corresponding fixed Red Hat builds), which restrict extended attribute modifications to the BuildKit state directory and prevent following links outside the build boundary, closing all 3 injection vectors (crafted build request submitting xattrs targeting paths outside the state directory, symbolic link traversal targeting host files for extended attribute modification, manipulation of security and trusted namespace extended attributes). Until patched, this is only a concern on Linux build hosts and multi-tenant build services accepting BuildKit control API requests — Non-Linux platforms are unaffected — so Restrict access to the BuildKit control API socket and network endpoints to trusted operators using strict permissions and mutual TLS, or isolate builds in dedicated ephemeral virtual machines. As a compensating measure, Log setxattr and lsetxattr syscalls targeting sensitive host directories and security namespaces using auditd, Enforce SELinux mandatory access controls to confine the BuildKit daemon from modifying host extended attributes outside its domain, Restrict the BuildKit process filesystem sandbox to explicitly allowed directory hierarchies using Landlock LSM, Use mount and user namespaces to isolate the daemon filesystem view from host extended attribute modifications, Run BuildKit in rootless mode to prevent setting privileged security and trusted namespace extended attributes on the host filesystem, and Drop CAP_SYS_ADMIN and CAP_SETFCAP from the BuildKit daemon to prevent setting sensitive extended attributes. These controls limit blast radius and contain exploitation, but they do not fix the underlying path traversal and symlink following defect — apply the upstream patch to fully remediate. Highest-impact CME: CME-1301 Path Traversal Prevention (Canonicalization) (high) Workaround: Restrict build submission permissions to trusted users and avoid building untrusted definitions or repositories on shared daemon instances. In multi-tenant environments, isolate BuildKit daemon instances per workload to prevent daemon-level crashes from impacting concurrent builds.

🔗 References (6)