RHSA-2025:22275HighCVSS 8.2

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

Published
December 5, 2025
Last Modified
August 24, 2026

🔗 CVE IDs covered (5)

CVE-2025-31133 →CVE-2025-52565 →CVE-2025-52881 →CVE-2025-4953 →CVE-2025-5318 →

📋 Description

CVE-2025-4953 — podman: Build Context Bind Mount CVE-2025-5318 — libssh: out-of-bounds read in sftp_handle() 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-52881 — runc: opencontainers/selinux: container escape and denial of service due to arbitrary write gadgets and procfs write redirects

🎯 Affected products2

  • Red Hat OpenShift Container Platform 4.13
  • rhcos-x86_64-413.92.202511261311-0 as a component of Red Hat OpenShift Container Platform 4.13

✅ Remediation

For OpenShift Container Platform 4.13 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.13/html/release_notes You may download the oc tool and use it to inspect release image metadata for x86_64, s390x, ppc64le, and aarch64 architectures. The image digests 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:384dcc2b7dde97674e4197b6e4130268adc2b00a94908aa9220a4061aa1030ac All OpenShift Container Platform 4.13 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.13/html-single/updating_clusters/index#updating-cluster-within-minor. Workaround: Avoid long-running build steps and overly permissive file permissions. Use RUN --mount=type=secret for sensitive data instead of bind mounts. Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability. 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: Potential mitigations for this issue include: * Using rootless containers, as doing so will block most of the inadvertent writes (runc would run with reduced privileges, making attempts to write to procfs files ineffective). * Based on our analysis, neither AppArmor or SELinux can protect against the full version of the redirected write attack. The container runtime is generally privileged enough to write to arbitrary procfs files, which is more than sufficient to cause a container breakout.

🔗 References (9)