CVE-2026-34933

What it actually does

A local denial-of-service flaw in Avahi before 0.9-rc4 allows an unprivileged local user to crash avahi-daemon by sending a crafted D-Bus method call that requests service publication using conflicting publish flags. The issue does not provide confidentiality or integrity impact, remote code execution, or privilege escalation by itself, but it can terminate the mDNS/DNS-SD service discovery daemon and disrupt local network service advertisement and discovery.

Why it matters to the business

Systems relying on Avahi for local network discovery may become harder to locate or use when the daemon crashes, affecting workflows such as printer discovery, media sharing, appliance discovery, workstation service discovery, or embedded/Linux device coordination. The risk is primarily operational disruption from a local user or compromised low-privilege account. EPSS is very low and there is no known KEV listing or ransomware association, so broad internet-scale exploitation is unlikely, but multi-user systems, shared workstations, lab environments, VDI hosts, and embedded devices with local shell access should still prioritize patching.

How an attack unfolds

An attacker first needs local access to a vulnerable system as any unprivileged user. They then communicate with the system D-Bus service exposed by Avahi and invoke a service-publishing related method using incompatible publish flag combinations. Vulnerable avahi-daemon versions fail to handle that invalid flag combination safely and crash. Once avahi-daemon is stopped or repeatedly crashed, local mDNS/DNS-SD advertisements and discovery can be unavailable until the service is restarted, the host is rebooted, or the package is upgraded.

How to fix it

Upgrade Avahi to version 0.9-rc4 or later when available from the operating system or vendor package channel. If a fixed package is not yet available, reduce exposure by disabling avahi-daemon where mDNS/DNS-SD is not required, restricting local shell access to trusted users, and reviewing D-Bus policy controls to ensure only intended local users or services can interact with Avahi. On systems where Avahi is required, configure systemd to restart the service on failure as a temporary resilience measure, but do not treat automatic restart as a substitute for patching.

How to confirm the fix worked

Confirm the installed Avahi version is 0.9-rc4 or later using the platform package manager or avahi-daemon version output. Verify avahi-daemon is running normally after upgrade and that service discovery still works for expected use cases. Review package changelogs or vendor advisories to ensure the fix for conflicting publish flags is included. For systems where Avahi is not needed, validate that the service is disabled and not listening or registered on D-Bus. Check recent logs after remediation to confirm avahi-daemon is no longer crashing or producing core dumps.

Typical attack path

1. Obtain local low-privilege access to a host running a vulnerable Avahi version.
2. Confirm avahi-daemon is installed, running, and reachable over the local system D-Bus.
3. Send a crafted D-Bus method call to Avahi using conflicting publish flags.
4. Trigger avahi-daemon to terminate or dump core.
5. Optionally repeat the call after service restart to maintain service discovery disruption.

How to detect it

Look for evidence that avahi-daemon crashed unexpectedly, especially if preceded by local D-Bus activity from unprivileged users. Useful sources include systemd journal logs, syslog, auditd process and D-Bus monitoring, dbus-daemon logs where available, systemd-coredump records, endpoint telemetry, and package/version inventory. Investigate repeated avahi-daemon restarts, core dumps, segmentation faults, abort messages, or service failures around the same time as local user sessions, scripts, containers, or unusual D-Bus client processes interacting with org.freedesktop.Avahi. Because this flaw is a local denial of service and no public exploit maturity is reported, indicators are likely to be service-crash artifacts rather than network indicators.

• avahi-daemon.service: Main process exited
• avahi-daemon.service: Failed with result 'core-dump'
• avahi-daemon.service: Failed with result 'signal'
• avahi-daemon.service: Scheduled restart job
• systemd-coredump
• Process avahi-daemon
• avahi-daemon dumped core
• avahi-daemon[
• segfault at
• org.freedesktop.Avahi
• org.freedesktop.Avahi.EntryGroup
• org.freedesktop.Avahi.Server

What your security team should do

• Inventory Linux, Unix-like, and embedded systems running Avahi, especially shared-user systems and devices that rely on mDNS/DNS-SD.
• Prioritize upgrading Avahi to 0.9-rc4 or later on systems where unprivileged local users, containers, desktop users, or remote shell users exist.
• Disable avahi-daemon on servers and appliances where local network service discovery is not required.
• Monitor for repeated avahi-daemon crashes, systemd restarts, and core dumps as possible signs of attempted exploitation.
• Review local account access and D-Bus policy posture on systems where Avahi must remain enabled.
• Add package/version compliance checks to vulnerability management tooling because exploitation requires local access but can cause high availability impact for discovery-dependent services.