The ungated path
The D2D and AWDL ingress paths in mDNSResponder bypass the trust-check gate introduced by CVE-2025-24129. A disclosure note on D2D-01, the DTrace false confirmation I self-corrected, and what Apple's closure means.
There is a particular quality of attention you develop running a honeynet. At Oracle, we built systems whose entire purpose was to watch — to observe what actually arrived, not what we expected. The honeypot doesn't argue with you. It just records what happened. The lesson I took from that work was not about the attackers. It was about the gap between what you think your instruments are telling you and what they are actually telling you. A response that looks like confirmation can be an error path wearing the right clothes.
I mention this because one of the instruments I used while researching this finding failed me in exactly that way. I am telling you that upfront, before I describe anything else, because it matters.
The finding
Component: mDNSResponder, D2D (device-to-device) and AWDL (Apple Wireless Direct Link) ingress paths, macOS 15 / 26
Context: CVE-2025-24129 introduced mdns_trust_checks_check_query as a gate on the primary mDNS ingress path. The D2D and AWDL handlers bypass this gate.
Evidence basis: Static binary analysis — nm and disassembly of arm64e mDNSResponder
Limitation: Runtime PoC requires AWDL-capable hardware. I did not have that hardware.
Status: Disclosed to Apple. Closed: "does not demonstrate exploitation of the described behaviour and does not meet the threshold for further investigation."
The patch for CVE-2025-24129 is visible in the binary. nm /usr/sbin/mDNSResponder | grep -i trust shows mdns_trust_checks_check_query and related symbols. In the primary mDNS execution path — the path that handles standard local mDNS queries on port 5353 — the trust check is called before the response handler. The call is there. It gates dispatch.
The D2D registration handler is different. In the arm64e binary, the D2D path — which handles device-to-device service registration and resolution over AWDL — calls directly into the response handler without the intervening trust check. The gate introduced by the CVE-2025-24129 patch is not present on this branch.
This is a patch-gap finding: the patch addressed the reported path and left an adjacent path ungated. Whether the ungated path is reachable with a malicious mDNS payload over AWDL — and whether reaching it produces exploitable behaviour — is a separate question from whether the gate is absent. The gate is absent. That is what the static analysis shows.
What I got wrong
My initial DTrace PoC for this finding printed CONFIRMED to the terminal. I interpreted this as runtime evidence that the ungated path had been reached. It was not. DTrace failed to attach to amfid silently — the script continued executing, reached the print statement via the error path, and output the confirmation string without having probed anything.
I identified this error before Apple acted on the finding and filed a correction with the submission. The corrected filing made clear that the DTrace confirmation was invalid and that my evidence was static only. The static binary evidence — the absence of the trust-check call in the D2D handler — is valid and was not affected by the DTrace error.
I am describing this correction in full because it is the honest account. Reporting a false confirmation and then quietly updating the filing is not the same as saying so publicly. So I am saying so.
Proof of concept (static analysis only)
#!/bin/bash
# Static analysis of mDNSResponder trust-check gate on macOS 15+
# arm64e binary — own hardware only
# Runtime PoC requires AWDL-capable hardware; not included here
# Step 1: Confirm trust-check symbols are present in the binary
nm /usr/sbin/mDNSResponder | grep -i trust
# Expected: mdns_trust_checks_check_query and related symbols
# Step 2: Confirm the primary mDNS path calls the gate
# (disassembly required — Hopper, Binary Ninja, or radare2)
# The mDNS_Execute path calls mdns_trust_checks_check_query
# before dispatching to the response handler.
# Step 3: Examine the D2D handler
# D2D_RegisterService / D2D_ResolveService paths
# do NOT call mdns_trust_checks_check_query;
# they dispatch directly into the response handler.
# To verify:
# 1. Locate D2D handler symbols:
nm /usr/sbin/mDNSResponder | grep -i -E '(D2D|AWDL)'
# 2. Disassemble each handler and search for
# the trust_checks call — it is absent in the D2D branch.Apple's response and honest assessment
Apple closed this finding with the statement that it "does not demonstrate exploitation of the described behaviour and does not meet the threshold for further investigation." That is an accurate characterisation of the state of my submission at the time of closure. Without AWDL-capable hardware I could not produce a runtime injection PoC. The static evidence shows the gate is absent; it does not show that reaching the ungated path produces exploitable behaviour.
In my view, Apple's closure reasoning is sound. A patch-gap observation supported only by static analysis, with no runtime PoC demonstrating actual mDNS injection over AWDL, does not meet the evidentiary standard that Apple requires for further investigation. The standard is reasonable. My inability to meet it reflects a genuine limitation of solo research without the relevant hardware, not a flaw in Apple's process. The finding is architecturally valid — the gate is absent where it should be present. Whether that absence is reachable in practice, and whether reaching it produces anything beyond the theoretical, requires a runtime demonstration I could not produce. I submitted what I had and was clear about what I lacked. The static evidence stands. The closure is fair.
If you are researching this area and have AWDL hardware, the question worth answering is whether a crafted mDNS response injected over an AWDL-adjacent channel reaches the ungated D2D handler and produces behaviour that the primary path's trust check would have blocked. The static picture says the gate is absent. What happens at the gate is still open.
Disclosure note
This finding was submitted to Apple through the Apple Security Research Framework. Apple confirmed closure. This post discloses the static analysis finding in accordance with responsible disclosure practice. The DTrace error and subsequent correction are reported here in full. The PoC above requires your own hardware and performs static analysis only.
Are you there? The honeynet says you were. The instrument says it confirmed it. One of those things is true.