Your Discord Server Got Nuked

The first hour

The order matters more than the speed. Every step below depends on the one before it, and the most common expensive mistake is starting to rebuild while the attacker still has access.

What a nuke actually is

A nuke is bulk destruction carried out with legitimate permissions: channels deleted, roles removed, members mass-banned, the server renamed into nonsense. It is almost never an exploit. It is an account with too much power, used badly.

• A compromised moderator or admin account — the most common cause by a wide margin, usually a stolen token or reused password.
• A malicious bot granted Administrator during setup and never reviewed afterwards.
• A trusted person acting deliberately — a falling-out, a rival community, a departing staff member.
• A self-bot or token grabber that reached someone with dangerous permissions.

Because it runs on real permissions, no detection tool catches every variant. That is the reason a recovery layer is not optional — it is the plan for the case where prevention did its best and lost.

Step 1: Contain, before anything else

1. Strip the offending account. Remove its roles entirely rather than editing permissions one by one — faster and less error-prone under pressure.
2. Demote every role it could reach. If it could assign roles, assume it did. Check for new roles you do not recognise.
3. Kick unknown bots. Any bot with Administrator that you cannot account for goes now; you can re-add it later.
4. Change your own password and rotate your 2FA if there is any chance your account was the entry point.
5. Rotate bot tokens for any application whose token may have leaked.

Step 2: Preserve the audit log

Open Server Settings → Audit Log and screenshot it before you do anything else destructive-adjacent. It records which account performed each action and when. Entries do not persist indefinitely, and this is your only evidence for a Discord Trust & Safety report, for an ownership dispute, or simply for understanding what happened.

Step 3: Restore the structure

With a snapshot, this is the easy part. Pick a restore point from before the incident and rebuild channels, categories, roles, permission overwrites, and message history in one operation.

Choosing the restore point matters. The most recent snapshot is not always the right one — if the attacker had access for days before acting, an earlier capture may be the last genuinely clean state. Check the audit log timeline against your snapshot dates before you commit.

Step 4: Recover the members

This is the step with no manual substitute. You cannot DM people who left, you cannot see who was banned once bans are cleared, and posting an invite in a server nobody is in reaches nobody.

Member recovery re-adds everyone who completed OAuth authorization before the incident. RestoreCord does not cap how many members that is on any plan, and paid plans carry no cooldown between pulls. What it cannot do is reach anyone who never authorized — which is why this is a preparation feature wearing an emergency costume.

Recovery without a backup

If you had nothing in place, the honest picture is mixed. Here is what is still possible and what is not.

Structure: rebuildable, tediously

• Members who were online often have channel names in their message history — ask in a temporary server.
• Pinned messages and shared links in other communities can reconstruct rules and announcement text.
• Xenon-style templates give you a plausible structure quickly, even if it is not exactly yours.
• Expect an afternoon. Structure is the recoverable half.

Members: not recoverable retroactively

No service can add members who never authorized. Anyone claiming to extract a member list from Discord after the fact is describing something the API does not permit. What you can do:

• Post the new invite anywhere your community also gathers — other servers, social accounts, a website, a mailing list.
• Ask the members you do reach to pass it on; word of mouth is the only distribution you have left.
• Expect meaningful attrition. Most people who lose a server simply drift, and there is no message that fully prevents that.
• Set up verification in the new server on day one so this is the last time it happens.

Step 5: Make it not happen again

Read the security checklist for the full hardening pass, and the disaster-recovery guide for the operational detail.

The uncomfortable summary

Recovery from a nuke is almost entirely determined by decisions made before it happened. With a snapshot and prior authorizations, this is a bad afternoon. Without them, it is the end of a community — and no tool, ours included, can change that retroactively.

If your server is currently intact, that is the whole argument for spending ten minutes on this today. Set up snapshots and verification free while it is still an ordinary Tuesday.