RHSA-2026:94802CriticalCVSS 8.2

Red Hat Security Advisory: A Subscription Management tool for finding and reporting Red Hat product usage

Published
November 4, 2026
Last Modified
November 12, 2026

🔗 CVE IDs covered (19)

CVE-2026-60000 →CVE-2026-97687 →CVE-2026-97689 →CVE-2026-111497 →CVE-2026-8932 →CVE-2026-88806 →CVE-2026-114136 →CVE-2026-114406 →CVE-2026-118669 →CVE-2026-19553 →CVE-2026-102633 →CVE-2026-114137 →CVE-2026-59998 →CVE-2026-77214 →CVE-2026-114138 →CVE-2026-12345 →CVE-2026-19445 →CVE-2026-34743 →CVE-2026-59997 →

📋 Description

CVE-2026-8932 — libcurl: libcurl: Security feature bypass due to improper mTLS connection reuse CVE-2026-12345 — python: python: Arbitrary file deletion via race condition during temporary directory cleanup CVE-2026-19445 — python: Use-after-free of a server-side SSLContext when sni_callback switches contexts CVE-2026-19553 — python: python: Certificate verification bypass via missing server_hostname validation in SSLContext.wrap_bio() CVE-2026-34743 — xz: XZ Utils: Denial of Service via buffer overflow in index decoding CVE-2026-59997 — openssh: OpenSSH: SFTP security bypass due to command-line argument parsing flaw CVE-2026-59998 — openssh: OpenSSH: Undocumented GSSAPIStrictAcceptorCheck behavior impacts security in Windows Active Directory CVE-2026-60000 — openssh: OpenSSH: Denial of Service via excessive GSSAPI authentication attempts CVE-2026-77214 — expat: expat: Information disclosure via heap buffer over-read in XML_ParseBuffer CVE-2026-88806 — libX11: libX11: Heap-based buffer overflow via malicious X server CVE-2026-97687 — urllib3: urllib3: Traffic interception via HTTPS proxy TLS configuration override CVE-2026-97689 — urllib3: urllib3: Denial of Service via unbounded memory allocation in chunk parser CVE-2026-102633 — expat: expat: Denial of Service via integer overflow in expat_realloc CVE-2026-111497 — brotli: Out-of-Bounds Write in Google Brotli Decoder CVE-2026-114136 — djangorestframework: djangorestframework: Denial of Service via improper charset handling in JSON parser CVE-2026-114137 — djangorestframework: djangorestframework: Unauthorized access via improper token revocation in TokenProxy CVE-2026-114138 — djangorestframework: djangorestframework: Denial of Service via unbounded Accept header parsing CVE-2026-114406 — ca-certificates: Distrust eMudhra intermediate CA certificates due to security concerns CVE-2026-118669 — oauthlib: oauthlib: privilege escalation via client identity confusion in token grant handlers

🎯 Affected products5

  • Red Hat Discovery 2
  • registry.redhat.io/discovery/discovery-server-rhel9@sha256:ca92ccbc631ef611a3bdb41ce782955ec386ebe150a8cdaefadc1237f6b79ba0_amd64 as a component of Red Hat Discovery 2
  • registry.redhat.io/discovery/discovery-server-rhel9@sha256:f61cac028ee7bb6606b6baad72ed5018bf80622422308279d27669c259de5d73_arm64 as a component of Red Hat Discovery 2
  • registry.redhat.io/discovery/discovery-ui-rhel9@sha256:2348157c3e6fbea084390c0bee502b8efecad3387b97cdca790e8ee725b93ce0_arm64 as a component of Red Hat Discovery 2
  • registry.redhat.io/discovery/discovery-ui-rhel9@sha256:84419ba38b148dfd0faf60bc6a604f1cb85878854520bf59f0514acc6e0fb49e_amd64 as a component of Red Hat Discovery 2

✅ Remediation

The containers required to run Discovery can be installed through discoveryctl RPM. See the official documentation for more details. 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, ensure kernel symlink protection is enabled (active by default in RHEL) by verifying sysctl fs.protected_symlinks is set to 1. Additionally, restrict exposure on shared systems by setting the TMPDIR environment variable to a secure, user-private directory rather than a public shared path (e.g., export TMPDIR=/path/to/private_tmp). Workaround: Restrict Python TLS servers that use SSLContext.sni_callback to trusted clients. Keep a strong reference to every SSLContext that registers an SNI callback for the lifetime of the server so the original context cannot be garbage-collected while connections remain open. Prefer wrapping the listening socket with a long-lived SSLContext; that common pattern is not affected. Host heap allocator hardening increases the difficulty of turning the use-after-free into reliable code execution but does not prevent process crashes. Workaround: Restrict Python TLS clients to trusted networks so an on-path attacker cannot intercept sessions. Applications that use SSLContext.wrap_bio(), asyncio.create_connection(), or loop.start_tls() with check_hostname enabled must pass a non-empty server_hostname; hostname verification then proceeds and this flaw is not reachable. Optionally pin expected server certificates so a mismatched host certificate is rejected even if hostname checking is skipped. Workaround: To mitigate this issue, ensure that all security-relevant command-line arguments for the `internal-sftp` server are positioned within the first nine arguments. Alternatively, consider using the default SFTP server implementation if custom configurations relying on numerous arguments are not strictly necessary. If `internal-sftp` is used with more than nine arguments, verify that no critical security options are being silently discarded. Workaround: To mitigate this issue, avoid using GSSAPI authentication for `sshd` when the server is integrated with a Windows Active Directory environment. If GSSAPI authentication is not strictly required, it can be disabled by setting `GSSAPIAuthentication no` in the `/etc/ssh/sshd_config` file. After modifying the configuration, the `sshd` service must be restarted for the changes to take effect. Note that restarting the `sshd` service will terminate all active SSH sessions. ```bash # echo "GSSAPIAuthentication no" >> /etc/ssh/sshd_config # systemctl restart sshd ``` Alternatively, if GSSAPI authentication is necessary in such an environment, ensure that the network path between the client and the `sshd` server, and to the Active Directory, is secured and trusted to prevent man-in-the-middle attacks. Workaround: To mitigate this issue, users should avoid connecting to untrusted X servers. When using SSH, ensure that X11 forwarding (`ssh -X` or `ssh -Y`) is only enabled for trusted remote hosts. To prevent X11 forwarding for specific hosts, add `ForwardX11 no` to the relevant host entry in `~/.ssh/config` or `/etc/ssh/ssh_config`. Alternatively, disable X11 forwarding globally by setting `ForwardX11 no` in `/etc/ssh/ssh_config`. 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: See the security bulletin for a detailed mitigation procedure.

🔗 References (23)