RHSA-2026:43588HighCVSS 8.6

Red Hat Security Advisory: Red Hat Hardened Images RPMs bug fix and enhancement update

Published
July 22, 2026
Last Modified
September 6, 2026

🔗 CVE IDs covered (23)

CVE-2026-32665 →CVE-2026-40691 →CVE-2026-46582 →CVE-2026-50046 →CVE-2026-50243 →CVE-2026-52863 →CVE-2026-55973 →CVE-2026-42955 →CVE-2026-44690 →CVE-2026-50045 →CVE-2026-50248 →CVE-2026-50251 →CVE-2026-55708 →CVE-2026-56444 →CVE-2026-14586 →CVE-2026-54478 →CVE-2026-41637 →CVE-2026-44687 →CVE-2026-50252 →CVE-2026-55717 →CVE-2026-55990 →CVE-2026-55991 →CVE-2026-56416 →

📋 Description

CVE-2026-14586 — unbound: Unbound: Denial of Service via assertion failure in DNS-over-QUIC environments CVE-2026-32665 — unbound: Unbound: Denial of Service via improper validation of DNS-over-QUIC client length CVE-2026-40691 — unbound: Unbound: Denial of Service via crafted DNSCrypt query CVE-2026-41637 — unbound: Unbound: Denial of Service via terminated DNS-over-QUIC queries CVE-2026-42955 — unbound: Unbound: DNS cache integrity issue CVE-2026-44687 — unbound: Unbound: Denial of Service due to 'harden-below-nxdomain' logic bypass CVE-2026-44690 — unbound: Unbound: Cache poisoning via insufficient RRSIG.Labels validation and premature cache writes CVE-2026-46582 — unbound: Unbound: Information disclosure via DNSSEC wildcard replay CVE-2026-50045 — unbound: Unbound: Denial of Service via DNSSEC query amplification bypass CVE-2026-50046 — unbound: Unbound: Denial of Service due to freed pointer dereference in DNS-over-TLS handling CVE-2026-50243 — unbound: Unbound: Insecure DNS redirection via spoofed DNS answers CVE-2026-50248 — unbound: Unbound: DNS response policy replacement via hostname spoofing CVE-2026-50251 — unbound: NLnet Labs Unbound: Denial of Service via crafted DNS glue records CVE-2026-50252 — unbound: Unbound: DNS cache poisoning via UDP source port predictability CVE-2026-52863 — unbound: Unbound: Denial of service due to memory corruption under specific configurations. CVE-2026-54478 — unbound: Unbound: DNS Cookie security bypass via incorrect server cookie calculation CVE-2026-55708 — unbound: Unbound: Information disclosure due to local policy bypass via unbound-control CVE-2026-55717 — unbound: Unbound: Denial of Service via crafted DNS responses with expired records CVE-2026-55973 — unbound: Unbound: Denial of Service via malformed EDNS Report-Channel option CVE-2026-55990 — unbound: NLnet Labs Unbound: Denial of Service via faulty DNSCrypt configuration CVE-2026-55991 — unbound: Unbound: Denial of Service via crafted DNS-over-QUIC connection CVE-2026-56416 — unbound: Unbound: Heap buffer overflow via malformed DNSSEC record CVE-2026-56444 — unbound: Unbound: Denial of Service due to incorrect client reply accounting with specific serve-expired configuration

🎯 Affected products5

  • Red Hat Hardened Images
  • unbound-main@aarch64 as a component of Red Hat Hardened Images
  • unbound-main@noarch as a component of Red Hat Hardened Images
  • unbound-main@src as a component of Red Hat Hardened Images
  • unbound-main@x86_64 as a component of Red Hat Hardened Images

✅ Remediation

For details on how to apply this update, which includes the changes described in this advisory, refer to: https://images.redhat.com/ Workaround: Disable DNS-over-QUIC (DoQ) by removing or commenting out any quic-port directives in your unbound.conf file. Restart the unbound service for the changes to take effect and prevent potential assertion crashes. Workaround: To mitigate this issue, disable DNS-over-QUIC (DoQ) in the Unbound configuration if it is not a required service. This can typically be achieved by commenting out or removing DoQ-related configuration options in `unbound.conf`. For example, remove or comment out lines such as `do-quic: yes` or `quic-port: 853`. After modifying the configuration, restart the Unbound service for the changes to take effect: ```bash systemctl restart unbound ``` Warning: Restarting the Unbound service will temporarily interrupt DNS resolution. Workaround: To mitigate this issue, completely disable DNS-over-QUIC (DoQ) support by removing or commenting out the quic-port directive in your Unbound configuration. Restart the Unbound service to apply the changes and clear any lingering resource limits. Workaround: To mitigate this issue, ensure harden-referral-path is set to no (the default) to prevent Unbound from implicitly triggering the vulnerable cache overwrites. Additionally, restrict recursive DNS access strictly to trusted clients to prevent external attackers from manually triggering the flaw. Restart the Unbound service to apply these configuration changes. Workaround: Disable the harden-below-nxdomain option in the Unbound configuration to prevent the logic bypass that leads to the denial of service. Note that disabling this option may reduce the overall DNSSEC hardening provided by Unbound. Edit /etc/unbound/unbound.conf and set the following in the server: section: harden-below-nxdomain: no Restart the Unbound service for the changes to take effect: systemctl restart unbound Warning: Restarting the Unbound service will temporarily interrupt local DNS resolution. 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, disable the serve-expired feature by setting serve-expired: no in the Unbound configuration if it is not strictly required. This entirely removes the vulnerable code path where the cache poisoning occurs. Workaround: Restrict recursive DNS access strictly to trusted networks using firewall access controls, reloading the service to apply changes. Additionally, configure Rate Limiting on outbound traffic to throttle anomalous spikes and mitigate amplification risks. Workaround: To mitigate this issue, avoid configuring Unbound with a `#authname` suffix in DNS-over-TLS (DoT) forwarding or stub zones if not strictly required. If the `#authname` suffix is necessary, restrict network access to the Unbound instance to trusted clients only. This may involve configuring firewall rules to limit inbound connections to the DoT port (typically 853) from known, secure sources. After modifying Unbound's configuration, the service must be reloaded or restarted for the changes to take effect. This action may temporarily interrupt DNS resolution services. Workaround: If IP-based rewriting is unused, leave module-config configured as "validator iterator" and do not configure response-ip redirects or RPZ-IP triggers. If these features are required, ensure validator is placed before respip in module-config and restrict upstream peer access to reduce exposure to spoofed DNS answers. Workaround: Configure Response Policy Zones (RPZ) and secondary zone primary endpoints using explicit IP addresses rather than hostnames to prevent A/AAAA spoofing or resolution flaws. Additionally, restrict network access for zone transfers to trusted sources and reload or restart the unbound service for configuration changes to take effect. Workaround: To mitigate this issue, configure Unbound to disable the `unwanted-reply-threshold` option by setting it to `0` in the `unbound.conf` file. This prevents the cache clearing behavior triggered by malicious glue records. After modifying the configuration, restart the Unbound service for the changes to take effect. Workaround: Disable the so-reuseport option by explicitly setting so-reuseport: no in your unbound.conf file. This prevents the deterministic mapping of worker threads to outbound UDP source ports, effectively stopping the cache poisoning vector. Additionally, restrict who can query the resolver using the access-control directive to reduce the overall attack surface, and restart the Unbound service to apply the changes. Workaround: To mitigate this issue, avoid configuring Unbound with a combination of 'respip' or 'rpz' modules, subquery attachment features (such as respip CNAME redirection, dns64, or subnetcache), and 'access-control-view' if these functionalities are not strictly required. Disabling these specific configurations will prevent the conditions under which memory corruption can occur. Any changes to Unbound's configuration will require a service restart to take effect, which may temporarily interrupt DNS resolution services. Workaround: To mitigate this issue, avoid enabling `answer-cookie: yes` when Unbound is configured to listen on a `proxy-protocol-port`. If the `proxy-protocol-port` is essential, consider disabling DNS cookies. If both features are required, ensure the proxy infrastructure is secured and trusted. A restart of the Unbound service is required for configuration changes to take effect. Workaround: Do not run unbound-control view_local_data / view_local_datas on named views that started with no local-data; put local-data (or the RFC 1918 / AS112 / .onion / .localhost local-zones) in unbound.conf so the tree is built at startup with the defaults. If views or remote control are unused, leave control-enable: no and keep the control socket admin-only. Block Unbound from sending those names to the public Internet. Workaround: Ensure serve-expired remains disabled (default), or set serve-expired-client-timeout: 0 to bypass the vulnerable callback path. If serving expired answers is necessary, remove any response-ip CNAME redirect rules and RPZ rpz-cname-override entries. Additionally, use access-control to restrict query access, preventing untrusted clients from triggering the flaw via attacker-controlled names. Workaround: To mitigate this issue, ensure that Unbound is not compiled with DNSCrypt support if the feature is not required. If DNSCrypt support is enabled, verify that the number of 'dnscrypt-provider-cert:' files precisely matches the number of 'dnscrypt-secret-key:' files in the Unbound configuration to prevent the faulty configuration that leads to a denial of service. Restart the Unbound service after any configuration changes. Workaround: To prevent exploitation, disable DNS-over-QUIC (DoQ) functionality within Unbound if it is not actively used. This typically involves adjusting Unbound's configuration to remove or comment out DoQ-related listening directives. After modifying the configuration, restart the Unbound service for the changes to take effect. Workaround: To mitigate this issue, consider disabling DNSSEC validation in Unbound if it is not strictly required for your environment. This can be achieved by ensuring `module-config: "iterator"` is used in `unbound.conf` and that no `trust-anchor` or `auto-trust-anchor-file` directives are present. Disabling DNSSEC validation will reduce the security assurances provided by DNSSEC. Alternatively, configure Unbound to only perform DNSSEC validation for trusted zones. A restart of the Unbound service is required for changes to take effect. Workaround: To mitigate this issue, ensure that Unbound is configured with `serve-expired-client-ti…

🔗 References (27)