Anatomy of a Discord nuke attack — and how to survive it

A "nuke" is the worst thirty seconds a Discord server can have. One account with the wrong permissions runs a script, and by the time anyone reacts every channel is gone, every role is deleted, half the members are banned, and the server name is something you can't repeat. This post walks through how it actually happens, why the usual response fails, and what genuinely stops it.

How the attacker gets in

A nuke needs an account with Administrator, or the specific combination of Manage Channels, Manage Roles, Ban Members and Manage Webhooks. There are only a few ways that account ends up in the wrong hands:

• A compromised admin. The most common one. An admin reuses a password, clicks a fake "Discord Nitro" or "Steam gift" link, or runs a "free tool" that steals their token. The attacker now *is* that admin — no login prompt, no 2FA challenge.
• A malicious bot. Someone with Manage Server adds a bot that asks for Administrator "to work properly". Weeks later it fires.
• Rogue staff. A moderator who was promoted too fast and holds a grudge, or a staff account that got sold.
• A social-engineered owner. "Hey, I'm from Discord Trust & Safety, add this bot to verify your server."

Almost every nuke traces back to an account that already had permission. The attack is a permissions problem before it is a security-tool problem.

The sequence, second by second

Once the account is in hand, the script runs in a fixed order because Discord rate-limits each action type separately. A typical run:

1. 1Mass channel delete — every channel, a few per second. This is usually first because it removes the places where staff would coordinate a response.
2. 2Mass role delete — including staff roles, so no one can re-lock anything.
3. 3Mass ban — members are banned in bulk; on large servers the script prioritises staff and boosters.
4. 4Webhook spam — new webhooks in any surviving channel, blasting @everyone pings and invite links to other servers.
5. 5Cosmetic wreckage — server name, icon and vanity URL changed, new channels named to humiliate.

The whole thing is over in 10–40 seconds. There is no "noticing it happening" — you notice it *happened*.

Why the manual response fails

The instinct is to jump in and start fixing: remove the attacker's roles, re-create channels, unban people. Three reasons that never works during the attack:

• You can't out-click a script. It does 5–10 actions per second. You do maybe one every two seconds, and you have to *find* the attacker first.
• The coordination channels are gone. Staff can't agree on who does what because #staff was the first thing deleted.
• Discord's own limits work against you. After the dust settles, re-creating 60 channels and unbanning 200 members hits the same rate limits the attacker did — recovery takes hours.

Manual effort is for *recovery*, not defence. Defence has to be automatic and it has to be faster than the script.

What actually stops a nuke

Every effective anti-nuke system does the same three things, in this order:

1. 1Watch the audit log in real time. Discord writes an audit-log entry for every destructive action and streams events over the gateway. A watcher sees "user X deleted channel #5" the instant it happens.
2. 2Count per actor, per window. "More than N channel deletes / role deletes / bans by the same non-whitelisted user in T seconds" is the trigger. Legit admin work never trips a sane threshold; a script trips it on action three.
3. 3Neutralise the actor, then freeze. Strip every role from the offending account (which removes its permissions), ban it, and lock the server so nothing else can be deleted while you assess. Total time from first bad action to locked: under a second.

The key idea: you don't react to a nuke, you make it impossible to finish. The attacker gets two or three deletes, then loses the permission to do the fourth.

Harden the server so it barely matters

Anti-nuke automation is the safety net. These reduce the chance you ever need it:

• Require 2FA for moderation (Server Settings → Safety Setup). A stolen password alone can no longer act.
• Count your admins. Every account with Administrator is a full copy of the keys. Most servers need two or three, not fifteen. Give staff the specific permissions they use instead.
• Fix the role hierarchy. Bots and junior staff should sit *below* the roles they might be tricked into touching. A bot can't delete a role above its own highest role.
• Audit bot permissions. No bot needs Administrator "to work properly". If it asks, that's the story. Grant the four or five permissions it actually uses.
• Review the audit log weekly. Unexpected role changes and new webhooks are the early warning that something is already wrong.
• Keep an off-server backup of your channel/role structure and important settings, so recovery is a restore, not a rebuild.

How Salazar handles it

Salazar's anti-nuke watches for mass channel/role deletion and mass bans in real time. When a non-whitelisted account crosses your thresholds it strips the account's permissions and locks the server automatically, then pings your staff role with what happened and who did it. Anti-raid does the same for sudden join floods. A trusted-admin whitelist keeps your own bulk work from tripping it, and one command lifts the lockdown once you've checked things over.

It's part of the same bot that does your logging, verification and tickets — add it to your server and the security suite starts at €5/mo. See how it compares on the comparison pages.