RHSA-2026:91232CriticalCVSS 9.1

Red Hat Security Advisory: Red Hat AI Base Images 3.0.7 (CPU)

Published
October 27, 2026
Last Modified
November 2, 2026

🔗 CVE IDs covered (30)

CVE-2026-74860 →CVE-2026-28390 →CVE-2026-59999 →CVE-2026-86144 →CVE-2026-89161 →CVE-2025-8869 →CVE-2025-69418 →CVE-2026-11979 →CVE-2026-55653 →CVE-2026-55655 →CVE-2026-86143 →CVE-2026-86145 →CVE-2026-1703 →CVE-2026-45445 →CVE-2026-60001 →CVE-2026-114406 →CVE-2026-6653 →CVE-2026-59995 →CVE-2026-59996 →CVE-2026-86142 →CVE-2026-103111 →CVE-2025-13327 →CVE-2026-34182 →CVE-2026-45447 →CVE-2026-8643 →CVE-2026-31790 →CVE-2026-86140 →CVE-2026-34183 →CVE-2026-86138 →CVE-2026-13346 →

📋 Description

CVE-2025-8869 — pip: pip missing checks on symbolic link extraction CVE-2025-13327 — uv: uv: Specially crafted ZIP archives lead to arbitrary code execution due to parsing differentials CVE-2025-69418 — openssl: OpenSSL: Information disclosure and data tampering via specific low-level OCB encryption/decryption calls CVE-2026-1703 — pip: pip: Information disclosure via path traversal when installing crafted wheel archives CVE-2026-6653 — libxml2: mingw-libxml2: libxml2: Denial of Service via crafted XML input due to use-after-free CVE-2026-8643 — python-pip: Path traversal via malicious entry point name in pip wheel installation allows arbitrary file overwrite CVE-2026-11979 — libxml2: libxml2: Arbitrary code execution in xmlcatalog utility via buffer overflow CVE-2026-13346 — pip: pip: Arbitrary file installation via malicious package indexes CVE-2026-28390 — openssl: OpenSSL: Denial of Service due to NULL pointer dereference in CMS EnvelopedData processing CVE-2026-31790 — openssl: openssl: Information Disclosure from Uninitialized Memory via Invalid RSA Public Key CVE-2026-34182 — openssl: CMS AuthEnvelopedData Processing May Accept Forged Messages CVE-2026-34183 — openssl: Unbounded Memory Growth in the QUIC PATH_CHALLENGE Handler 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-55655 — openssh: Local MITM of X11 forwarding via abstract UNIX socket pre-binding in Red Hat Enterprise Linux OpenSSH client versions CVE-2026-59995 — openssh: OpenSSH: sftp client allows attacker to control downloaded file location CVE-2026-59996 — openssh: OpenSSH: scp file misplacement vulnerability during remote copy CVE-2026-59999 — openssh: OpenSSH sshd: Security bypass due to incorrect handling of forwarding and tunneling options CVE-2026-60001 — openssh: OpenSSH: Brute-force attacks facilitated due to insufficient authentication delay CVE-2026-74860 — libxml2: double-free/UAF in libxml2 Python bindings 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-103111 — pcre2: pcre2: Out-of-bounds write via crafted regular expression CVE-2026-114406 — ca-certificates: Distrust eMudhra intermediate CA certificates due to security concerns

🎯 Affected products3

  • Red Hat OpenShift AI 3.0
  • registry.redhat.io/rhai/base-image-cpu-rhel9@sha256:51200bbd86f52481b4f45d28766d34646d52f76270b1a0a52a2cfaf2e316e83c_amd64 as a component of Red Hat OpenShift AI 3.0
  • registry.redhat.io/rhai/base-image-cpu-rhel9@sha256:57bc921a05826bb1fa0a48e7baa11c12237ad467fb74b8aa0adf2e8649993825_arm64 as a component of Red Hat OpenShift AI 3.0

✅ Remediation

For more information visit https://access.redhat.com/errata/RHSA-2026:91232 Workaround: Mitigations include upgrading to a version of pip that includes the fix, upgrading to a Python version that implements PEP 706 (Python >=3.9.17, source distributions (sdists) before installation as is already a best-practice. 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: 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. Updating to a fixed version of libxml2 (2.11.0 or later upstream, or a future RHEL errata) will fully resolve this issue. Workaround: To mitigate this issue, users should avoid installing Python wheels from untrusted sources. It is strongly advised against using `pip install` with elevated privileges, such as `sudo`, when installing wheels. Additionally, administrators should inspect `entry_points.txt` within wheels for path separators or absolute paths before installation. 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: 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: To mitigate this vulnerability, apply UDP rate limiting at your network edge to throttle malicious traffic. If QUIC is not strictly required, disable the listener entirely and configure your application to use standard TLS over TCP. Additionally, enforce strict process memory limits using cgroups to prevent host-wide memory exhaustion during an attack. 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 curve25519-sha256@libssh.org,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, disable X11 forwarding on OpenSSH clients when it is not required. This can be achieved by avoiding the use of `-X` or `-Y` options when invoking `ssh`, or by setting `ForwardX11 no` in the SSH client configuration file (`~/.ssh/config` or `/etc/ssh/ssh_config`). Disabling X11 forwarding will prevent the client from attempting to establish X11 connections, thereby removing the attack vector. 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, users should avoid performing `scp` operations directly between two remote destinations. Instead, consider copying files from the first remote host to a local machine, and then from the local machine to the second remote host. Alternatively, use `sftp` or `rsync` for remote file transfers, as these utilities are not affected by this specific vulnerability. 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: 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: See the security bulletin for a detailed mitigation procedure.

🔗 References (34)