RHSA-2026:6492HighCVSS 8.2

Red Hat Security Advisory: OpenShift Container Platform 4.12.87 bug fix and security update

Published
April 9, 2026
Last Modified
September 1, 2026

🔗 CVE IDs covered (3)

CVE-2025-52565 →CVE-2025-61662 →CVE-2025-31133 →

📋 Description

CVE-2025-31133 — runc: container escape via 'masked path' abuse due to mount race conditions CVE-2025-52565 — runc: container escape with malicious config due to /dev/console mount and related races CVE-2025-61662 — grub2: Missing unregister call for gettext command may lead to use-after-free

🎯 Affected products2

  • Red Hat OpenShift Container Platform 4.12
  • rhcos-x86_64-412.86.202604010116-0 as a component of Red Hat OpenShift Container Platform 4.12

✅ Remediation

For OpenShift Container Platform 4.12 see the following documentation, which will be updated shortly for this release, for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.redhat.com/en/documentation/openshift_container_platform/4.12/html/release_notes You may download the oc tool and use it to inspect release image metadata for x86_64 architecture. The image digest may be found at https://quay.io/repository/openshift-release-dev/ocp-release?tab=tags. The sha value for the release is as follows: (For x86_64 architecture) The image digest is sha256:4e989978ab0e24d7148f08e939800502370b761efea1005d87522884d1a3f595 All OpenShift Container Platform 4.12 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift CLI (oc) or web console. Instructions for upgrading a cluster are available at https://docs.redhat.com/en/documentation/openshift_container_platform/4.12/html-single/updating_clusters/index#updating-cluster-within-minor. Workaround: Potential mitigations for this issue include: * Using user namespaces, with the host root user not mapped into the container's namespace. procfs file permissions are managed using Unix DAC and thus user namespaces stop a container process from being able to write to them. * Not running as a root user in the container (this includes disabling setuid binaries with noNewPrivileges). As above, procfs file permissions are managed using Unix DAC and thus non-root users cannot write to them. * Depending on the maskedPath configuration (the default configuratio nonly masks paths in /proc and /sys), using an AppArmor that blocks unexpectedwrites to any maskedPaths (as is the case with the defaultprofile used by Docker and Podman) will block attempts to exploit this issue. However, CVE-2025-52881 allows an attacker to bypass LSMlabels, and so this mitigation is not helpful when considered incombination with CVE-2025-52881. Workaround: Potential mitigations for this issue include: * Using user namespaces, with the host root user not mapped into the container's namespace. procfs file permissions are managed using Unix DAC and thus user namespaces stop a container process from being able to write to them. * Not running as a root user in the container (this includes disabling setuid binaries with noNewPrivileges). As above, procfs file permissions are managed using Unix DAC and thus non-root users cannot write to them. * The default SELinux policy should mitigate this issue, as the /dev/console bind-mount does not re-label the mount and so the container process should not be able to write to unsafe procfs files. However, CVE-2025-52881 allows an attacker to bypass LSM labels, and so this mitigation is not helpful when considered in combination with CVE-2025-52881. * The default AppArmor profile used by most runtimes will NOT help mitigate this issue, as /dev/console access is permitted. You could create a custom profile that blocks access to /dev/console, but such a profile might break regular containers. In addition, CVE-2025-52881 allows an attacker to bypass LSM labels, and so that mitigation is not helpful when considered in combination with CVE-2025-52881. Workaround: There's no known mitigation available for this vulnerability.

🔗 References (6)