mDNS Detection

Plugin 12218 is not finding code execution, auth bypass, or a memory corruption bug. It is finding a host that answers mDNS/Bonjour requests and leaks inventory-style details such as hostname, service list, interface addresses, and sometimes enough fingerprints to infer OS family or exact build. The affected range is not a software version range in the usual CVE sense; it is any device or host running an mDNS responder that will answer from a remotely reachable segment, whether that responder is Apple Bonjour, Avahi, embedded IoT firmware, or another DNS-SD implementation.

Tenable's MEDIUM label reflects confidentiality exposure in the abstract, but in enterprise reality this is usually over-scored. mDNS is designed for the local link, with TTL and multicast scope intended to keep it local; if this plugin fires, the more important story is segmentation drift, an mDNS gateway/repeater, or a device answering unicast queries it should not answer. The impact is reconnaissance fuel, not compromise by itself, so the right operational bucket is LOW unless the responder is directly reachable from the Internet or is disclosing unusually sensitive service metadata.

Why this verdict

• Major downward adjustment: requires unusual reachability. mDNS is a local-link protocol by design, so remote visibility means the attacker already has internal network position or the environment is misconfigured to expose UDP/5353 across boundaries.
• Second downward adjustment: no compromise primitive. The finding leaks host and service metadata, but it does not grant execution, auth bypass, privilege escalation, or durable persistence.
• Not ignored entirely: it exposes useful targeting data. Hostnames, TXT records, service types, and local addresses can materially improve follow-on phishing, lateral movement planning, and asset fingerprinting.

Why not higher?

There is no direct path from this finding to code execution or privilege gain. The attack chain depends on a separate initial access or follow-on exploit, and the population that is remotely reachable is much smaller than the vendor score implies because normal routing and firewall policy should keep mDNS local.

Why not lower?

It is still real information disclosure when the plugin fires. If a host answers remotely, you have either Internet exposure or cross-segment leakage of a protocol that routinely reveals asset identity and service inventory, which is worth fixing even if it is not urgent.

1. Block UDP/5353 at trust boundaries — Enforce ACLs/firewall policy so mDNS stays on the local link and cannot cross user/server, server/management, or perimeter boundaries. For a LOW verdict there is no SLA; treat this as backlog hygiene and deploy in the next normal network change window.
2. Disable unnecessary responders — Turn off Bonjour/Avahi/embedded DNS-SD advertising on servers and appliances that do not need zero-config discovery. This reduces passive metadata leakage and should be handled as routine hardening with no SLA; treat as backlog hygiene.
3. Audit mDNS gateways and reflectors — Review wireless controllers, IoT gateway features, Bonjour gateways, and multicast repeaters that intentionally bridge discovery across VLANs. Keep only explicit business-required service types and remove broad forwarding during the same hygiene cycle.
4. Suppress vuln noise with exposure context — If the finding is limited to internal user subnets and only discloses commodity workstation/printer metadata, document the exposure class and avoid escalating it like a real vuln. Use asset tags or scanner exceptions so your queue reflects actual exploitability.

Run this from an auditor workstation, scanner node, or jump host that has the same network reachability as the scanner finding. Invoke it as ./check_mdns_remote.sh 10.20.30.40; it needs dig installed and does not require root. The script sends a direct DNS-SD PTR query to UDP/5353 and reports whether the host answers with service data.

#!/usr/bin/env bash
# check_mdns_remote.sh
# Verify whether a target answers remote mDNS/DNS-SD queries on UDP/5353.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -u

TARGET="${1:-}"
QUERY="_services._dns-sd._udp.local"

if [[ -z "$TARGET" ]]; then
  echo "UNKNOWN - usage: $0 <target-ip-or-hostname>"
  exit 2
fi

if ! command -v dig >/dev/null 2>&1; then
  echo "UNKNOWN - 'dig' not found; install dnsutils/bind-utils"
  exit 2
fi

# Ask the target directly on UDP/5353 for DNS-SD service enumeration.
# Some responders will not answer unicast queries; that is expected and will be reported as PATCHED here,
# meaning 'not remotely answering in the way plugin 12218 depends on'.
OUT=$(dig @"$TARGET" -p 5353 "$QUERY" PTR +time=2 +tries=1 +short 2>/dev/null)
RC=$?

if [[ $RC -ne 0 ]]; then
  echo "UNKNOWN - dig query failed"
  exit 2
fi

if [[ -n "$OUT" ]]; then
  echo "VULNERABLE - target answered remote mDNS/DNS-SD query on UDP/5353: $OUT"
  exit 0
fi

# Fallback: ask for a common workstation PTR name pattern. This is still safe and lightweight.
OUT2=$(dig @"$TARGET" -p 5353 _workstation._tcp.local PTR +time=2 +tries=1 +short 2>/dev/null)
RC2=$?

if [[ $RC2 -ne 0 ]]; then
  echo "UNKNOWN - fallback dig query failed"
  exit 2
fi

if [[ -n "$OUT2" ]]; then
  echo "VULNERABLE - target answered remote mDNS workstation query on UDP/5353: $OUT2"
  exit 0
fi

echo "PATCHED - no remote mDNS/DNS-SD response observed on UDP/5353"
exit 1

Sources

1. Tenable Nessus Plugin 12218
2. RFC 6762 Multicast DNS
3. Apple Bonjour security implications
4. Cisco Bonjour / mDNS local-link behavior
5. Shadowserver Open mDNS Report
6. Censys Internet scanning coverage
7. Nmap dns-service-discovery NSE
8. IANA port 5353 registry