RHSA-2026:95745CriticalCVSS 9.8

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

Published
November 11, 2026
Last Modified
November 12, 2026

🔗 CVE IDs covered (29)

CVE-2026-86145 →CVE-2026-111497 →CVE-2026-103111 →CVE-2026-16313 →CVE-2026-34182 →CVE-2026-42011 →CVE-2026-45445 →CVE-2026-59999 →CVE-2026-60002 →CVE-2026-28390 →CVE-2026-42013 →CVE-2026-55653 →CVE-2026-98432 →CVE-2026-43114 →CVE-2026-89161 →CVE-2026-64564 →CVE-2026-68121 →CVE-2026-114406 →CVE-2026-59995 →CVE-2026-86138 →CVE-2026-99999 →CVE-2026-45447 →CVE-2026-80792 →CVE-2026-86142 →CVE-2026-89846 →CVE-2025-47273 →CVE-2026-86140 →CVE-2026-86143 →CVE-2026-86144 →

📋 Description

CVE-2025-47273 — setuptools: Path Traversal Vulnerability in setuptools PackageIndex CVE-2026-16313 — sg3_utils: sg3_utils: arbitrary command execution via udev property injection in sg_inq --export CVE-2026-28390 — openssl: OpenSSL: Denial of Service due to NULL pointer dereference in CMS EnvelopedData processing CVE-2026-34182 — openssl: CMS AuthEnvelopedData Processing May Accept Forged Messages CVE-2026-42011 — gnutls: gnutls: Security bypass due to incorrect name constraint handling CVE-2026-42013 — gnutls: gnutls: Certificate validation bypass due to oversized Subject Alternative Name CVE-2026-43114 — kernel: netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry CVE-2026-45445 — openssl: AES-OCB IV Ignored on EVP_Cipher() Path CVE-2026-45447 — openssl: Heap Use-After-Free in OpenSSL PKCS7_verify() CVE-2026-55653 — openssh: Double free in Red Hat Enterprise Linux versions of OpenSSH DH-GEX client path during FIPS known-group validation leads to client-side denial of service CVE-2026-59995 — openssh: OpenSSH: sftp client allows attacker to control downloaded file location CVE-2026-59999 — openssh: OpenSSH sshd: Security bypass due to incorrect handling of forwarding and tunneling options CVE-2026-60002 — openssh: OpenSSH: Use-after-free vulnerability during host key re-exchange on the client side CVE-2026-64564 — kernel: sctp: don't free the ASCONF's own transport in DEL-IP processing CVE-2026-68121 — kernel: pppoe: reload header pointer after dev_hard_header() CVE-2026-80792 — kernel: ipv6: fix use-after-free in ip6_finish_output2() CVE-2026-86138 — libxml2: libxml2: Arbitrary code execution via heap-based buffer overflow CVE-2026-86140 — libxml2: libxml2: Arbitrary code execution via stack-based buffer overflow in xmlSnprintfElements CVE-2026-86142 — libxml2: libxml2: Heap-based buffer overflow in xmlXPtrEval due to xpointer length saturation CVE-2026-86143 — libxml2: libxml2: Data integrity issues due to integer overflow in write callbacks CVE-2026-86144 — libxml2: libxml2: Information disclosure, SSRF, or denial of service due to improper parseFlags propagation. CVE-2026-86145 — pcre2: PCRE2: Out-of-bounds write allows arbitrary code execution via crafted regular expressions CVE-2026-89161 — pcre2: PCRE2: Memory corruption vulnerability in pcre2_jit_match CVE-2026-89846 — kernel: scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read CVE-2026-98432 — kernel: ipv4: free inet_opt and ireq_opt after an RCU grace period CVE-2026-99999 — kernel: ipv4: validate checksum_start before completing checksum CVE-2026-103111 — pcre2: pcre2: Out-of-bounds write via crafted regular expression CVE-2026-111497 — brotli: Out-of-Bounds Write in Google Brotli Decoder CVE-2026-114406 — ca-certificates: Distrust eMudhra intermediate CA certificates due to security concerns

🎯 Affected products2

  • Red Hat OpenShift Container Platform 4.13
  • rhcos-x86_64-413.92.202611041925-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 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:80000563b92e45a91e80d9318811ec2b81d7274b32ddbd5043d306267dd8cd6d 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: 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: 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: Applications that process Cryptographic Message Syntax (CMS) EnvelopedData messages should be configured to only accept input from trusted sources. Restricting network access to services that process untrusted CMS data can also reduce exposure to this Denial of Service vulnerability. Workaround: Systems configured to operate in FIPS mode are not affected by this vulnerability. To mitigate this issue, ensure that OpenSSL is operating in FIPS mode by enabling the system-wide FIPS policy. This may have broader implications for cryptographic operations on the system and should be evaluated for compatibility with existing applications. A system reboot may be required for the changes to take effect. 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: To mitigate this issue, OpenSSH clients operating in FIPS mode should avoid negotiating the `diffie-hellman-group-exchange-sha256` key exchange algorithm. This can be achieved by explicitly listing allowed key exchange algorithms in the client's SSH configuration file (e.g., `/etc/ssh/ssh_config` or `~/.ssh/config`), ensuring `diffie-hellman-group-exchange-sha256` is *not* included. For example, to use a subset of common algorithms, you might configure: ``` KexAlgorithms [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1 ``` (Note: The above example `KexAlgorithms` list is illustrative and should be adjusted based on your environment's security requirements.) Additionally, avoid using non-fatal client flows, such as `ssh-keyscan`, against untrusted SSH servers while FIPS mode is enabled. Changes to `ssh_config` will take effect for new SSH connections. Workaround: To mitigate this issue, avoid using the `sftp server:/path .` command when connecting to untrusted or potentially malicious SFTP servers. Exercise caution and verify the authenticity of SFTP servers before initiating file transfers, especially when using commands that implicitly define the download destination, and also avoid running SFTP sessions with elevated privileges (such as root). Workaround: To mitigate this issue, if `DisableForwarding=yes` is set in `/etc/ssh/sshd_config` to prevent all forwarding, ensure that `PermitTunnel` is explicitly set to `no` in the same configuration file. This will enforce the intended security policy. After modifying `/etc/ssh/sshd_config`, restart the `sshd` service for the changes to take effect. This may temporarily interrupt active SSH sessions. Workaround: To mitigate this issue, OpenSSH clients should only connect to trusted SSH servers. Enforcing strict host key checking and carefully managing `known_hosts` files can help prevent connections to servers with unexpected or altered host keys, thereby reducing exposure to this client-side vulnerability. Workaround: To mitigate this issue, prevent the `sctp` kernel module from loading. Create a file named `/etc/modprobe.d/disable-sctp.conf` with the following content: ``` install sctp /bin/true blacklist sctp ``` After creating the file, regenerate the initramfs and reboot the system for the changes to take effect. Applications or services that rely on the SCTP protocol cannot use this mitigation and should prioritize applying the fix. Workaround: See the security bulletin for a detailed mitigation procedure. Workaround: Bound XML document and QName (prefix + local name) size before intern. Cap process and cgroup memory so a ~4 GiB dictionary pool cannot be built. Keep FORTIFY_SOURCE and heap hardening on Red Hat binaries. Workaround: To mitigate this, administrators should disable DTD processing and validation for untrusted documents within libxml2 parsers and restrict network access so only authorized users can submit XML data to the application. For robust defense-in-depth against buffer overflow exploitation, ensure the library and dependent applications are compiled with memory safety flags like stack canaries (-fstack-protector-strong) and bounds checking (_FORTIFY_SOURCE=2), while verifying that standard OS-level protections such as ASLR and Data Execution Prevention (NX/XD Bit) are active on the host system. Workaround: To mitigate this applications should avoid passing untrusted XPointer expressions into xmlXPtrEval or XInclude xpointer= attributes and strictly cap input length well below INT_MAX. Additionally, administrators should enforce process or cgroup memory limits to prevent the construction of multi-gigabyte scheme bodies, relying on heap allocator hardening rather than standard fortify flags, which cannot stop this byte-store loop. Workaround: Cap process and cgroup memory so a process cannot build a ≥2 GiB libxml2 output backlog. Keep FORTIFY_SOURCE-built Red Hat binaries so some callback copies of the truncated length abort instead of corrupting memory Workaround: Do not expand untrusted XInclude; parse without XML_PARSE_XINCLUDE and do not call xmlXIncludeProcess / xmlXIncludeProcessTree. If XInclude is required, pass XML_PARSE_NONET (and XML_PARSE_NO_XXE where available) via xmlXIncludeProcessFlags, and restrict outbound fetches. Workaround: To mitigate this Improper Protection of Alternate Path vulnerability, ensure that secondary execution branches—such as the reuse of cached memory workspaces—enforce the exact same size and boundary checks as the primary memory allocation paths. Limit exposure by preventing untrusted user input from directly controlling PCRE2 regular expressions, and strictly avoid utilizing recursive matching patterns when operating under a low heap limit. Apply a defense-in-depth strategy by validating all inputs comprehensively. Workaround: If QLogic Fibre Channel HBAs are not in use, the 'qla2xxx' kernel module can be blacklisted to prevent it from loading. This can be achieved by creating a modprobe configuration file. To blacklist the module: 1. Create a file named `/etc/modprobe.d/blacklist-qla2xxx.conf` with the following content: `blacklist qla2xxx` 2. Regenerate the initramfs to ensure the blacklist is applied during boot: `sudo dracut -f -v` (for RHEL 7/8/9) …

🔗 References (32)