RHSA-2026:61783HighCVSS 8.6

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

Published
August 31, 2026
Last Modified
September 11, 2026

🔗 CVE IDs covered (42)

📋 Description

CVE-2024-29180 — webpack-dev-middleware: lack of URL validation may lead to file leak CVE-2026-1965 — curl: curl: Authentication bypass due to incorrect connection reuse with Negotiate authentication CVE-2026-3783 — curl: curl: Information disclosure via OAuth2 bearer token leakage during HTTP(S) redirect CVE-2026-5704 — tar: tar: Hidden file injection via crafted archives CVE-2026-6322 — fast-uri: fast-uri: URI authority bypass due to improper delimiter handling CVE-2026-6653 — libxml2: mingw-libxml2: libxml2: Denial of Service via crafted XML input due to use-after-free CVE-2026-8286 — curl: curl: Insecure connection establishment due to TLS configuration mismatch CVE-2026-9547 — curl: curl: Man-in-the-middle attack via SSH host key bypass CVE-2026-11822 — sqlite: SQLite: Arbitrary code execution via crafted FTS5 full-text search data CVE-2026-11824 — sqlite: SQLite: Arbitrary code execution and crash via heap-based buffer overflow in FTS5 CVE-2026-11979 — libxml2: libxml2: Arbitrary code execution in xmlcatalog utility via buffer overflow CVE-2026-14164 — libarchive: Double-Free Vulnerability in RAR5 Decompression Logic via dangling filtered_buf pointer in init_unpack() CVE-2026-15588 — GDBusServer: glib2: GDBusServer pre-authentication DoS via unbounded SASL line buffering CVE-2026-18477 — tar: tar: TOCTOU in incremental dumpdir 'X' rename handling allows restore path escape CVE-2026-18508 — tar: tar: --one-top-level hardlink targets not confined to top-level directory enabling arbitrary file overwrite CVE-2026-41991 — gzip: gzip: Arbitrary file overwrite via insecure temporary file handling in gzexe utility CVE-2026-41992 — gzip: gzip: Information disclosure via global buffer overflow in LZH decompression CVE-2026-45409 — python-idna: idna: Denial of Service via specially crafted long inputs CVE-2026-45623 — postcss: PostCSS: Information disclosure and denial of service via crafted CSS input CVE-2026-54284 — sqlparse: sqlparse: Denial of Service via quadratic CPU consumption in SQL parsing CVE-2026-54371 — attr: attr: Symlink Traversal Privilege Escalation via getfattr and setfattr CVE-2026-56434 — nginx: NGINX: Heap buffer over-read allows memory modification or denial of service CVE-2026-58010 — glib: buffer over-read in glib/gvariant-serialiser.c via gvs_tuple_is_normal() CVE-2026-58011 — glib: out-of-bounds read in glib/gdatetime.c:g_date_time_get_ymd via invalid GDateTime CVE-2026-58012 — glib: buffer over-read in g_regex_replace() via glib/gregex.c:string_append() and g_utf8_next_char() CVE-2026-58013 — glib: buffer over-read in glib/giochannel.c via "g_io_channel_read_line_backend" CVE-2026-58014 — glib: off-by-one error in glib/gkeyfile.c via "g_key_file_get_locale_string_list" CVE-2026-58015 — glib: path traversal in glib/gio/gdbusauthmechanismsha1.c via keyring_lookup_entry and mechanism_client_data_receive CVE-2026-58055 — nghttp2: nghttp2: HTTP Request/Response Smuggling and Response-Queue Poisoning via ambiguous HTTP/1.1 Upgrade requests CVE-2026-59868 — js-yaml: js-yaml: Denial of Service via quadratic CPU time parsing with merge keys CVE-2026-59869 — js-yaml: js-yaml: Denial of Service via crafted YAML documents CVE-2026-59893 — sqlparse: sqlparse: Denial of Service via inefficient SQL parsing CVE-2026-60005 — nginx: NGINX: Memory disclosure and denial of service in ngx_http_slice_module CVE-2026-67213 — nanoid: nanoid: Denial of Service via infinite loop in random ID generation CVE-2026-67214 — nanoid: nanoid: Denial of Service via negative size input in non-secure module functions CVE-2026-71491 — sqlparse: sqlparse: Denial of Service via quadratic CPU consumption in comment grouping CVE-2026-73643 — js-yaml: js-yaml: Denial of Service via exponential parsing in flow collections CVE-2026-75899 — fast-uri: fast-uri: Server-Side Request Forgery via repeated hostname percent-decoding CVE-2026-75931 — fast-uri: fast-uri: Host confusion via skipped IDN canonicalization CVE-2026-75975 — fast-uri: fast-uri: Server-side request forgery via malformed IPv6 normalization CVE-2026-76172 — fast-uri: fast-uri: URI parsing flaw enables server-side request forgery and redirects CVE-2026-76844 — webpack-dev-middleware: webpack-dev-middleware: Information Disclosure via Path Traversal

🎯 Affected products5

  • Red Hat Discovery 2
  • registry.redhat.io/discovery/discovery-server-rhel9@sha256:5efae8059c9c15454abac947b8482412686d60aaf5c104557d463e8282e340af_amd64 as a component of Red Hat Discovery 2
  • registry.redhat.io/discovery/discovery-server-rhel9@sha256:e9592a7aa5db3a61a7248d7b0305f3eb2fae189b1d078e483f1cc439f5b2351d_arm64 as a component of Red Hat Discovery 2
  • registry.redhat.io/discovery/discovery-ui-rhel9@sha256:480c69f89b45c714ec13a7901bc8615a2fa3f4622c889cd023d80a6278855a58_arm64 as a component of Red Hat Discovery 2
  • registry.redhat.io/discovery/discovery-ui-rhel9@sha256:def96951197558d6c5d1784a7971b0e37b44025c60d9b59fe6797085e39c382a_amd64 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 don't 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. Workaround: To prevent the leakage of OAuth2 bearer tokens, ensure that `.netrc` files are carefully managed. Avoid configuring `.netrc` entries for untrusted or unknown hostnames, particularly when `curl` is used with OAuth2 bearer tokens and is configured to follow redirects. Regularly review and restrict the scope of credentials stored in `.netrc` files to only explicitly trusted destinations. Workaround: To mitigate this issue, avoid extracting archives from untrusted sources. If processing untrusted archives is necessary, do so within a sandboxed environment to limit potential impact. 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: 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. Customers are advised to apply the appropriate security update once it becomes available. Workaround: Do not perform incremental restores (-G/-g) from untrusted archives. Avoid restoring incremental backups on systems where untrusted users have shell access,​ perform restoration only on systems inaccessible to users. Workaround: Do not use --one-top-level as the sole confinement mechanism when extracting untrusted archives. Prefer extracting as an unprivileged user into a freshly created empty directory after changing into that directory (mkdir and cd), avoid extracting as root from sensitive working directories such as /, and follow the GNU tar security guidance for untrusted archives. Workaround: Ensure that the mktemp utility (provided by the coreutils package) is available in PATH when using the gzexe utility. On Red Hat Enterprise Linux, mktemp is installed by default and no additional action is needed. Workaround: To mitigate this denial-of-service vulnerability, applications utilizing the `idna` Python library should implement input validation to ensure that domain names do not exceed the standard 253-character length limit before being passed to the `idna.encode()` function. This operational control prevents the processing of excessively long inputs that could lead to resource exhaustion and service unavailability. Applications that pass user-controlled data directly to `idna.encode()` without validation checks (e.g.: DNS length < 254 chars) are affected. Workaround: To prevent exploitation, avoid configuring NGINX with `ngx_http_ssi_module` when `proxy_pass` and `proxy_buffering off` are simultaneously active. If Server-Side Includes (SSI) are not essential, disable the `ngx_http_ssi_module` by removing or commenting out the `ssi on;` directive. Alternatively, ensure `proxy_buffering` is explicitly enabled (`proxy_buffering on;`) when `proxy_pass` is used with SSI. A reload or restart of the NGINX service is necessary for configuration changes to apply, which may cause a brief service interruption. Workaround: To mitigate this vulnerability, in applications processing user-supplied dates, implement input validation to ensure the supplied date is within the supported range before calling g_date_time_add_full() with untrusted data, specifically rejecting inputs that result in a negative or zero days field. Workaround: To mitigate this vulnerability, implement strict input validation to sanitize user-supplied replacement strings, specifically rejecting or escaping case-change modifiers (\u, \l, \U, \L) before calling g_regex_replace() or g_regex_replace_eval() when the G_REGEX_RAW compile flag is used. Removing the G_REGEX_RAW flag or hardcoding the replacement strings will completely neutralize this issue. Workaround: To mitigate this vulnerability, restrict any custom line terminator string passed to g_io_channel_set_line_term() to a maximum length of one byte before calling g_io_channel_read_line_backend(). Using the default line terminators will completely neutralize this issue. Workaround: To mitigate this vulnerability, implement input validation to sanitize untrusted key files (such as .desktop or .ini files), specifically rejecting or stripping empty values before calling g_key_file_get_locale_string_list(). Alternatively, restricting the application to only load key files from trusted sources will completely neutralize this issue. Workaround: To mitigate this vulnerability, ensure that applications only connect to trusted D-Bus servers and operate within secure, isolated networks to prevent man-in-the-middle (MitM) attacks. If feasible, configuring the D-Bus connection to strictly require the EXTERNAL authentication mechanism and disabling DBUS_COOKIE_SHA1 will completely neutralize this issue. Workaround: Configure your WAF or load balancer to drop incoming HTTP/1.1 requests that contain both Upgrade and Content-Length headers. This blocks the malformed traffic at the edge before it can reach the vulnerable proxy without impacting legitimate users. Workaround: Upgrade to js-yaml 5.2.0 or later. Where an immediate upgrade is not possible, avoid parsing untrusted YAML documents that use merge keys ('<<'), or apply size and time limits when parsing untrusted YAML input. Workaround: To reduce exposure, restrict the processing of untrusted YAML documents by applications that rely on `js-yaml`. Implement robust input validation and sanitization for all YAML data originating from external or untrusted sources. Consider limiting network access to services that parse YAML content to trusted networks or clients through appropriate firewall configurations. Workaround: To mitigate this issue, disable the ngx_http_slice_module entirely if it is not required. If the module must be used, avoid unnamed regex captures with the slice directive and explicitly disable proxy_cache_background_update. Reload or restart the NGINX service to apply these changes. Please note this may cause a brief service interruption. Workaround: To mitigate this issue, ensure application code validates the size parameter passed to customAlphabet or customRandom, rejecting or sanitizing zero-value inputs before passing them to nanoid. Workaround: Sanitize all user-supplied integer inputs before passing them to `nanoid` or `customAlphabet` functions in the `nanoid/non-secure` module, ensuring the size parameter is strictly a non-negative integer. Workaround: To mitigate this issue, restrict applications from processing untrusted YAML input with affected versions of the `js-yaml` library. Implement strict input validation to ensure that only trusted and well-formed YAML data is processed. If the application is exposed to external, untrusted sources, consider isolating the application or implementing additional resource limits to prevent complete service disruption. Workaround: Ensure that the configured publicPath always ends with a trailing slash (e.g., '/assets/'), or utilize the default…

🔗 References (46)