CoreDNS is a DNS server written in Go. In versions prior to 1.14.3, the gRPC, QUIC, DoH, and DoH3 transport implementations incorrectly handle TSIG authentication. For gRPC and QUIC, the server checks whether the TSIG key name exists in the configuration but never calls dns.TsigVerify() to validate the HMAC. If the key name matches a configured key, the tsigStatus field remains nil and the tsig plugin treats the request as successfully authenticated regardless of the MAC value. For DoH and DoH3, the issue is more severe: the DoHWriter.TsigStatus() method unconditionally returns nil, and the server never inspects the TSIG record at all. Any request containing a TSIG record is treated as authenticated over DoH and DoH3, even if the key name is invalid and the MAC is arbitrary. An unauthenticated network attacker can exploit this to bypass TSIG-protected functionality such as AXFR/IXFR zone transfers, dynamic DNS updates, or other TSIG-gated plugin behavior. The DoH and DoH3 variants have a lower exploitation bar because the attacker does not need to know a valid TSIG key name. This issue has been fixed in version 1.14.3. As a workaround, disable gRPC, QUIC, DoH, and DoH3 listeners where TSIG authentication is required, or restrict network-level access to affected transport ports to trusted sources only.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - CoreDNS is a DNS server written in Go. In versions prior to 1.14.3, the gRPC, QUIC, DoH, and DoH3
    transport implementations incorrectly handle TSIG authentication. For gRPC and QUIC, the server checks
    whether the TSIG key name exists in the configuration but never calls dns.TsigVerify() to validate the
    HMAC. If the key name matches a configured key, the tsigStatus field remains nil and the tsig plugin
    treats the request as successfully authenticated regardless of the MAC value. For DoH and DoH3, the issue
    is more severe: the DoHWriter.TsigStatus() method unconditionally returns nil, and the server never
    inspects the TSIG record at all. Any request containing a TSIG record is treated as authenticated over DoH
    and DoH3, even if the key name is invalid and the MAC is arbitrary. An unauthenticated network attacker
    can exploit this to bypass TSIG-protected functionality such as AXFR/IXFR zone transfers, dynamic DNS
    updates, or other TSIG-gated plugin behavior. The DoH and DoH3 variants have a lower exploitation bar
    because the attacker does not need to know a valid TSIG key name. This issue has been fixed in version
    1.14.3. As a workaround, disable gRPC, QUIC, DoH, and DoH3 listeners where TSIG authentication is
    required, or restrict network-level access to affected transport ports to trusted sources only.
    (CVE-2026-35579)

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-109796 advisory.

    CoreDNS is a DNS server written in Go. In versions prior to 1.14.3, the gRPC, QUIC, DoH, and DoH3     transport implementations incorrectly handle TSIG authentication. For gRPC and QUIC, the server checks     whether the TSIG key name exists in the configuration but never calls dns.TsigVerify() to validate the     HMAC. If the key name matches a configured key, the tsigStatus field remains nil and the tsig plugin     treats the request as successfully authenticated regardless of the MAC value. For DoH and DoH3, the issue     is more severe: the DoHWriter.TsigStatus() method unconditionally returns nil, and the server never     inspects the TSIG record at all. Any request containing a TSIG record is treated as authenticated over DoH     and DoH3, even if the key name is invalid and the MAC is arbitrary.

    An unauthenticated network attacker can exploit this to bypass TSIG-protected functionality such as     AXFR/IXFR zone transfers, dynamic DNS updates, or other TSIG-gated plugin behavior. The DoH and DoH3     variants have a lower exploitation bar because the attacker does not need to know a valid TSIG key name.

    This issue has been fixed in version 1.14.3. As a workaround, disable gRPC, QUIC, DoH, and DoH3 listeners     where TSIG authentication is required, or restrict network-level access to affected transport ports to     trusted sources only.

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

An update of the coredns package has been released.

The remote openSUSE 16 host has packages installed that are affected by multiple vulnerabilities as referenced in the openSUSE-SU-2026:20703-1 advisory.

    Changes in coredns:

    - Update to version 1.14.3:
      * This release introduces Windows service support, along with full TSIG         verification across DoH, DoH3, QUIC, and gRPC transports, and improved         TSIG propagation and DoH request validation.
      * It also adds optional TLS for the metrics endpoint.
      * Performance and stability are improved through cache prefetching, QUIC         optimizations, and a new max_age option in the forward plugin.
      * Additional updates include enhanced SVCB/HTTPS support, improved zone         transfer behavior, and various DNSSEC, PROXY protocol, and concurrency         fixes.
      * The release is built with Go 1.26.2, which includes security         fixes addressing CVE-2026-32282, CVE-2026-32289, CVE-2026-33810,         CVE-2026-27144, CVE-2026-27143, CVE-2026-32288, CVE-2026-32283,         and CVE-2026-27140, and also includes fixes for CVE-2026-32936,         CVE-2026-33190, CVE-2026-33489, CVE-2026-32934, and CVE-2026-35579.

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Type	Severity
457482	Echo: github.com/coredns/coredns: security update to 1.14.3	Tenable Cloud Security	Echo Local Security Checks	Local	high
457482	Echo: github.com/coredns/coredns: security update to 1.14.3	Tenable Self-Hosted Container Security	Echo Local Security Checks	Local	high
347011	Unity Linux 20.1050e / 20.1060e / 20.1070e Security Update: coredns (UTSA-2026-109796)	Nessus	Unity Linux Local Security Checks	Local	high
333808	Photon OS 5.0: Coredns PHSA-2026-5.0-91-0869	Nessus	PhotonOS Local Security Checks	Local	high
321834	Photon OS 4.0: Coredns PHSA-2026-4.0-1038	Nessus	PhotonOS Local Security Checks	Local	high
321475	Photon OS 5.0: Coredns PHSA-2026-5.0-0869	Nessus	PhotonOS Local Security Checks	Local	high
313705	openSUSE 16 Security Update : coredns (openSUSE-SU-2026:20703-1)	Nessus	SuSE Local Security Checks	Local	high
440958	SCA: security update for github.com/coredns/coredns (GHSA-vp29-5652-4fw9)	Tenable Cloud Security	SCA Checks	Local	high
440958	SCA: security update for github.com/coredns/coredns (GHSA-vp29-5652-4fw9)	Tenable Self-Hosted Container Security	SCA Checks	Local	high

Detections

Analytics

CVE-2026-35579

high

Tenable Plugins

high

high

high

high

high

high

high

high

high