RHSA-2026:68279HighCVSS 7.5

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

Published
September 16, 2026
Last Modified
October 5, 2026

🔗 CVE IDs covered (14)

CVE-2026-19033 →CVE-2026-19666 →CVE-2026-19941 →CVE-2026-75029 →CVE-2026-76163 →CVE-2026-77119 →CVE-2026-78301 →CVE-2026-81563 →CVE-2026-19662 →CVE-2026-19667 →CVE-2026-19668 →CVE-2026-77692 →CVE-2026-80274 →CVE-2026-81736 →

📋 Description

CVE-2026-19033 — bind: BIND: Unauthorized zone content updates via unauthenticated IXFR deltas CVE-2026-19662 — bind9: bind: BIND 9: Denial of Service via crafted DNSSEC responses CVE-2026-19666 — bind: BIND: Denial of Service via malformed DNS64 responses CVE-2026-19667 — bind9: bind: BIND 9: Denial of Service via 16-bit length truncation in DNS negative cache handling CVE-2026-19668 — bind: BIND: Denial of Service via invalid DNSSEC records CVE-2026-19941 — bind9: bind: BIND 9: DNS wildcard record existence can be masked by an attacker via inapplicable NSEC records CVE-2026-75029 — bind: BIND 9: Denial of Service via crafted query responses CVE-2026-76163 — bind: BIND: Denial of Service via TKEY query with specific configuration CVE-2026-77119 — bind9: bind: BIND 9: DNSSEC bypass via NSEC3 insecure-referral proof CVE-2026-77692 — bind: BIND: Remote Denial of Service via crafted DNS-over-HTTPS request CVE-2026-78301 — bind: BIND: DNS cache poisoning via malformed zone insertion CVE-2026-80274 — bind: BIND: Denial of Service via crafted DNSSEC reply CVE-2026-81563 — bind: BIND resolver: Denial of Service due to resource exhaustion in SVCB/HTTPS AliasMode processing CVE-2026-81736 — bind: BIND 9: Remote Denial of Service via cached SVCB/HTTPS AliasMode records

🎯 Affected products16

  • Red Hat Hardened Images
  • bind-0:9.20.29-0.1.hum1@aarch64 as a component of Red Hat Hardened Images
  • bind-0:9.20.29-0.1.hum1@src as a component of Red Hat Hardened Images
  • bind-0:9.20.29-0.1.hum1@x86_64 as a component of Red Hat Hardened Images
  • bind-chroot-0:9.20.29-0.1.hum1@aarch64 as a component of Red Hat Hardened Images
  • bind-chroot-0:9.20.29-0.1.hum1@x86_64 as a component of Red Hat Hardened Images
  • bind-devel-0:9.20.29-0.1.hum1@aarch64 as a component of Red Hat Hardened Images
  • bind-devel-0:9.20.29-0.1.hum1@x86_64 as a component of Red Hat Hardened Images
  • bind-dnssec-utils-0:9.20.29-0.1.hum1@aarch64 as a component of Red Hat Hardened Images
  • bind-dnssec-utils-0:9.20.29-0.1.hum1@x86_64 as a component of Red Hat Hardened Images
  • bind-doc-0:9.20.29-0.1.hum1@noarch@public-hummingbird-aarch64-rpms as a component of Red Hat Hardened Images
  • bind-doc-0:9.20.29-0.1.hum1@noarch@public-hummingbird-x86_64-rpms as a component of Red Hat Hardened Images
  • bind-libs-0:9.20.29-0.1.hum1@aarch64 as a component of Red Hat Hardened Images
  • bind-libs-0:9.20.29-0.1.hum1@x86_64 as a component of Red Hat Hardened Images
  • bind-utils-0:9.20.29-0.1.hum1@aarch64 as a component of Red Hat Hardened Images
  • bind-utils-0:9.20.29-0.1.hum1@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: 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, consider disabling DNSSEC validation on `named` resolvers if it is not a strict requirement for your environment. This can be achieved by setting `dnssec-validation no;` in the `named.conf` file. Disabling DNSSEC validation will prevent the resolver from processing DNSSEC-signed zones, thereby avoiding this specific vulnerability, but it will also remove the security benefits provided by DNSSEC. After modifying the configuration, the `named` service must be reloaded or restarted for the changes to take effect. `sudo systemctl reload named` `sudo systemctl restart named` Workaround: To mitigate this issue, disable the `dns64` feature in the BIND resolver configuration if it is not required. This can be done by removing or commenting out the `dns64` configuration block in `named.conf` or related configuration files. After modifying the configuration, the BIND service (`named`) must be reloaded or restarted for the changes to take effect. This action may temporarily interrupt DNS resolution services. Workaround: To reduce the exposure to this vulnerability, configure BIND 9 to forward all DNS queries to trusted, non-vulnerable upstream DNS servers. This prevents the local `named` instance from directly interacting with potentially malicious authoritative servers. Example configuration in `named.conf`: ``` options { forwarders { 192.0.2.1; 192.0.2.2; }; forward only; }; ``` Replace `192.0.2.1` and `192.0.2.2` with the IP addresses of your trusted upstream DNS servers. After modifying the configuration, restart the `named` service for the changes to take effect. This configuration may impact DNS resolution if the configured forwarders are unavailable or do not provide comprehensive resolution. Workaround: To mitigate potential denial of service, ensure that the BIND recursive resolver's configuration includes appropriate limits for `max-records-per-type` and `max-types-per-name` within the `named.conf` file. These settings help control resource consumption when encountering invalid DNSSEC records. A restart of the `named` service is required for any configuration changes to take effect. Workaround: To mitigate this issue, restrict network access to the BIND `named` service to only trusted clients and networks. Implement firewall rules to limit incoming UDP/TCP port 53 traffic to known, legitimate sources. This reduces the attack surface by preventing untrusted external entities from sending crafted query responses. Workaround: To mitigate this issue, ensure that the BIND configuration file (`named.conf`) includes a global `options` block. If no such block exists, adding an empty `options {}` block will prevent the vulnerability. After modifying `named.conf`, the `named` service must be restarted for the changes to take effect. This may temporarily interrupt DNS resolution. Workaround: To mitigate this issue, restrict access to the BIND service to trusted clients only, or disable DNS-over-HTTPS if it is not required. To restrict network access to the BIND service, configure firewall rules to only allow connections from trusted IP ranges to port 53 (UDP and TCP). For example, using `firewalld`: `firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="<TRUSTED_IP_RANGE>" port port="53" protocol="udp" accept'` `firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="<TRUSTED_IP_RANGE>" port port="53" protocol="tcp" accept'` `firewall-cmd --reload` If DNS-over-HTTPS is enabled and not essential, consider disabling it in the BIND configuration. Refer to the BIND administrator's reference manual for instructions on disabling DNS-over-HTTPS. Changes to BIND configuration require a restart of the `named` service for them to take effect. Workaround: To mitigate this issue, Red Hat recommends separating authoritative and recursive DNS functions onto different BIND instances or servers. This prevents a compromised authoritative zone from affecting recursive queries. Additionally, restrict zone transfer sources to trusted hosts only by configuring `allow-transfer` directives within your `named.conf` zone definitions. After modifying `named.conf`, the BIND service must be reloaded for changes to take effect, which may temporarily interrupt DNS resolution. Workaround: To mitigate this issue, disable DNSSEC validation in the BIND resolver configuration. This can be achieved by setting `dnssec-enable no;` and `dnssec-validation no;` within the `options` block in `named.conf` or an included configuration file. A restart of the `named` service is required for the changes to take effect and may impact DNS resolution during the restart. Disabling DNSSEC validation will reduce the security posture of DNS resolution by removing integrity protection for DNS data. Workaround: To mitigate the risk of this denial of service, configure BIND resolvers to restrict recursive queries to trusted clients only. This can be achieved by setting the `allow-recursion` option in the `named.conf` configuration file to specific IP addresses or networks. After modifying the configuration, the `named` service must be reloaded for the changes to take effect, which may temporarily interrupt DNS resolution.

🔗 References (18)