RHSA-2026:63044HighCVSS 7.6

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

Published
September 9, 2026
Last Modified
September 14, 2026

🔗 CVE IDs covered (8)

CVE-2026-15816 →CVE-2026-16313 →CVE-2026-50721 →CVE-2026-50722 →CVE-2026-6893 →CVE-2026-12413 →CVE-2026-14164 →CVE-2026-14957 →

📋 Description

CVE-2026-6893 — dracut: dracut: Root code execution via DHCP options command injection CVE-2026-12413 — librenswan: IKEv2 Denial of Service via malformed fragmentation CVE-2026-14164 — libarchive: Double-Free Vulnerability in RAR5 Decompression Logic via dangling filtered_buf pointer in init_unpack() CVE-2026-14957 — libreswan: badly formatted X.509 certificate can cause an assertion failure that crashes the daemon process CVE-2026-15816 — dracut: dracut: root code execution via unescaped error message written to sourced emergency hook script in die() CVE-2026-16313 — sg3_utils: sg3_utils: arbitrary command execution via udev property injection in sg_inq --export CVE-2026-50721 — librenswan: IKEv1 Denial of Service via RSA-SHA1 (PKCS#1 Version 1.5 Encrypted) authentication payload CVE-2026-50722 — librenswan: IKEv2 Denial of Service via RSA-SHA1 (PKCS#1 RSASSA-PKCS1-v1_5) authentication payload

🎯 Affected products5

  • Red Hat OpenShift Container Platform 4.19
  • rhcos-aarch64-4.19.9.6.202609021231-0 as a component of Red Hat OpenShift Container Platform 4.19
  • rhcos-ppc64le-4.19.9.6.202609021231-0 as a component of Red Hat OpenShift Container Platform 4.19
  • rhcos-s390x-4.19.9.6.202609021231-0 as a component of Red Hat OpenShift Container Platform 4.19
  • rhcos-x86_64-4.19.9.6.202609021231-0 as a component of Red Hat OpenShift Container Platform 4.19

✅ Remediation

For OpenShift Container Platform 4.19 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.19/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 values for the release are as follows: (For x86_64 architecture) The image digest is sha256:7c2a7b3f4b11fb7b217f196d8f4e6a3385beb7c15275b941a27249263c60a3bc (For s390x architecture) The image digest is sha256:689909e6a2fc8eac872a9ceeabf4f9ebf1d77551617151a54561fb10f776e010 (For ppc64le architecture) The image digest is sha256:b5bfa7d60cfca5fbf544d025e18b27fe1d98b7425a9fa22808eaa0b483c505a4 (For aarch64 architecture) The image digest is sha256:dfbf625ebb1addd1234392fad233b882ff5e683b2f037ab3a50bf1aabf1541cd All OpenShift Container Platform 4.19 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.19/html-single/updating_clusters/index#updating-cluster-cli. Workaround: To mitigate this issue, ensure that systems configured to obtain network settings via DHCP in the initramfs are only booted on trusted networks. This vulnerability requires an attacker to control a DHCP server on the adjacent network segment. If network configuration via DHCP is not strictly necessary during the initramfs phase, consider using static network configuration. Workaround: If upgrading to Libreswan is not an option, you can mitigate the vulnerability by disabling IKEv2 fragment processing: Add the following directive to your global or connection-specific configuration files in /etc/ipsec.conf: ```fragmentation=no``` Warning: Disabling fragmentation may cause larger IKEv2 payloads (such as those carrying large X.509 certificate chains) to be dropped by intermediate network routers if they exceed the path MTU. Workaround: No mitigation is currently available that meets Red Hat Product Security's standards for usability, deployment, applicability, or stability. Customers are advised to apply the appropriate security update once it becomes available. Workaround: No mitigation is currently available that meets Red Hat Product Security's standards for usability, deployment, applicability, or stability. Customers are advised to apply the appropriate security updates once they become available. Workaround: Restrict DHCP server access on networks used for network boot (DHCP snooping, dedicated/trusted provisioning VLANs) until a fix is available. Workaround: Remove or comment out the REMOVE_CMD rule from 50-udev-default.rules to prevent command execution on device removal. Alternatively, if automatic SCSI device identification is not required, disable the udev rule that invokes sg_inq --export on device connection. Workaround: To mitigate this vulnerability, consider the following strategic workarounds if upgrading Libreswan immediately is not viable: - Migrate to IKEv2: Disable IKEv1 entirely and migrate all connections to IKEv2. The vulnerable code path is tied specifically to IKEv1’s rigid handling of PKCS#1 v1.5 RSA-SHA1. - Switch to Pre-Shared Keys (PSK): Additionally, if the configuration is for static tunnels, and not for a group of Remote Access VPN Clients, the authentication can be changed to use PSK via "authby=secret" after coordination with the remote peer. Workaround: If upgrading to Libreswan is not immediately feasible, this vulnerability can be mitigated by enforcing modern signature algorithms, which effectively prevents Libreswan from falling back to the vulnerable legacy parser logic. Explicitly configure your authby (or leftauth/rightauth) parameters in /etc/ipsec.conf to exclusively permit ECDSA and RSASSA-PSS: ```authby=ecdsa,rsa-sha2``` Note: Applying this mitigation will drop compatibility with native Windows VPN clients that do not support RSASSA-PSS.

🔗 References (12)