CVE-2025-68276
Avahi ≤ 0.9
Raw vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HSummary
CVE-2025-68276 is a medium-severity Reachable Assertion (CWE-617) vulnerability in Avahi Avahi. Its CVSS base score is 5.5 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Application or System Exploitation (T1499.004); ranked at the 4th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to AC-3 (Access Enforcement) and AC-6 (Least Privilege) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-206280
Vulnerability Data
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, an unprivileged local users can crash avahi-daemon (with wide-area disabled) by creating record browsers with the AVAHI_LOOKUP_USE_WIDE_AREA flag set…
more
via D-Bus. This can be done by either calling the RecordBrowserNew method directly or creating hostname/address/service resolvers/browsers that create those browsers internally themselves.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
Local DoS via reachable assertion in avahi-daemon allows application crash through D-Bus API abuse, directly matching Application or System Exploitation.
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
Mitigating Controls (NIST 800-53 r5) AI
Enforces D-Bus method authorization so unprivileged local users cannot invoke RecordBrowserNew or resolver methods that set AVAHI_LOOKUP_USE_WIDE_AREA.
Restricts the set of D-Bus interfaces and methods available to non-root users, directly blocking the call path used to trigger the reachable assertion.
Validates or rejects the AVAHI_LOOKUP_USE_WIDE_AREA flag and related browser parameters before they reach the assertion in avahi-daemon.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly prevent unsafe assertions from being coded in reachable paths.
Runtime monitoring of software can detect assertion-triggered crashes as adverse events.
Vulnerability identification processes can discover and record reachable-assertion flaws before deployment.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development can detect reachable assertions before release, reducing the likelihood of exploitation.
Secure development lifecycle mandates defensive coding and input validation that prevent reachable assertions from being triggered by untrusted data.
Application security requirements can specify that assertions must not be reachable from attacker-controlled inputs.
Secure architecture principles discourage the use of assertions for runtime error handling that an attacker could exploit.
Secure coding standards explicitly ban the use of assert() or equivalent statements that can be triggered by external input.