RHSA-2026:6935HighCVSS 8.6

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

Published
April 7, 2026
Last Modified
September 1, 2026

🔗 CVE IDs covered (8)

CVE-2026-1519 →CVE-2026-3104 →CVE-2026-3119 →CVE-2026-3591 →CVE-2025-8677 →CVE-2025-13878 →CVE-2025-40778 →CVE-2025-40780 →

📋 Description

CVE-2025-8677 — bind: Resource exhaustion via malformed DNSKEY handling CVE-2025-13878 — bind: bind: Denial of Service via corrupt or malicious record CVE-2025-40778 — bind: Cache poisoning attacks with unsolicited RRs CVE-2025-40780 — bind: Cache poisoning due to weak PRNG CVE-2026-1519 — bind: BIND: Denial of Service via maliciously crafted DNSSEC-validated zone CVE-2026-3104 — bind: BIND: Denial of Service via specially crafted domain query causing a memory leak CVE-2026-3119 — bind: BIND: Denial of Service via authenticated TKEY queries CVE-2026-3591 — bind: BIND: Unauthorized access due to use-after-return vulnerability in DNS query handling

🎯 Affected products5

  • Red Hat Hardened Images
  • bind-main@aarch64 as a component of Red Hat Hardened Images
  • bind-main@noarch as a component of Red Hat Hardened Images
  • bind-main@src as a component of Red Hat Hardened Images
  • bind-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: 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. To reduce risk, restrict recursive queries to trusted or internal networks only, and apply rate limiting or firewall rules to prevent excessive or repetitive requests. Enabling DNSSEC validation helps reject forged records, while isolating recursive resolvers from authoritative servers limits the impact of potential cache poisoning. Active monitoring of CPU usage, query volume, and cache anomalies can provide early warning of abuse or attacks. 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: While it is not possible to eliminate risk from this vulnerability, there are several options for reducing the risk. These include restricting recursive queries to trusted or internal networks only, and apply rate limiting or firewall rules to prevent excessive or repetitive requests. Enabling DNSSEC validation helps reject forged records, while isolating recursive resolvers from authoritative servers limits the impact of potential cache poisoning. Active monitoring of CPU usage, query volume, and cache anomalies can provide early warning of abuse or attacks. Workaround: To mitigate this issue, disable DNSSEC validation on affected BIND resolvers. Alternatively, configure the BIND server as authoritative-only if recursive queries are not required. Disabling DNSSEC validation may reduce the security posture of the DNS resolver. A restart of the BIND service (`named`) is required for these changes to take effect and may temporarily interrupt DNS resolution. Workaround: To mitigate this issue, restrict access to the BIND resolver to trusted clients only. This can be achieved by configuring firewall rules to limit inbound connections to port 53 (UDP/TCP) from known, authorized IP addresses or networks. Alternatively, configure BIND to listen only on specific trusted interfaces or localhost. Example using firewalld: `firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="<TRUSTED_IP_OR_NETWORK>" port port=53 protocol="udp" accept'` `firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="<TRUSTED_IP_OR_NETWORK>" port port=53 protocol="tcp" accept'` `firewall-cmd --reload` After applying changes, a restart of the BIND service may be required for the new configuration to take full effect. This may temporarily interrupt DNS resolution services. Workaround: To mitigate this issue, restrict access to the `named` service to only trusted networks and clients. If Transaction Signature (TSIG) keys are not actively used or required, consider disabling them in the BIND configuration. If TSIG keys are necessary, ensure they are securely managed and only distributed to authorized clients. After making configuration changes, a restart of the `named` service may be required to apply the changes, which could temporarily impact DNS resolution. Workaround: Restrict network access to the `named` service to trusted clients and networks. Configure firewall rules to limit inbound connections to the DNS service port (UDP/TCP 53). For example, using `firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="<TRUSTED_IP_RANGE>" port port="53" protocol="udp" accept'` and `firewall-cmd --reload`. This action may impact DNS resolution for clients outside the specified trusted networks. A service reload or restart may be required for changes to take effect.

🔗 References (12)