Where
-Infinity
0
Severity
5.5
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. Prior to version 0.9-rc4, any unprivileged local user can crash avahi-daemon by sending a single D-Bus method call with conflicting publish flags. This issue has been patched in version 0.9-rc4.

1 / 3
Source: MITRE
First published (updated )
Severity
6.5
EPSS
0.03%
AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In versions 0.9rc2 and below, avahi-daemon can be crashed via a segmentation fault by sending an unsolicited mDNS response containing a recursive CNAME record, where the alias and canonical name point to the same domain (e.g., "h.local" as a CNAME for "h.local"). This causes unbounded recursion in the lookuphandlecname function, leading to stack exhaustion. The vulnerability affects record browsers where AVAHILOOKUPUSEMULTICAST is set explicitly, which includes record browsers created by resolvers used by nss-mdns. This issue is patched in commit 78eab31128479f06e30beb8c1cbf99dd921e2524.

1 / 2
Source: MITRE
First published (updated )
Severity
6.5
AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

Avahi has a reachable assertion in lookupstart

1 / 2
Source: Microsoft
First published (updated )
Severity
6.5
AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

Avahi has a reachable assertion in lookupmulticastcallback

1 / 2
Source: Microsoft
First published (updated )
Severity
5.5
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Avahi has a reachable assertion in avahiwideareascancache

1 / 2
Source: Microsoft
First published (updated )

https://github.com/avahi/avahi/security/advisories/GHSA-73wf-3xmj-x82q advises: Summary -------

The simple protocol server ignores the documented client limit and accepts unlimited connections, allowing for easy local DoS.

Details -------

Although CLIENTSMAX is defined, serverwork() unconditionally accept()s and clientnew() always appends the new client and increments nclients. There is no check against the limit.

When client cannot be accepted as a result of maximal socket number of avahi-daemon, it logs unconditionally error per each connection.

PoC ---

Flood the UNIX simple-protocol socket with idle connections for i in $(seq 1 4000); do socat - UNIX-CONNECT:/run/avahi-daemon/socket >/dev/null 2>&1 & done wait

Watch avahi-daemon’s memory/FD count grow until it becomes unresponsive or crashes, such as an endless loop of:

accept(): Too many open files accept(): Too many open files accept(): Too many open files accept(): Too many open files accept(): Too many open files accept(): Too many open files accept(): Too many open files accept(): Too many open files accept(): Too many open files accept(): Too many open files accept(): Too many open files accept(): Too many open files accept(): Too many open files accept(): Too many open files

Impact ------

Unprivileged local users can exhaust daemon memory and file descriptors, causing a denial of service system-wide for mDNS/DNS-SD.

Exahusting local file descriptors causes increased system load caused by logging errors of each of request.

Overloading prevents glibc calls using nss-mdns plugins to resolve .local. names and link-local addresses.

Workarounds -----------

Simple clients are offered for nss-mdns package functionality. It is not possible to disable the unix socket /run/avahi-daemon/socket, but resolution requests received via DBus are not affected directly. Tools avahi-resolve, avahi-resolve-address and avahi-resolve-host-name are not affected, they use DBus interface.

It is possible to change permissions of unix socket after avahi-daemon is started. But avahi-daemon does not provide any configuration for it. Additional access restrictions like SELinux can also prevent unwanted tools to access the socket and keep resolution working for trusted users.

Fixes -----

Candidate only: https://github.com/avahi/avahi/pull/808

Credits -------

We would like to thank Joshua Rogers using the ZeroPath tool for discovering and reporting the issue responsibly.

published article about it: Avahi Simple Protocol Server DoS (CVE-2025-59529) https://zeropath.com/blog/avahi-simple-protocol-server-dos-cve-2025-59529

Severity: Moderate, 5.5 / 10 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H CVE ID: CVE-2025-59529 Weaknesses: CWE-400 -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In versions up to and including 0.9-rc2, the simple protocol server ignores the documented client limit and accepts unlimited connections, allowing for easy local DoS. Although CLIENTSMAX is defined, serverwork() unconditionally accept()s and clientnew() always appends the new client and increments nclients. There is no check against the limit. When client cannot be accepted as a result of maximal socket number of avahi-daemon, it logs unconditionally error per each connection. Unprivileged local users can exhaust daemon memory and file descriptors, causing a denial of service system-wide for mDNS/DNS-SD. Exhausting local file descriptors causes increased system load caused by logging errors of each of request. Overloading prevents glibc calls using nss-mdns plugins to resolve .local. names and link-local addresses. As of time of publication, no known patched versions are available, but a candidate fix is available in pull request 808, and some workarounds are available. Simple clients are offered for nss-mdns package functionality. It is not possible to disable the unix socket /run/avahi-daemon/socket, but resolution requests received via DBus are not affected directly. Tools avahi-resolve, avahi-resolve-address and avahi-resolve-host-name are not affected, they use DBus interface. It is possible to change permissions of unix socket after avahi-daemon is started. But avahi-daemon does not provide any configuration for it. Additional access restrictions like SELinux can also prevent unwanted tools to access the socket and keep resolution working for trusted users.

First published (updated )
Severity
4

The sequential increment of DNS transaction IDs makes Avahi vulnerable to DNS spoofing, allowing attackers to inject malicious DNS records. This can compromise the integrity of DNS responses, redirecting users to potentially harmful domains. This vulnerability poses a greater risk as it directly undermines the integrity of DNS resolution, affecting all systems using Avahi for wide-area DNS queries unless mitigations are applied.

First published (updated )
Severity
5.5
Null Pointer Dereference
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

A flaw was found in avahi 0.8-5. A reachable assertion is present in avahishostnameresolverstart function allowing a local attacker to crash the avahi service by requesting hostname resolutions through the avahi socket or dbus methods for invalid hostnames. The highest threat from this vulnerability is to the service availability.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

A flaw was found in avahi deamon. Denial of service can be triggered by writing long lines to /run/avahi-daemon/socket resulting in an unresponsive busy-loop of the daemon.

References:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984938

1 / 2
Source: Red Hat
First published (updated )
Severity
7.8
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

avahi-daemon-check-dns.sh in the Debian avahi package through 0.8-4 is executed as root via /etc/network/if-up.d/avahi-daemon and allows a local attacker to cause a denial of service or create arbitrary empty files via a symlink attack on files under /run/avahi-daemon. NOTE: this only affects the packaging for Debian GNU/Linux (used indirectly by SUSE) not the upstream Avahi product.

1 / 2
Source: Microsoft
First published (updated )
Severity
9.1
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

avahi-daemon in Avahi through 0.6.32 and 0.7 inadvertently responds to IPv6 unicast queries with source addresses that are not on-link, which allows remote attackers to cause a denial of service (traffic amplification) and may cause information leakage by obtaining potentially sensitive information from the responding device via port-5353 UDP packets. NOTE: this may overlap CVE-2015-2809.

1 / 3
Source: Launchpad

Remedy

Block udp port 5353 at perimeter firewall
First published (updated )
Severity
2.1
AV:L/AC:L/Au:N/C:N/I:N/A:P

The Avahi daemon in Avahi before 0.6.20 allows attackers to cause a denial of service (exit) via empty TXT data over D-Bus, which triggers an assert error.

First published (updated )
Severity
5
AV:N/AC:L/Au:N/C:N/I:N/A:P

The consumelabels function in avahi-core/dns.c in Avahi before 0.6.16 allows remote attackers to cause a denial of service (infinite loop) via a crafted compressed DNS response with a label that points to itself.

First published (updated )
Severity
2.1
AV:L/AC:L/Au:N/C:N/I:P/A:N

Avahi before 0.6.15 does not verify the sender identity of netlink messages to ensure that they come from the kernel instead of another process, which allows local users to spoof network changes to Avahi.

First published (updated )
Severity
3.6
AV:L/AC:L/Au:N/C:N/I:P/A:P

Avahi before 0.6.10 allows local users to cause a denial of service (mDNS/DNS-SD service disconnect) via unspecified mDNS name conflicts.

First published (updated )
Severity
2.1
Buffer Overflow
AV:L/AC:L/Au:N/C:N/I:P/A:N

Buffer overflow in avahi-core in Avahi before 0.6.10 allows local users to execute arbitrary code via unknown vectors.

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203