RHSA-2026:1736HighCVSS 9.8

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

Published
February 2, 2026
Last Modified
August 31, 2026

🔗 CVE IDs covered (21)

CVE-2025-9086 →CVE-2025-12818 →CVE-2025-15467 →CVE-2025-15468 →CVE-2025-66199 →CVE-2025-69421 →CVE-2026-21441 →CVE-2025-11187 →CVE-2025-12084 →CVE-2025-15469 →CVE-2025-66418 →CVE-2026-22795 →CVE-2025-13836 →CVE-2025-68160 →CVE-2025-69418 →CVE-2026-22796 →CVE-2025-13601 →CVE-2025-66471 →CVE-2025-68973 →CVE-2025-69419 →CVE-2025-69420 →

📋 Description

CVE-2025-9086 — curl: libcurl: Curl out of bounds read for cookie path CVE-2025-11187 — openssl: OpenSSL: Arbitrary code execution or denial of service through crafted PKCS#12 file CVE-2025-12084 — cpython: python: cpython: Quadratic algorithm in xml.dom.minidom leads to denial of service CVE-2025-12818 — postgresql: libpq: libpq undersizes allocations, via integer wraparound CVE-2025-13601 — glib: Integer overflow in in g_escape_uri_string() CVE-2025-13836 — cpython: Excessive read buffering DoS in http.client CVE-2025-15467 — openssl: OpenSSL: Remote code execution or Denial of Service via oversized Initialization Vector in CMS parsing CVE-2025-15468 — openssl: OpenSSL: Denial of Service via NULL pointer dereference in QUIC protocol handling CVE-2025-15469 — openssl: OpenSSL: Data integrity bypass in openssl dgst command due to silent truncation CVE-2025-66199 — openssl: OpenSSL: Denial of Service due to excessive memory allocation in TLS 1.3 certificate compression CVE-2025-66418 — urllib3: urllib3: Unbounded decompression chain leads to resource exhaustion CVE-2025-66471 — urllib3: urllib3 Streaming API improperly handles highly compressed data CVE-2025-68160 — openssl: OpenSSL: Denial of Service due to out-of-bounds write in BIO filter CVE-2025-68973 — GnuPG: GnuPG: Information disclosure and potential arbitrary code execution via out-of-bounds write CVE-2025-69418 — openssl: OpenSSL: Information disclosure and data tampering via specific low-level OCB encryption/decryption calls CVE-2025-69419 — openssl: OpenSSL: Arbitrary code execution due to out-of-bounds write in PKCS#12 processing CVE-2025-69420 — openssl: OpenSSL: Denial of Service via malformed TimeStamp Response CVE-2025-69421 — openssl: OpenSSL: Denial of Service via malformed PKCS#12 file processing CVE-2026-21441 — urllib3: urllib3 vulnerable to decompression-bomb safeguard bypass when following HTTP redirects (streaming API) CVE-2026-22795 — openssl: OpenSSL: Denial of Service due to type confusion in PKCS#12 file processing CVE-2026-22796 — openssl: OpenSSL: Denial of Service via type confusion in PKCS#7 signature verification

🎯 Affected products5

  • Red Hat Discovery 2
  • registry.redhat.io/discovery/discovery-server-rhel9@sha256:519d4fe184cebe5152f840e9f609fa4705590656ac9bcace2e2e17622ab7e6a8_arm64 as a component of Red Hat Discovery 2
  • registry.redhat.io/discovery/discovery-server-rhel9@sha256:d4d6cd6b1a84587ee851c4f76b47c1e6bf9f597f4a476c34e4a257cd1a860448_amd64 as a component of Red Hat Discovery 2
  • registry.redhat.io/discovery/discovery-ui-rhel9@sha256:26bb49a8e2e695d61192f04eb0db63efa8210bba20ea22b60e4e22d519d8b9e6_amd64 as a component of Red Hat Discovery 2
  • registry.redhat.io/discovery/discovery-ui-rhel9@sha256:4ba29e3e7565cfdfdedcc558bc8495398cee07742fda133b0bc04fd657b908cd_arm64 as a component of Red Hat Discovery 2

✅ Remediation

The containers required to run Discovery can be installed through discovery-installer 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, avoid processing untrusted PKCS#12 files. Applications should only handle PKCS#12 files from trusted sources, as these files are typically used for storing private keys and are expected to be secure. 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: No mitigation is currently available that meets Red Hat Product Security’s standards for usability, deployment, applicability, or stability. Workaround: Since this vulnerability is triggered when no read amount is specified and the client defaults to using the potentially malicious Content-Length header, developers can mitigate this issue in their code by always imposing an explicit, safe limit on data reads. Applications using the http.client.HTTPResponse.read function directly can ensure that read operations specify a byte limit: ~~~ ... max_safe_read = 10 * 1024 * 1024 data = response.read(max_safe_read) ... ~~~ Workaround: To mitigate this issue, avoid using the `openssl dgst` command with one-shot algorithms (such as Ed25519, Ed448, or ML-DSA) for files larger than 16MB. Instead, utilize streaming digest algorithms with `openssl dgst` or use library APIs for signing and verification, as these are not affected by the truncation vulnerability. Users should ensure that input files for one-shot signing/verification with `openssl dgst` do not exceed 16MB. Workaround: To mitigate this issue, disable the reception of compressed certificates by setting the SSL_OP_NO_RX_CERTIFICATE_COMPRESSION option in OpenSSL configurations. This will prevent the vulnerable code path from being exercised. Workaround: To mitigate this issue, users should avoid processing untrusted or unverified input with GnuPG. Exercise caution when handling GnuPG-encrypted or signed data from unknown or suspicious sources, as specially crafted input could trigger the vulnerability. This operational control reduces the attack surface by limiting exposure to malicious data. Workaround: To mitigate this vulnerability, Red Hat recommends avoiding the processing of PKCS#12 files from untrusted or unverified sources. Applications that use the `PKCS12_get_friendlyname()` API should ensure that PKCS#12 files are only processed if they originate from trusted entities. Restricting the input sources for PKCS#12 files can significantly reduce the attack surface for this flaw. Workaround: Restrict applications from processing untrusted or externally supplied PKCS#12 files, ensuring certificates are sourced only from trusted internal authorities. Additionally, configure critical background services with automatic restart policies (such as systemd's Restart=on-failure) to quickly restore availability if a denial-of-service crash occurs.

🔗 References (25)