CVE-2025-68471
Avahi vulnerability analysis and mitigation

Overview

CVE-2025-68471 is a reachable assertion vulnerability (CWE-617) in Avahi, a system that facilitates service discovery on local networks via the mDNS/DNS-SD protocol suite. The flaw affects Avahi versions up to and including 0.9-rc2, and was originally reported on February 4, 2025, with the security advisory published on January 12, 2026. An unauthenticated network attacker can crash avahi-daemon by sending two unsolicited mDNS announcements containing CNAME resource records approximately 2 seconds apart. It carries a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory, Feedly).

Technical details

The root cause is a reachable assertion in the lookup_start function in avahi-core/browse.c (line 323), classified as CWE-617 (Reachable Assertion). When avahi-daemon processes a CNAME resource record from an unsolicited mDNS response, it triggers a CNAME lookup chain. If a second unsolicited CNAME announcement arrives approximately 2 seconds later, the daemon attempts to start a duplicate lookup and hits the assertion !l->wide_area && !l->multicast, causing an abort via SIGABRT. The bug specifically affects record browsers where AVAHI_LOOKUP_USE_MULTICAST is set explicitly — a flag set by resolvers created via nss-mdns. The fix replaces the failing assert() with a graceful return 0 to avoid starting duplicate lookups (GitHub Advisory, GitHub Issue, Patch Commit).

Impact

Successful exploitation results in a denial-of-service condition: avahi-daemon crashes with SIGABRT, disrupting local network service discovery (mDNS/DNS-SD) for all dependent applications on the affected host. There is no confidentiality or integrity impact — the vulnerability is limited to availability. Applications relying on Avahi for service discovery (e.g., printers, network shares, IoT devices) will lose discovery functionality until the daemon is restarted (GitHub Advisory, Feedly).

Exploitation steps

  1. Reconnaissance: Identify hosts on the local network running a vulnerable version of avahi-daemon (≤0.9-rc2) using network scanning tools such as Nmap with mDNS service detection, or by passively monitoring mDNS traffic on UDP port 5353.
  2. Confirm active record browser: Verify that the target host has an active A/AAAA record browser with AVAHI_LOOKUP_USE_MULTICAST set (e.g., triggered by nss-mdns resolver activity).
  3. Craft malicious mDNS packet: Using Scapy, construct an mDNS response packet containing a CNAME resource record targeting a service being browsed (e.g., _ipp._tcp.local):
    send(IP(dst='224.0.0.251%iface')/UDP(sport=5353,dport=5353)/DNS(qd=[],qr=1,an=[DNSRR(rrname='_ipp._tcp.local', type='CNAME', ttl=1, rdata='Q')]), count=2, inter=2)
  4. Send two announcements 2 seconds apart: Transmit the crafted packet twice with a 2-second interval to the mDNS multicast address (224.0.0.251) on UDP port 5353.
  5. Trigger crash: Upon receipt of the second packet, avahi-daemon on the target host hits the reachable assertion in lookup_start (browse.c:323) and terminates with SIGABRT, causing a denial of service (GitHub Advisory, GitHub Issue).

Indicators of compromise

  • Network: Repeated unsolicited mDNS response packets (UDP port 5353, destination 224.0.0.251) containing CNAME resource records sent in pairs approximately 2 seconds apart from the same source IP; unusual mDNS traffic patterns from unexpected hosts on the local network segment.
  • Logs: System logs (e.g., /var/log/syslog, journalctl) showing avahi-daemon crash entries with SIGABRT or assertion failure messages: browse.c:323: lookup_start: Assertion '!l->wide_area && !l->multicast' failed.
  • Process: Unexpected termination of the avahi-daemon process; repeated automatic restarts of avahi-daemon by the init system (systemd) in a short time window.
  • File System: Core dump files generated by avahi-daemon in /var/crash/ or configured core dump directories following the crash (GitHub Advisory, GitHub Issue).

Mitigation and workarounds

Upgrade Avahi to version 0.9-rc3 or later, which replaces the failing assertion with a graceful return to prevent the crash. The fix is available in commit 9c6eb53 in the official Avahi repository. As a temporary workaround where patching is not immediately possible, restrict network access to the mDNS multicast address (224.0.0.251, UDP port 5353) to trusted hosts only using firewall rules. Linux distributions including SUSE, Mageia, Ubuntu, and Red Hat have released updated packages addressing this vulnerability (Patch Commit, GitHub Advisory, Red Hat Errata).

Community reactions

The vulnerability was originally reported by researcher evverx on the Avahi GitHub issue tracker in February 2025 and subsequently formalized as a security advisory in January 2026. Multiple Linux distributions (SUSE, Mageia, Ubuntu, Red Hat) have issued security advisories and updated packages. The Yocto Project security mailing list has also tracked the issue across multiple messages. Community reaction has been measured given the limited scope (local network DoS only) and the availability of a straightforward patch (GitHub Issue, Red Hat Errata).

Additional resources


SourceThis report was generated using AI

Related Avahi vulnerabilities:

CVE ID

Severity

Score

Technologies

Component name

CISA KEV exploit

Has fix

Published date

CVE-2026-24401MEDIUM6.5
  • Avahi logoAvahi
  • avahi-compat-howl-devel
NoYesJan 24, 2026
CVE-2025-68471MEDIUM6.5
  • Avahi logoAvahi
  • avahi-compat-mDNSResponder-devel
NoYesJan 12, 2026
CVE-2025-68468MEDIUM6.5
  • Avahi logoAvahi
  • avahi
NoYesJan 12, 2026
CVE-2026-34933MEDIUM5.5
  • Avahi logoAvahi
  • avahi
NoYesApr 03, 2026
CVE-2025-68276MEDIUM5.5
  • Avahi logoAvahi
  • avahi-autoipd
NoYesJan 12, 2026

Free Vulnerability Assessment

Benchmark your Cloud Security Posture

Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.

Request assessment

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management