Inside the AirDrop code that routes incoming HTTP requests by path, there is a Swift fatalError call that fires when the path doesn’t match anything the router expects. Send one HTTP POST to an unknown path and the whole process aborts. The process in question is sharingd, and sharingd doesn’t just run AirDrop. It also runs AirPlay, Handoff, Universal Clipboard, Continuity Camera, and NameDrop. Kill it once and all of those features go down together on that device until it restarts the daemon.

A fatalError call in Swift is not a defensive check. It is a hard assertion that says: “if this happens, the code is in an impossible state, so crash rather than continue.” That is fine for internal invariants that only the developer can violate. It is not fine on a network-reachable code path where the input is coming from a stranger’s laptop across the room. The moment a fatalError sits between untrusted input and process survival, every unknown path becomes a remote crash.

Send those crash messages on a loop, about one every two seconds, and the researchers reported that legitimate AirDrop transfers stopped working entirely for the duration of the attack. A person at the next table over could hold your Apple ecosystem hostage from a laptop. This is the bug Apple already fixed. iOS 26.5.2 and macOS 26.5.2 shipped on June 29, 2026, one day before the CISPA paper hit, and Apple has confirmed a CVE was assigned. The public security advisory has not yet been released as of the paper’s finalization.

The second AirDrop bug isn’t really an AirDrop bug. It lives in Foundation, Apple’s core framework for handling data structures, and specifically in the XML property list parser. The parser processes nested dictionary structures without imposing a depth limit. When nesting reaches roughly 180 to 200 levels, the parser exhausts available stack memory and crashes.

A specially crafted discovery request with deeply nested plist data triggers the same failure anywhere untrusted property lists are parsed, not just in AirDrop. Any Apple app on macOS, iOS, watchOS, tvOS, or visionOS that opens an untrusted plist could hit the same code path. The researchers reproduced the AirDrop-facing crashes on macOS 15.7.4, macOS 26.3, iOS 18.x, and iOS 26.3. Older iOS 16 builds were not affected.

This is why “just patch AirDrop” is the wrong framing. The bug is a Foundation-level parsing problem, and AirDrop is only one of many attack surfaces that reaches it. This is still under coordinated disclosure with Apple.

The third AirDrop issue sits in Network.framework, Apple’s modern networking library that replaced the older BSD sockets pattern. Malformed HTTP framing, such as negative chunk sizes or conflicting Content-Length headers, forces the parser into an inconsistent state and triggers a null pointer dereference. Sharingd goes down with it, and every continuity service on the device goes down at the same time.

This is technically a post-accept vulnerability rather than a pure zero-click. The attacker has to be past the initial connection handshake to reach the malformed HTTP framing. In practice, on a device set to “Everyone,” that gate is thin. The researchers were able to reach the crash reliably across the same macOS and iOS versions that V2 affected.

The combined effect of V1, V2, and V3 is the same: sharingd dies. That single process is doing too much work. When it goes, users don’t lose one feature. They lose AirDrop, AirPlay, Handoff, Universal Clipboard, Continuity Camera, and NameDrop in the same instant. That’s the design lesson from the AirDrop half of this paper.

On the Android side, the researchers found two flaws in Samsung’s Quick Share implementation. V4 is a pre-authentication frame-processing bypass. Quick Share is supposed to complete a UKEY2 handshake before it processes any application-layer content, but certain frame messages get processed before that handshake completes. That means an attacker in proximity can drive the Quick Share protocol state machine with attacker-controlled content before cryptographic authentication even happens.

V5 is worse in principle. After UKEY2 completes and a secure session exists, certain control frames are still accepted in plaintext, even though they should be protected by the SecureMessage encryption layer. An attacker on the same Wi-Fi network could inject unencrypted control frames into an active Quick Share session, forcing it into an “accepted” state, keeping it alive artificially, or making the server return attacker-supplied IP and port values.

Neither V4 nor V5 was demonstrated to steal files. Both defeat the protections the system is supposed to provide, and both were tested on a Samsung Galaxy S23 Ultra. Samsung transferred both to Google, and they remain under investigation as of the paper’s finalization.

Some context helps here. UKEY2 is the key exchange protocol Google designed for exactly this kind of “two devices meeting for the first time” scenario, and it’s the same protocol that underpins Google’s Nearby Share family. Its whole point is to bootstrap a mutually authenticated session between devices that have no prior relationship. When frames get processed before UKEY2 completes, or when control frames pass in plaintext after it, the protocol’s core promise, that no attacker in the middle can meaningfully interfere, stops holding. This is why the paper flags handler-by-handler security enforcement as an anti-pattern. Central dispatcher enforcement would have caught both V4 and V5.

The most technically serious bug of the six is V6, a use-after-free memory corruption issue in Google’s Quick Share client for Windows. The researchers triggered it through a concurrent connect and disconnect sequence, described in the paper’s Table 1 as a race condition in endpoint lifecycle management. In principle, use-after-free bugs on Windows are the class most likely to enable actual remote code execution rather than just a crash.

Google took this one seriously. It awarded a bounty through its Vulnerability Reward Program, and the code fix has already landed. A CVE assignment is pending. Update the Quick Share Windows client now if you haven’t, because unlike the Samsung bugs, this one is fixed and public awareness is rising.

The researchers were careful to note that they did not demonstrate remote code execution against V6, only the memory-corruption class. That is honest security research. The class is dangerous enough that Google’s rapid patch and bounty response is the correct pattern. Compare it with V4 and V5, which are still in investigation.

The mechanics matter here. A use-after-free happens when code frees a chunk of memory but keeps using a pointer that still refers to the freed region. If an attacker can trigger a race that causes the free at just the wrong moment, or can arrange for new content to be placed at the freed address before it gets reused, they get a foothold. That foothold is not RCE by itself, but on Windows it is the class of primitive that most reliably leads there once combined with a heap-spray or type-confusion follow-up. That is why the paper flagged the race condition in endpoint lifecycle management as the underlying design flaw, not just the crash.