Guide · July 28, 2026 · 6 min read

Discord anti-nuke: stopping the destruction of your server

A nuke does not come from outside: it comes from an account you handed the keys to. This guide explains how these attacks happen, why permissions are not enough, and how to set up protection that holds.

Nuke and raid: two different attacks

A nuke is the destruction of a Discord server from the inside: every channel and every role deleted, members banned en masse, sometimes hundreds of spam channels created to make the server unusable.

The difference from a raid is essential:

Anti-raid does not protect against a nuke, and the reverse is equally true. Both are needed.

The three ways it happens

1. A stolen administrator account

The most common. A team member clicks a fake Nitro link, downloads “a friend's game” containing a token-grabber, or falls for a fake login page. The attacker recovers the session token and acts under their identity — no password, no two-factor prompt to get past.

2. A compromised bot

Many servers add bots with the Administrator permission so as not to have to think about it. If that bot's token leaks (a public repository, a badly configured host, a hacked developer), the attacker has a destruction tool already installed and already authorised.

3. A team member who goes off the rails

Rarer, but real: a moderator pushed aside, a disagreement that turns sour. The protection is the same, which is rather reassuring: it does not require assuming bad faith about anyone.

Why permissions are not enough

The natural reflex is to restrict permissions. That is necessary, but insufficient, for a simple reason:

Discord permissions determine who may act. They say nothing about how much, or how fast.

A legitimate administrator needs to be able to delete a channel. That same administrator can delete fifty in ten seconds, and no permission stands in the way. That is precisely where the blind spot lies.

Protection must therefore target the pace and the volume of actions, not the right to perform them.

The principle behind detection that works

Serious anti-nuke protection counts destructive actions per author, within a rolling time window. Concretely: “this account deleted 6 channels in 3 seconds”.

The actions to watch are always the same:

• Channel and role deletion
• Mass creation of channels or roles (spam)
• Bans and kicks in series
• Webhook creation (exfiltration, then spam)
• Sudden granting of sensitive permissions
• Server changes (name, image, vanity URL)

Telling tidying from sabotage

The real challenge is not detecting, it is not sanctioning an administrator who is tidying up their server. A raw threshold will not do: reorganising categories can legitimately delete a dozen channels.

The most reliable signal for telling them apart is the regularity of the intervals. A script acts at an almost constant cadence — a few tens of milliseconds between actions, always the same. A human clicking through the interface is irregular: they hesitate, confirm, move around the menu.

Add to that the account's age on the server, its nature (human or bot), the time of day, and its record. Protection that combines these signals fires before the threshold when the signature is machine-like, and stays silent during genuine tidying.

The blind spot: bots

Here is the least known problem, and the most serious. Most anti-nuke protections exempt bots on principle — often with a simple condition along the lines of “if the author is a bot, do nothing”.

The intention is understandable: stopping the ticket bot, which creates and deletes channels all day, from raising alerts constantly. But the consequence is that a compromised bot is completely untouchable, when it is one of the main nuke vectors.

The right approach is to watch bots, and to handle false positives another way:

• A trusted-account list for legitimate bots that handle channels continuously.
• Thresholds per action type: a ticket bot creates channels, it does not delete forty at once.
• A fitting sanction: stripping a bot's roles cuts its permissions immediately, even if the kick fails.

Setting up your protection

With OriusBot, through /anti-raid and then the smart anti-nuke page.

Starting thresholds

Sensible values for a medium-sized server, to be adjusted afterwards:

Who to watch

• Bots: yes. This is the point that makes the difference.
• Administrators: yes. A stolen administrator account is the leading vector; exempting it amounts to protecting nothing.
• The server owner: no. Never. A false detection must not be able to behead the server.
• A trusted list for ticket bots and temporary voice channel bots.

Which sanction

The most effective sanction is not the kick, it is the immediate removal of every role. It cuts the permissions in one action, even if the kick then fails on hierarchy grounds. Kicking or banning comes afterwards.

The permission you cannot skip

The bot needs View Audit Log. Without it, no destructive action can be attributed to an author, and the protection has nothing to fire on. It is the most frequent omission.

The hygiene that avoids the incident

Technical protection is the second line. The first remains hygiene:

• Two-factor authentication required for moderation (Server settings → Moderation). One setting, two clicks.
• No Administrator permission for bots. Give exactly what the bot needs. It is the only measure that genuinely neutralises the compromised-bot vector.
• Limit the number of administrators. Every administrator account is a key to the server.
• Review the installed bots once a quarter: remove those no longer used, check the permissions of the rest.
• Train the team on phishing: fake Nitro, fake partnerships, files “to test”. That is how tokens leak.

After a nuke

1. Cut off access. Strip the offending account's roles before anything else — it may still be acting.
2. Check the webhooks. An attacker often leaves some behind to come back. Server settings → Integrations.
3. Restore. Protection with restoration recreates the deleted channels and roles. Messages, though, are lost: Discord offers no backup.
4. Check the bans. Lift in bulk those issued during the incident.
5. Work out how they got in. Stolen account? Compromised bot? Without an answer, the incident will happen again.

Frequently asked questions

Can a nuke be undone?

Partly. Channels and roles can be recreated, but messages are lost for good — Discord offers no restoration. That is why protection has to block the attack in progress rather than repair afterwards.

Should I remove the Administrator permission from every bot?

Ideally, yes. In practice, some bots require it to work. If you must grant it, keep it for bots you know, and enable bot monitoring to keep a safety net.

Does two-factor authentication protect against token theft?

No, and this is a widespread misunderstanding. A token-grabber steals the session token, which bypasses two-factor authentication. It remains essential against password theft, but it is no substitute for anti-nuke protection.

How long does a nuke last?

A few seconds. A script deletes fifty channels faster than a human reads a notification. That is why the response has to be automatic.

Read next : Security checklist, Protecting your server from raids, Malicious files on Discord.