Apple forgot to sanitize the cellphone quantity subject for misplaced AirTags


Enlarge / Apple’s AirTags – as seen attached to a backpack above – allow users to find their own device by retransmitting the location from other Apple users. If all else fails, the user can activate a “lost mode” which is supposed to display their phone number when a finder scans the missing AirTag.

The hits keep coming back to Apple’s bug bounty program, which security researchers say is slow and inconsistent to respond to its vulnerability reports.

This time around, the Vuln du Jour is due to the failure to clean up a user input field – specifically the phone number field AirTag owners use to identify their lost devices.

The Good Samaritan Attack

AirTags are tiny, button-like devices that are personalized with an engraving and attached to easily lost devices either directly or via.  can be attached Enlarge / AirTags are tiny, button-like devices that can be personalized with an engraving and attached to easily lost devices either directly or via “loop” holders.

Security advisor and penetration tester Bobby Rauch discovered that Apple’s AirTags – tiny devices that can be attached to frequently lost items such as laptops, phones, or car keys – do not disinfect user input. This oversight opens the door to AirTags that can be used in a drop attack. Instead of loading a target’s parking lot with USB drives loaded with malware, an attacker can dump a maliciously prepared AirTag.

This type of attack doesn’t require a lot of technological know-how – the attacker simply enters valid XSS into the AirTag’s phone number field, then puts the AirTag in lost mode and places it in a location that the target is likely to find. Theoretically, scanning a lost AirTag is a safe action – only one website should appear at The problem is that then embeds the contents of the phone number field in the website as it appears in the victim’s browser, uncleaned.

The most obvious way to exploit this vulnerability, according to Rauch, is to use simple XSS to display a fake iCloud login dialog on the victim’s phone. This doesn’t require a lot of code:

If innocently embeds the above XSS in the response for a scanned AirTag, the victim will get a popup showing the contents of badside.tld / page.html. This can be a zero-day exploit for the browser or simply a phishing dialog. Rauch suspects a fake iCloud login dialog that may look exactly like the real one – but instead stores the victim’s Apple credentials on the target’s server.


While this is a compelling exploit, it’s nowhere near the only one available – pretty much everything you can do with a website is on the table and available. This ranges from simple phishing, as in the example above, to exposing the victim’s phone to a zero-day, no-click browser vulnerability.

More technical details – and simple videos showing both the vulnerability and network activity triggered by Rauch’s exploit of the vulnerability – are available from Rauch’s public disclosure on Medium.

This Apple Public Disclosure

According to a report by Krebs on Security, Rauch is publicly announcing the vulnerability, which is mainly due to communication errors from Apple – an increasingly common refrain.

Rauch told Krebs that he first privately disclosed the vulnerability to Apple on June 20, but for three months the company would only tell him it was “still under investigation.” This is an odd reaction to what appears to be an extremely simple bug that needs to be verified and mitigated. Last Thursday, Apple emailed Rauch to say that the vulnerability will be fixed in an upcoming update and asked him not to speak publicly about it in the meantime.

Apple never responded to basic questions Rauch asked, such as whether there was a schedule for fixing the bug, whether he should be credited with the report, and whether he was eligible for a bounty. Cupertino’s lack of communication caused Rauch to go public on Medium, though Apple requires researchers to keep their discoveries quiet if they want credit and / or compensation for their work.

Rauch agreed to work with Apple but asked the company to “provide some details on when they would like to fix this and whether there would be an appreciation or a bug bounty payout.” He also warned the company not to release in 90 days. Rauch says Apple’s response was, “Basically, we’d appreciate it if you didn’t leak this out.”

We asked Apple for a comment and will update here with each response.