Push bombing

Push bombing is the repeated triggering of a system-level approval prompt on a target's trusted device, in the hope that the target eventually approves one — by reflex, by accident, or by fatigue after the prompt has surfaced enough times that they stop reading it and start swatting it away. It exploits the human at the device, not the device itself. The attacker needs no password. They need one mistaken tap.

On Apple accounts the prompt is the password-reset dialog: Use this iPhone to reset your Apple Account password, with two buttons — Don't Allow and Allow. It appears on every device signed into the account whenever someone initiates a reset. An attacker who knows the target's Apple ID — an email address or phone number, not the password — can initiate that reset at will, and repeat it.

How it looks on the receiving end

• A "Reset Password" / "Sign-in requested" / "Approve this sign-in?" prompt the recipient did not initiate.
• It returns. Once is a glitch; a run of them — sometimes dozens in a stretch — is the attack.
• It may be followed by a phone call. The caller claims to be Apple Support (or the platform's support), says they have detected suspicious activity, and asks the target to read back a code or approve a prompt "to secure the account." This is the same operation from the other side: the bombing softens the target up, the call closes the takeover.

What it produces, if it works

A single approval hands the initiating party the ability to complete the reset and lock the real owner out — email, photos, backups, location, the linked-device web, payment methods, everything the account gates. On a tightly integrated platform like Apple, account takeover is close to total.

Why it works

The defense is one button, and the attack knows it. Every prompt is a fresh chance for the target to tap the wrong one. Fatigue is the actual weapon: a person who has dismissed the same dialog twenty times is likelier to misfire on the twenty-first — especially if it surfaces mid-task, mid-call, or half-asleep. The technique does not need to be clever. It needs to be persistent, and to wait for one tired thumb.

The benign overlay

A single unexpected reset prompt is not, by itself, proof of an attack. It can fire from a mistyped Apple ID close to the target's, a fumbled recovery flow, or the target's own forgotten sign-in elsewhere. The innocent-misfire base rate is real — for one prompt. It does not extend to a sustained run: the system only sends the prompt when a reset is actively requested against the specific account, so a pattern of them is a pattern of deliberate requests. Frequency is the tell that separates noise from operation.

Defensive posture

• Never approve a prompt you did not initiate. Don't Allow, every time. The whole contest is that one button.
• Treat any "support" call that follows as part of the attack. Apple does not call to ask for codes or approvals; no legitimate platform does. Hang up and reach support through the official app or site if needed.
• If it persists, the attacker has your account identifier. Consider changing the email address the account is built on — a fresh, non-public address is a harder target — and adding a hardware security key plus a recovery key, measures that make a reset uncompletable even on a mistaken tap.
• Log the pattern. Frequency and timing across a long window is the evidence that distinguishes a campaign from noise.