Are AirDrop and Quick Share Putting Your Device at Risk?

Are AirDrop and Quick Share Putting Your Device at Risk?

Rupert Marais has spent years dissecting the invisible threads that hold our digital lives together—our networks and the endpoint devices we carry everywhere. As the boundary between our hardware disappears through seamless features like AirDrop and Quick Share, the “handshake” between devices has become a critical battleground for privacy and stability. Today, we sit down with Rupert to discuss the recent discovery of six major vulnerabilities that threaten these ecosystems, impacting everything from the iPhone in your pocket to the Windows workstation on your desk. We will explore how these flaws bypass session checks, the specific technical failures in Apple and Google’s code, and why the drive for cross-platform interoperability might be opening new doors for local attackers.

Since AirDrop is deeply integrated with features like AirPlay and Handoff, how does a crash in the background sharing service impact the overall user experience and security of the Apple ecosystem?

When an attacker sends a malformed request to a device set to “Everyone,” they are essentially pulling the rug out from under the entire Apple Continuity suite. The background service known as sharingd is the central nervous system for everything we consider “magic” in the Apple world; it’s not just about sending a photo to a friend. When it crashes, you instantly lose the ability to use your Universal Clipboard, Handoff for switching apps between devices, and even NameDrop for sharing contact info. In our testing environment, sending these crash messages every two seconds effectively creates a persistent denial-of-service, ensuring no legitimate data gets through. It transforms a premium, interconnected experience into a series of isolated, frustrated silos where the user is left wondering why their devices have suddenly stopped talking to one another.

The research highlighted a stack overflow vulnerability within Apple’s XML property list parser; what makes a flaw like this so dangerous across multiple operating systems?

This is particularly concerning because the vulnerability lives in a shared framework, which is a fundamental building block for macOS, iOS, watchOS, and even visionOS. By crafting a tiny file with about 200 nested layers, an attacker triggers a parser path that these systems simply weren’t designed to handle, leading to an immediate crash. Because this parser is used by so many different apps to handle untrusted files, the attack surface isn’t limited to just AirDrop; any app opening a similar file could be compromised. We saw this specifically hit devices running macOS 15.7.4 and iOS 18, though it’s interesting to note that older builds like iOS 16 seemed to dodge this specific bullet. It shows that even as software evolves, legacy parsing logic can remain a hidden Achilles’ heel that affects billions of active devices.

When we look at the Android side, specifically Samsung’s implementation of Quick Share, what are the primary risks associated with bypassing the initial session handshake?

The Samsung flaws represent a fundamental breakdown in the “trust but verify” model that users rely on for wireless sharing. One of the vulnerabilities allows an unverified device to actually start driving the connection before any encryption has been established, which is essentially letting a stranger through the front door before they’ve even shown their ID. Another flaw allows certain control messages to remain unencrypted even after you think you’ve established a secure session with a trusted contact. This allows an attacker on the same local network to trick the system into an “accepted” state or manipulate the server to return attacker-supplied IP and port values. While we haven’t seen files being stolen in these specific tests, it completely nullifies the security promises these manufacturers make to their users, leaving them vulnerable to session hijacking.

Google’s Quick Share for Windows seems to have a recurring issue with memory management; how serious is this latest use-after-free bug, and what does the “race condition” irony tell us about the software’s development?

This is arguably the most dangerous flaw of the bunch because it’s a memory bug that could potentially be turned into a path for running attacker code. The crash happens when two connections collide at the exact right millisecond, causing the program to use a chunk of memory it has already thrown away. What’s truly stinging is that the program’s own source code actually had a comment admitting a previous bug in that same spot regarding a “race with EncryptionRunner.” The fix they wrote to handle that original problem ended up reintroducing the same kind of flaw, which shows how difficult it is to patch these high-speed concurrent processes. With Windows defenses like Control Flow Guard being switched off in this specific app, the vulnerability is much more plausible for exploitation, which is why it was critical for Google to land a code fix and pay out a bounty for the discovery.

Considering these attacks require the perpetrator to be within 10 to 30 meters, how should the average user weigh this risk compared to more traditional internet-based threats?

It’s a matter of context and environment; while it’s true these aren’t “internet-wide” threats, the high density of our modern world changes the math significantly. An attacker sitting in a crowded airport lounge, a busy train, or a professional conference can reach many devices at once with just a laptop and no prior connection. They don’t need to be on your Wi-Fi or have your phone number to cause these crashes or bypass checks. The researchers have even released their tools openly so other security teams can see how easily these findings are reproduced. Even if the risk feels “local,” the fact that over five billion devices are potentially in play means the pool of targets is massive, especially in urban centers where everyone has their sharing settings turned on.

With Google rolling out AirDrop interoperability for Quick Share, how does the requirement for iPhones to be set to “Everyone” complicate the security landscape?

This is a classic case of convenience clashing with security in a way that creates a new, awkward vulnerability window. For the new cross-platform sharing between Android and iOS to work, the iPhone must be set to receive from “Everyone,” which is the exact configuration required for the AirDrop crash bugs to be exploited. It puts users in a tough spot: if they want the ease of sharing files with their friends on different operating systems, they have to lower their shields to a known exploit path. This interoperability is rolling out across flagship Android phones right now, and unless users are extremely diligent about switching their settings back to “Contacts Only” immediately after a transfer, they are leaving a wide-open door for any nearby attacker to disrupt their device.

What is your forecast for the security of these seamless wireless ecosystems?

I predict we are going to see a major shift toward “Zero Trust” architectures even for local, peer-to-peer connections over the next few years. The current model, where security checks are often bolted onto individual message handlers rather than being enforced at the very front of the stack, is clearly failing under the scrutiny of researchers like Arash Ale Ebrahim and Nils Ole Tippenhauer. We’ve seen two independently built systems from the world’s largest tech giants fail in nearly identical ways, which tells me the industry needs a standardized, hardened protocol for these wireless handshakes. As we move forward, I expect Apple and Google will have to move away from these open “visibility” settings entirely in favor of more robust, identity-based discovery that doesn’t expose the underlying background services to crashes from unauthenticated requests.

Subscribe to our weekly news digest.

Join now and become a part of our fast-growing community.

Invalid Email Address
Thanks for Subscribing!
We'll be sending you our best soon!
Something went wrong, please try again later