CVE-2025-68468
Unknown Unknown - Not Provided
Denial of Service in Avahi-daemon via Malformed CNAME Records

Publication date: 2026-01-12

Last updated on: 2026-01-12

Assigner: GitHub, Inc.

Description
Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending unsolicited announcements containing CNAME resource records pointing it to resource records with short TTLs. As soon as they expire avahi-daemon crashes.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-01-12
Last Modified
2026-01-12
Generated
2026-05-07
AI Q&A
2026-01-13
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
avahi avahi_daemon to 0.9-rc2 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-617 The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2025-68468 is a denial-of-service vulnerability in the avahi-daemon caused by an incorrect assertion in the source code. Specifically, when avahi-daemon receives unsolicited multicast DNS announcements containing CNAME resource records with short TTLs, the daemon attempts to validate keys during the multicast DNS lookup callback. Due to a faulty assertion checking key equality, when these CNAME records expire, the assertion fails and causes the daemon to crash. This crash occurs because the code incorrectly assumes certain keys will always match, leading to an unexpected program termination. [1, 2, 3]


How can this vulnerability impact me? :

This vulnerability can cause the avahi-daemon to crash, resulting in a denial-of-service condition. Since avahi-daemon facilitates service discovery on local networks, its crash can disrupt network service discovery functionality, potentially impacting applications or services relying on it. The crash is triggered remotely by sending specially crafted multicast DNS packets with CNAME records that expire quickly, requiring no privileges but user interaction (receiving the malicious packet). [2, 3]


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring for crashes or abnormal termination of the avahi-daemon process, especially following receipt of multicast DNS announcements containing CNAME resource records with short TTLs. Additionally, you can attempt to reproduce the issue by sending crafted multicast DNS packets with chains of CNAME records that expire quickly. An example command to test this using Python and Scapy is: ```python 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=10, rdata='A.local'), DNSRR(rrname='A.local', type='CNAME', ttl=10, rdata='B.local'), DNSRR(rrname='B.local', type='PTR', ttl=2, rdata='_qotd._tcp.local') ] ) ) ``` Replace `iface` with your network interface name. Monitoring system logs for avahi-daemon crashes and using network packet capture tools (e.g., tcpdump or Wireshark) to detect suspicious multicast DNS traffic with unusual CNAME chains can also help detect exploitation attempts. [3]


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include: 1. Update avahi-daemon to a version that includes the fix for CVE-2025-68468 once available. 2. If an update is not yet available, consider temporarily disabling avahi-daemon to prevent exploitation. 3. Monitor network traffic for unsolicited multicast DNS announcements containing suspicious CNAME chains with short TTLs and block or filter such packets if possible. 4. Restrict network access to the multicast DNS service to trusted hosts only. These steps help prevent the daemon from crashing due to the assertion failure triggered by malicious multicast DNS packets. [3, 2]


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart