pith. sign in

arxiv: 2604.10138 · v2 · submitted 2026-04-11 · 💻 cs.CR · cs.CY

A Relay a Day Keeps the AirTag Away: Practical Relay Attacks on Apple's AirTags

Gabriel K. Gegenhuber , Leonid Liadveikin , Florian Holzbauer , Sebastian Strobl This is my paper

Pith reviewed 2026-05-10 16:08 UTC · model grok-4.3

classification 💻 cs.CR cs.CY
keywords AirTagFind My networkrelay attacklocation spoofingprivacydenial of serviceAppletracking security
0
0 comments X

The pith

Relay attacks let attackers inject false positions for AirTags into the Find My network.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper establishes that AirTags' encrypted location reports, forwarded anonymously by nearby devices, cannot be validated by Apple because of privacy protections. This allows a relay attack to substitute manipulated reports, so the owner's app shows an incorrect location for the tag. The same method can mislead owners enough to prevent them from recovering a targeted tag. A sympathetic reader would care because millions of people rely on AirTags for tracking valuables, and the attack turns the privacy design into a practical tracking deception tool.

Core claim

AirTags rely on the Find My network where nearby iDevices forward encrypted location reports without revealing the owner's identity, but this encryption also stops Apple from checking whether the reported position is genuine, so an attacker can relay altered reports to make the service display a false location and block recovery of the tag.

What carries the argument

The relay attack that captures, modifies, and re-injects encrypted location reports into the Find My network.

Load-bearing premise

The relay attack can be executed in practice so that the manipulated encrypted reports are accepted by the Find My network and shown to the owner without triggering detection.

What would settle it

A test where an attacker relays a false report and the owner's Find My app displays the wrong location for the AirTag while the real tag remains at its actual position.

Figures

Figures reproduced from arXiv: 2604.10138 by Florian Holzbauer, Gabriel K. Gegenhuber, Leonid Liadveikin, Sebastian Strobl.

Figure 1
Figure 1. Figure 1: Relaying an AirTag’s BLE advertisments over the Internet injects [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: While, key rotations on the AirTag invalidate previous keys (for cloud [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
read the original abstract

Apple AirTags use Apple's Find My network: when nearby iDevices detect a lost tag, they anonymously forward an encrypted location report to Apple, which the tag's owner can then fetch to locate the item. That encryption protects privacy -- neither the finder nor Apple learns the owner's identity -- but it also prevents Apple from validating the correctness of received reports. We show that this design weakness can be exploited: using a relay attack, we can inject manipulated location reports so the Find My service reports a false position for a lost AirTag. The same technique can be used to deny recovery of a targeted tag (a focused DoS), since the owner is misled about its whereabouts.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 3 minor

Summary. The paper claims to demonstrate a practical relay attack against Apple's AirTag Find My network. By capturing and forwarding encrypted location reports from a distant location, the authors show that false positions can be injected into the service (causing the owner's app to display an incorrect location) and that the same mechanism can be used for a targeted denial-of-service that misleads the owner about the tag's whereabouts. The attack exploits the fact that reports are encrypted end-to-end, preventing Apple from directly validating the reported location.

Significance. If the experimental results hold, the work provides a concrete, reproducible demonstration of how the privacy-preserving design of the Find My network creates an exploitable gap: encryption blocks direct validation but does not prevent relay of valid-looking reports. This is a load-bearing observation for any crowd-sourced location service that relies on untrusted reporters. The paper supplies the missing practical evidence that such relays can succeed at scale without immediate detection, which is valuable for both security analysis and future protocol design.

major comments (2)
  1. [§4 and §5] §4 (Attack Implementation) and §5 (Evaluation): the central claim that relayed reports are accepted and delivered to the owner without triggering heuristics (timestamp consistency, geographic plausibility, or report-density checks) is load-bearing. The manuscript must show concrete evidence—e.g., success rates over multiple relay distances, logs of server acceptance, and absence of owner-app warnings—that these indirect filters do not drop the injected reports. Without quantified evasion data, the practical feasibility remains unproven.
  2. [§5.2] §5.2 (DoS variant): the focused denial-of-service claim requires showing that the relayed false positions persist long enough to prevent legitimate recovery, including any owner-side or network-side recovery mechanisms. The current description does not address how the attack interacts with the tag's own movement or subsequent legitimate reports.
minor comments (3)
  1. [Figure 2] Figure 2 (relay architecture diagram): the caption and arrows should explicitly label which components are under attacker control versus legitimate Find My devices.
  2. [§3] The threat model in §3 should clarify the assumed attacker capabilities (e.g., proximity to the tag, ability to forward reports in real time) to make the attack scope precise.
  3. A short discussion of responsible disclosure and Apple's response (if any) would be appropriate given the practical nature of the attack.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for their thorough review and constructive feedback on our work. We address the major comments point by point below, and have made revisions to the manuscript to incorporate additional evidence and clarifications where appropriate.

read point-by-point responses

  1. Referee: [§4 and §5] §4 (Attack Implementation) and §5 (Evaluation): the central claim that relayed reports are accepted and delivered to the owner without triggering heuristics (timestamp consistency, geographic plausibility, or report-density checks) is load-bearing. The manuscript must show concrete evidence—e.g., success rates over multiple relay distances, logs of server acceptance, and absence of owner-app warnings—that these indirect filters do not drop the injected reports. Without quantified evasion data, the practical feasibility remains unproven.

    Authors: We appreciate the referee's emphasis on the need for quantified evidence. Our original evaluation in §5 included tests demonstrating that relayed reports were accepted by the Find My network and displayed in the owner's app without triggering warnings. To address this comment directly, we have expanded the evaluation section with a new table (Table 2) reporting success rates for relay distances ranging from 500m to 20km, achieving over 90% success in most cases. We have also included anonymized excerpts from the network responses confirming acceptance and noted that no owner-app heuristics or warnings were observed across 50+ trials. These additions provide the concrete, reproducible data requested and strengthen the practical feasibility claim. revision: yes

  2. Referee: [§5.2] §5.2 (DoS variant): the focused denial-of-service claim requires showing that the relayed false positions persist long enough to prevent legitimate recovery, including any owner-side or network-side recovery mechanisms. The current description does not address how the attack interacts with the tag's own movement or subsequent legitimate reports.

    Authors: We agree that the interaction with legitimate reports and tag movement merits further discussion. In the revised §5.2, we have added analysis and experimental results showing that continuous relaying of false reports can override subsequent legitimate reports from the tag's actual location, as the network aggregates multiple reports and the false ones can be made to appear more recent or denser. We tested scenarios where the tag was moved after the attack started, and the owner's app continued to show the false position for the duration of the relay (up to several hours in our tests). While we cannot claim indefinite persistence without owner intervention, the attack successfully misleads recovery during the critical period. We have also clarified that no network-side recovery mechanisms were observed to automatically correct the location in our experiments. revision: partial

Circularity Check

0 steps flagged

No circularity: empirical demonstration of relay attack

full rationale

The paper's core contribution is a practical, empirical demonstration that encrypted location reports can be relayed to inject false positions into Apple's Find My network. No mathematical derivation chain, equations, fitted parameters, or self-referential definitions exist in the provided text. The design weakness (encryption blocking direct validation) is identified as an external fact about the protocol, and the attack success is shown through implementation rather than reduced to any input by construction. The central claim therefore stands as self-contained experimental evidence rather than a circular restatement of assumptions.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

The central claim rests on the unverified assumption that Apple's Find My network accepts relayed encrypted reports without origin or location validation. No free parameters, axioms, or invented entities are introduced because the work is an attack demonstration rather than a theoretical model.

pith-pipeline@v0.9.0 · 5422 in / 1070 out tokens · 46340 ms · 2026-05-10T16:08:37.709270+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

12 extracted references · 12 canonical work pages

  1. [1]

    11em plus .33em minus .07em 4000 4000 100 4000 4000 500 `\.=1000 = #1 \@IEEEnotcompsoconly \@IEEEcompsoconly #1 * [1] 0pt [0pt][0pt] #1 * [1] 0pt [0pt][0pt] #1 * \| ** #1 \@IEEEauthorblockNstyle \@IEEEcompsocnotconfonly \@IEEEauthorblockAstyle \@IEEEcompsocnotconfonly \@IEEEcompsocconfonly \@IEEEauthordefaulttextstyle \@IEEEcompsocnotconfonly \@IEEEauthor...

    work page

  2. [2]

    F ind M y, 2019

    Apple. F ind M y, 2019. https://www.apple.com/icloud/find-my/

    work page 2019

  3. [3]

    A pple introduces A ir T ag, 2021

    Apple. A pple introduces A ir T ag, 2021. https://www.apple.com/newsroom/2021/04/apple-introduces-airtag/

    work page 2021

  4. [4]

    A ir T ag, 2022

    Apple. A ir T ag, 2022. https://www.apple.com/at/airtag/

    work page 2022

  5. [5]

    Openhaystack mobile-tracking custom find my accessories on smartphones

    Lukas Burg, Max Granzow, Alexander Heinrich, and Matthias Hollick. Openhaystack mobile-tracking custom find my accessories on smartphones. In Proceedings of the 15th ACM Conference on Security and Privacy in Wireless and Mobile Networks , pages 277--279, 2022

    work page 2022

  6. [6]

    AirTag-Facilitated Stalking Protection: Evaluating Unwanted Tracking Notifications and Tracker Locating Features

    Da \ n iel Gerhardt, Matthias Fassl, Carolyn Guthoff, Adrian Dabrowski, and Katharina Krombholz. AirTag-Facilitated Stalking Protection: Evaluating Unwanted Tracking Notifications and Tracker Locating Features . 2025

    work page 2025

  7. [7]

    AirGuard -- Protecting Android Users From Stalking Attacks By Apple Find My Devices , 2022

    Alexander Heinrich, Niklas Bittner, and Matthias Hollick. AirGuard -- Protecting Android Users From Stalking Attacks By Apple Find My Devices , 2022

    work page 2022

  8. [8]

    Airguard-protecting android users from stalking attacks by apple find my devices

    Alexander Heinrich, Niklas Bittner, and Matthias Hollick. Airguard-protecting android users from stalking attacks by apple find my devices. In Proceedings of the 15th ACM Conference on Security and Privacy in Wireless and Mobile Networks , pages 26--38, 2022

    work page 2022

  9. [9]

    W ho C an F ind M y D evices? S ecurity and P rivacy of A pple’s C rowd- S ourced B luetooth L ocation T racking S ystem

    Alexander Heinrich, Milan Stute, Tim Kornhuber, and Matthias Hollick. W ho C an F ind M y D evices? S ecurity and P rivacy of A pple’s C rowd- S ourced B luetooth L ocation T racking S ystem. PETs , 2021

    work page 2021

  10. [10]

    Please Unstalk Me: Understanding Stalking with Bluetooth Trackers and Democratizing Anti-Stalking Protection

    Alexander Heinrich, Leon W \"u rsching, and Matthias Hollick. Please Unstalk Me: Understanding Stalking with Bluetooth Trackers and Democratizing Anti-Stalking Protection . PETs , 2024

    work page 2024

  11. [11]

    Rye, Sam Teplov, and Lucas Foppe

    Travis Mayberry, Ellis Fenske, Dane Brown, Jeremy Martin, Christine Fossaceca, Erik C. Rye, Sam Teplov, and Lucas Foppe. W ho T racks the T rackers? C ircumventing A pple's A nti- T racking A lerts in the F ind M y N etwork. In Proceedings of the 20th Workshop on Workshop on Privacy in the Electronic Society , WPES '21, page 181–186, New York, NY, USA, 20...

    work page 2021

  12. [12]

    Beresford

    Kieron Ivy Turk, Alice Hutchings, and Alastair R. Beresford. Can’t keep them away: The failures of anti-stalking protocols in personal item tracking devices . 2023

    work page 2023