TL;DR: In June 2026, I encountered a real-world scenario where an iPhone 13 (iOS 18.6), fraudulently locked via a phishing attack, could be fully unlocked by an unprivileged user through a factory reset followed by Device-to-Device Migration (Quick Start) from an older iPhone 7 (iOS 15.8.8). This allowed the attacker's Activation Lock to be silently replaced without credentials. After a 30-day responsible disclosure process, Apple indicated the behavior is no longer present in current builds. This article documents the technical findings, the disclosure timeline, and the broader implications for mobile theft protection.
1. The Incident
In early 2026, a device owner fell victim to a phishing scheme. An attacker obtained the victim's Apple ID credentials, replaced the legitimate account on the device with their own, enabled Find My, and marked the iPhone as lost-demanding a ransom for its return. When the victim refused to pay, the device remained permanently Activation Locked under the attacker's account.
The victim held legitimate proof of purchase but, due to local jurisdictional constraints, was unable to obtain timely law enforcement assistance. The device sat powered off for approximately six months.
I was asked to assist. The device was an iPhone 13 (Model MLPK3HN/A) running iOS 18.6. Upon first boot, it presented the standard Activation Lock screen, requesting the attacker's Apple ID credentials. The device was also flagged as lost in Find My.
A standard factory reset (via Settings → Erase All Content and Settings) did not remove the lock. This was expected: Activation Lock is a server-side mechanism tied to the device's serial number and IMEI, persisting across wipes and restores.
However, what happened next was not expected.
2. The Bypass
After the factory reset, the device entered the iOS Setup Assistant. I selected "Transfer from iPhone" (Quick Start / Device-to-Device Migration) and brought an older iPhone 7 (Model MN962RU/A) running iOS 15.8.8 into proximity.
The devices paired over Bluetooth and established a peer-to-peer Wi-Fi connection. During this phase, the iPhone 7 shared its internet connection with the target device. The migration completed successfully, transferring all data and settings from the iPhone 7 to the iPhone 13.
Following the migration, the iPhone 13 was fully activated and bound to the Apple ID of the iPhone 7-the legitimate source device. Checking Settings → Apple ID → Find My confirmed that the iPhone 13 now appeared under the source device's account, not the attacker's.
I then performed a second factory reset on the iPhone 13. Upon reboot, the device presented a clean Setup Assistant without the Activation Lock screen. The device was effectively unlocked, free of any remote lock, and fully usable.
The attacker's Apple ID no longer had any control over the device in Find My.
3. Technical Analysis
3.1 How Activation Lock Normally Works
Activation Lock is enforced by Apple's activation servers (albert.apple.com). When a device boots after a reset, it transmits its serial number and IMEI to Apple's backend. If the device is flagged as locked, the server responds with a challenge requiring the Apple ID and password of the account that owns the lock. This state persists regardless of local wipes, restarts, or even full firmware restores via Recovery Mode.
The security model assumes that only the legitimate account holder (or Apple, with proof of purchase) can remove the lock.
3.2 What Went Wrong
In this case, the server-side lock was bypassed-not by exploiting a memory corruption bug, nor by using stolen credentials, but by leveraging a legitimate user flow (Device-to-Device Migration) in an unintended way.
My working hypothesis is that during Quick Start, the activation server trusted the authenticated session of the source device (the iPhone 7 with a valid Apple ID) and processed an ownership transfer request for the target device without performing an atomic check against the existing Activation Lock record.
Specifically, the server may have conflated the source device's legitimate network session with authorization to modify the target device's lock state. When the target iPhone 13 sent its activation request-routed through the iPhone 7's authenticated internet connection-the server appears to have accepted the source device's Apple ID as the new owner, overwriting or temporarily suspending the attacker's lock.
A subsequent factory reset then cleared the newly bound lock, leaving the device unprotected.
3.3 Version Mismatch Hypothesis
Notably, this bypass involved a version mismatch between devices:
- Source: iPhone 7, iOS 15.8.8 (final supported release for this hardware)
- Target: iPhone 13, iOS 18.6 (latest stable release at the time)
I attempted a control experiment using an iPhone 4s (iOS 9.3.6) as the source device. Migration could not be initiated due to protocol incompatibility, confirming that the bypass is not universal and is likely dependent on specific iOS version ranges and hardware generations. This suggests that the server may have applied a legacy compatibility path when handling migration requests from older iOS versions, skipping modern lock-validation checks.
4. Reproduction Steps (Historical)
For transparency, the following steps were used to reproduce the behavior in June 2026. This behavior is no longer reproducible on current builds, as confirmed by Apple.
- Confirm Lock State: Power on the target iPhone 13. Observe the Activation Lock screen requesting the attacker's Apple ID.
- Factory Reset: Erase All Content and Settings via Settings, or restore via Recovery Mode.
- Initiate Quick Start: In Setup Assistant, select "Transfer from iPhone."
- Pair Devices: Bring the source iPhone 7 into proximity. Authenticate pairing with the source device's passcode.
- Complete Migration: Allow Device-to-Device Migration to finish. The target device activates under the source Apple ID.
- Verify Transfer: Check Settings → Apple ID → Find My on the target device. It now lists under the source account.
- Final Reset: Erase All Content and Settings again. The device reboots to a clean Setup Assistant without Activation Lock.
5. Responsible Disclosure Timeline
| Date | Event |
|---|---|
| June 8, 2026 | Initial report submitted to Apple Security Bounty, including device models, iOS versions, and detailed reproduction steps. |
| June 15, 2026 | Apple responds: "Thank you for the additional information." |
| June 26, 2026 | Apple responds: "After review this report seems to have already been mitigated by a previous update. If you are able to reproduce this on the latest build please let us know." |
| June 26, 2026 | I reply, clarifying that the target device has been returned to its owner and cannot be retested, but requesting CVE assignment, publication permission, and acknowledgment. |
| July 8, 2026 | Apple provides final assessment (see Section 6). |
Total disclosure window: 30 days.
6. Apple's Response
On July 8, 2026, Apple Product Security provided the following final assessment:
"Our assessment is that behavior of this kind would have been addressed by a prior update. However, because we were not able to reproduce or validate this specific report on a current build, it was not tracked as a distinct security issue, no CVE was assigned to it, and we are not able to identify a specific version or change as its fix."
"Since this was not tracked as a security issue on our side, there is no coordinated-disclosure timeline or embargo associated with it from us. Decisions about publishing your own research are yours to make."
Additionally, Apple noted that security acknowledgments are reserved for reports they are able to validate and track, and therefore no acknowledgment was provided for this specific submission.
Key Takeaways from the Response
- Explicit Publication Permission: Apple explicitly stated that publication decisions are mine to make. There is no embargo.
- Implicit Acknowledgment: The phrase "behavior of this kind would have been addressed by a prior update" indicates that Apple recognizes the described behavior as something that required mitigation, even if this specific report was not independently validated.
- No CVE: No CVE was assigned, likely because the issue could not be reproduced on current builds and was therefore not tracked as a distinct, current vulnerability.
7. Impact and Threat Model
At the time of discovery, this bypass had significant implications for the theft-protection model of iOS:
- Physical Access + Second Device: An attacker with physical access to a locked iPhone and any older, legitimate iPhone could potentially bypass Activation Lock without knowing any credentials.
- Ransomware Reversibility: Fraudulent locking schemes (where attackers phish credentials and lock devices for ransom) could be trivially reversed by anyone with a spare device and physical access.
- Resale Market: Stolen devices could be reactivated and resold after being flagged as lost in Find My.
The bypass did not require jailbreaking, MDM exploits, hardware glitching, or stolen credentials. It relied entirely on a server-side authorization gap in a legitimate user-facing feature.
Mitigation Recommendations
For Apple and other vendors building similar ecosystems:
- Server-Side Atomic Checks: Before processing any ownership transfer or migration request, the activation backend must verify that the target device is not currently under an unrelated Activation Lock. A "check-and-set" operation should prevent legacy compatibility paths from skipping modern security validations.
- Client-Side Warnings: Setup Assistant should display an explicit warning when attempting to migrate data to a device that is Activation Locked by a different account.
- Post-Migration Verification: The target device should independently re-verify its lock status with activation servers after migration completes, before allowing the new Apple ID to take full ownership.
8. Conclusion
This case highlights several important themes in modern mobile security research:
- Server-Side Logic Bugs Matter: Not all critical bypasses require memory corruption or exploit chains. Authorization gaps in trusted user flows can be just as impactful.
- Version Mismatch is a Valid Attack Vector: Legacy compatibility paths between old and new software versions can create unexpected security regressions.
- Responsible Disclosure Works: Even without a CVE, bounty, or formal acknowledgment, the disclosure process led to explicit publication permission and-most importantly-confirmed that the behavior is no longer present in current builds.
- User-First Ethics: The primary goal was to return a victim's device and ensure the gap was closed. Financial compensation was never the objective.
To the Apple Security team: thank you for reviewing the report and for the transparent communication regarding publication rights.
To the community: I hope this analysis contributes to a deeper understanding of activation security and encourages continued scrutiny of the trust boundaries between devices, users, and cloud backends.
About the Author
I am a security researcher and red team operator focused on mobile and systems security. I believe in responsible disclosure, user-first ethics, and the value of publishing technical findings to advance collective security knowledge.
If you have questions, corrections, or related findings, feel free to reach out in the comments or via [b0x@hackteam.red].
This article was published on [10.07.2026] following a 30-day responsible disclosure process with Apple Inc. All testing was conducted on devices with legitimate ownership. No unauthorized access to Apple systems was performed.
Top comments (0)