AirDrop and Quick Share vulnerabilities affect protocols on five billion devices as fixes begin
Phones and laptops ship with a feature that sends files to nearby devices over the air, with no cables, accounts, or prior pairing. Apple calls its version AirDrop. Google and Samsung call theirs Quick Share. Both run inside privileged background services that wake when another device comes within wireless range, and both read a stack of serialized data formats sent by devices they have never met. More than five billion active devices run one of the two.
Researchers at the CISPA Helmholtz Center for Information Security examined both systems and came away with six vulnerabilities spanning macOS, iOS, Android, and Windows. Arash Ale Ebrahim and Nils Ole Tippenhauer reverse engineered the application-layer protocols, built a custom fuzzer for AirDrop, and ran targeted analysis on Quick Share. The work is the first cross-platform look at how both stacks behave above the radio layer.
The attack surface and the test setup
A proximity attacker needs a laptop with Wi-Fi and a spot within range, often 10 to 30 meters. No pairing, contact exchange, or shared network is required. On Apple devices set to receive from “Everyone,” the early protocol phases respond before any user prompt appears. Quick Share answers nearby devices by default once it is visible.
The AirDrop work centered on sharingd, the macOS and iOS daemon that also runs AirPlay, Handoff, Universal Clipboard, and Continuity Camera. A crash in any one of those subsystems takes the rest down with it. The Quick Share work used a Samsung Galaxy S23 Ultra and Google’s Windows client.
To reach deeper code paths, the team wrote a custom fuzzer that mutates raw archive content before the data gets compressed. That single design choice raised the share of inputs the server accepted from a tiny fraction to more than 90 percent, opening up the archive-handling code to meaningful testing.
Crashes in Apple’s sharing daemon
The three AirDrop findings all end in a crash. The simplest comes from a Swift fatalError call in the code that routes incoming web requests by path. A request to an unrecognized path hits that call and aborts the whole process. One short request takes down AirDrop, AirPlay, Handoff, Universal Clipboard, and Continuity Camera at once. Sent in a loop every couple of seconds, it holds the service down. During one test, the legitimate connection attempts all failed under the attack and all succeeded again once it stopped.
The second issue lives in Foundation, Apple’s base framework. An XML property list parser recurses with no depth limit, so a document with about 200 nested elements exhausts the thread stack and faults. The reach extends to any Apple app that decodes untrusted XML property lists, across macOS, iOS, watchOS, tvOS, and visionOS. The third bug is a null pointer dereference in the system HTTP parser, reachable with malformed length and chunk headers.
Bypasses and a use-after-free in Quick Share
The Quick Share findings move from crashes to protocol logic. The first lets an attacker drive the connection state machine ahead of authentication. The Samsung implementation dispatches application frames right after the opening connection request, before the UKEY2 key exchange that is meant to gate everything after it. Three frame types get parsed and answered with no secrets exchanged, a result reproduced in every trial.
The second bypass sits one step later. After the key exchange finishes and session keys exist, three of the seven post-handshake frame types still get processed when sent as plain, unencrypted data. An on-path attacker on the same Wi-Fi can push a connection into an accepted state, keep a session alive, and feed the server attacker-supplied addresses.
The Windows client holds the one memory-corruption bug in the set. A use-after-free occurs when two connections collide on the same endpoint identifier and nonce, freeing an object that another thread then calls into. A developer comment in the source even marks the spot: “We had a bug here, caused by a race with EncryptionRunner.” The applied fix reads the freed object during its check, opening the same hole again. Google awarded a bounty for it. The team confirmed a crash and stopped short of a working exploit.
A common root cause across both stacks
The two designs took separate routes and landed on overlapping weaknesses. Apple’s daemon serializes requests through a single lock, which keeps races rare and leaves reliability code such as fatalError as the exposed risk. Google and Samsung’s endpoint manager runs many threads, and that concurrency produced the Windows race. The Samsung bypasses share one cause: authentication and encryption get checked inside individual frame handlers, so any handler that omits the check becomes a gap.
Ale Ebrahim ties that pattern to the job these services do. “I don’t think the overlap is unique to Apple or Google,” he said. “Instead, it reflects common engineering challenges in proximity-based protocols. These services are designed to provide a seamless user experience, which means privileged daemons have to process complex, attacker-controlled inputs before authentication or user approval has taken place. That inevitably creates a large pre-authentication attack surface.”
The convergence stood out to him because the stacks share so little code. “What I found particularly interesting is that the two ecosystems arrived at similar classes of weaknesses through entirely different implementations,” Ale Ebrahim told Help Net Security. He placed each set of bugs in its own corner of the design: “In AirDrop, the issues were primarily related to parser robustness and network-reachable fatal assertions. In Quick Share, the more significant problems came from security checks being enforced by individual handlers rather than centrally, together with concurrency issues in endpoint lifecycle management.” The common thread, in his words: “Different codebases, but ultimately the same architectural pattern: security-critical invariants were not enforced at a single boundary.”
Three principles for future protocols
Ale Ebrahim pointed to three principles for proximity protocols built from here. The first moves the security checks to one place. “Authentication and encryption should be enforced once at the dispatcher or framework boundary instead of relying on individual protocol handlers,” he said. The second shrinks the exposed code. “The amount of privileged code reachable before authentication should be minimized as much as possible,” Ale Ebrahim said. The third folds the kind of testing behind this paper into routine work. “Protocol-aware fuzzing and state-machine testing should become part of the standard development process, since these protocols are highly stateful and traditional API or file fuzzing rarely exercises the most security-critical execution paths,” he said.
Disclosure status
Some of this has moved in the days since the paper was finalized in late June 2026. One AirDrop bug now has a fix and an identifier, according to Ale Ebrahim. “Apple informed us that one of the reported AirDrop vulnerabilities has been fixed in a software update and has been assigned a CVE identifier,” he said. The advisory stays private for now. “The corresponding security advisory and CVE have not yet been published publicly, so I cannot share additional details at this stage,” Ale Ebrahim said, adding that “the remaining Apple reports are still under coordinated disclosure and have not yet received public CVE assignments.”
The Quick Share side has shifted as well. The two Samsung bugs sent upstream remain under investigation at Google. The Windows use-after-free drew a bounty through Google’s reward program, and a code fix has now landed. “Since the paper was finalized, Google has also landed a fix for the affected Windows codebase, although a public CVE assignment is still pending,” Ale Ebrahim said. The researchers released their fuzzer, crash scripts, and protocol notes for others to check the work.
Guide: What automated pentesting alone cannot see