{"schema_version":"1.7.2","id":"OESA-2026-4342","modified":"2026-10-16T11:59:33Z","published":"2026-10-16T11:59:33Z","upstream":["CVE-2026-19033","CVE-2026-19662","CVE-2026-19941","CVE-2026-75029","CVE-2026-78301"],"summary":"bind security update","details":"BIND (Berkeley Internet Name Domain) is an implementation of the DNS (Domain Name System) protocols. BIND includes a DNS server (named), which resolves host names to IP addresses; a resolver library (routines for applications to use when interfacing with DNS); and tools for verifying that the DNS server is operating properly.\r\n\r\nSecurity Fix(es):\n\nFor a secondary zone with transfers restricted by TSIG, `named` may start to serve the data provided in a zone transfer before the final message with the TSIG signature arrives. This could allow an attacker that does not actually possess a valid TSIG signature to send unauthorized zone contents to a secondary server. Although no TSIG signature ever arrives, `named` does not rollback to the pre-transfer state. To exploit the vulnerability, the transfer must be a multi-message TCP IXFR, as described by RFC 8945.\nThis issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.(CVE-2026-19033)\n\nAn attacker may be able to cause a `named` resolver to abort. The attack requires inducing the victim resolver to send multiple queries for a DNSSEC-signed zone hosted by an authoritative server under the control of the attacker. If the auth responds with a particular sequence of crafted answers, and those answers arrive in a particular order with particular timing, the `named` resolver will encounter a use-after-free bug, and abort.\nThis issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.(CVE-2026-19662)\n\nAn inapplicable NSEC record may be accepted by a `named` resolver as proof that no wildcard exists, which could allow an attacker at the same or an upstream level of the zone name to mask the existence of a victim's wildcard record.\nThis issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.(CVE-2026-19941)\n\nIn a query response, an attacker may send `named` multiple copies of a record that should only exist once (such as an SOA record). If the RDATA is the same on all the copies, the record is appended to the in-memory RDATA set, which can cause increased memory usage of the negative cache and possibly lead to other memory attack vectors.\nThis issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.(CVE-2026-75029)\n\nA malformed zone may contain an NS or DNAME node above its origin, which `named` treats as a zone cut. If an attacker inserts a malformed zone into a BIND authoritative server (e.g., via zone transfer), queries for names inside the configured zone then lose authoritative status and return an out-of-zone delegation. On a server that also provides recursion BIND can follow this locally sourced cut and cache attacker-supplied data, affecting names outside the configured zone. This situation persists as long as the malformed zone remains in the zone database.\nThis issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.(CVE-2026-78301)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"bind","purl":"pkg:rpm/openEuler/bind&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"9.16.23-33.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bind-9.16.23-33.oe2203sp4.aarch64.rpm","bind-chroot-9.16.23-33.oe2203sp4.aarch64.rpm","bind-debuginfo-9.16.23-33.oe2203sp4.aarch64.rpm","bind-debugsource-9.16.23-33.oe2203sp4.aarch64.rpm","bind-devel-9.16.23-33.oe2203sp4.aarch64.rpm","bind-dnssec-utils-9.16.23-33.oe2203sp4.aarch64.rpm","bind-libs-9.16.23-33.oe2203sp4.aarch64.rpm","bind-pkcs11-9.16.23-33.oe2203sp4.aarch64.rpm","bind-pkcs11-devel-9.16.23-33.oe2203sp4.aarch64.rpm","bind-pkcs11-libs-9.16.23-33.oe2203sp4.aarch64.rpm","bind-pkcs11-utils-9.16.23-33.oe2203sp4.aarch64.rpm","bind-utils-9.16.23-33.oe2203sp4.aarch64.rpm"],"noarch":["bind-dnssec-doc-9.16.23-33.oe2203sp4.noarch.rpm","bind-license-9.16.23-33.oe2203sp4.noarch.rpm","python3-bind-9.16.23-33.oe2203sp4.noarch.rpm"],"src":["bind-9.16.23-33.oe2203sp4.src.rpm"],"x86_64":["bind-9.16.23-33.oe2203sp4.x86_64.rpm","bind-chroot-9.16.23-33.oe2203sp4.x86_64.rpm","bind-debuginfo-9.16.23-33.oe2203sp4.x86_64.rpm","bind-debugsource-9.16.23-33.oe2203sp4.x86_64.rpm","bind-devel-9.16.23-33.oe2203sp4.x86_64.rpm","bind-dnssec-utils-9.16.23-33.oe2203sp4.x86_64.rpm","bind-libs-9.16.23-33.oe2203sp4.x86_64.rpm","bind-pkcs11-9.16.23-33.oe2203sp4.x86_64.rpm","bind-pkcs11-devel-9.16.23-33.oe2203sp4.x86_64.rpm","bind-pkcs11-libs-9.16.23-33.oe2203sp4.x86_64.rpm","bind-pkcs11-utils-9.16.23-33.oe2203sp4.x86_64.rpm","bind-utils-9.16.23-33.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4342"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-19033"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-19662"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-19941"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-75029"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-78301"}],"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L"}],"database_specific":{"severity":"Medium"}}