Permissions are the gate
The dashboard trusts Discord's own permission checks. There is no second password to leak.
Every action is logged
Antinuke, moderation and dashboard changes produce a record you can review.
Report it privately
A vulnerability reported in the support server is fixed before it is discussed publicly.
Harden in minutes
2FA on the owner account, a sensible role order and a short whitelist remove most of the risk.
How the bot is built to fail safely#
- Every event handler is wrapped, so one bad guild cannot take the process down.
- Antinuke reverts the destructive action first and punishes second, and never reverts an action by the server owner.
- Whitelisted users and extra owners are explicit lists — there is no implicit trust by role name.
- The dashboard re-checks permissions on every request instead of trusting the page that drew the button.
- Sessions are signed and expire in 12 hours; signing out deletes the cookie.
Permissions and why each is needed#
| Permission | Used for |
|---|---|
| Manage Roles | Reaction roles, auto roles, jail and mute roles, antinuke reverts |
| Manage Channels | Ticket channels, jail channel, VoiceMaster rooms, antinuke reverts |
| Kick / Ban members | Moderation commands, antinuke punishment, quarantine |
| Moderate Members | Timeouts, mutes and raid containment |
| Manage Messages | Purge, automod deletion, starboard and pinning |
| View Audit Log | Knowing who performed a destructive action, so antinuke can attribute it |
| Manage Webhooks | Reverting a webhook created by a compromised admin |
| Read / Send Messages | Answering commands, logs and notices |
| Connect / Speak | Music playback and VoiceMaster rooms |
The bot never needs Administrator. If a guide or a command asks you to grant it, that is a bug — report it.
What leaves your server#
Only what a feature needs, and only to the bot process: the ids you configured, the command being run and the target of that command. Nothing is forwarded to an advertising or analytics service because there is none in the stack.
- Join and leave notices are posted in the bot's own support server so the operators can greet a new server.
- Aggregate counters — total servers, total members, command totals — are public on the site.
- A server's invite appears on the public wall only when the operator publishes that server.
Harden your server in five minutes#
- Turn on 2FA for the Discord account that owns the server — it is the single biggest protection against a stolen account.
- Put the bot's role high enough to act on staff, but below the roles it should never touch.
- Run antinuke setup, then shorten the whitelist to people who genuinely need to act without tripping it.
- Add extra owners you trust to recover the server, and remove them when they leave.
- Keep one immutable backup of the server structure so a nuke is a restore instead of a rebuild.
- Give moderators the least role that lets them do their job; Manage Server is not required for moderation commands.
Reporting a vulnerability#
If you find a way to read another server's data, bypass a permission check, escalate a role or take the bot offline, report it in the support server and ask for a maintainer. Do not test it against servers you do not own, do not download data that is not yours, and do not publish it before it is fixed.
- Good-faith research is welcome and will not be met with a ban.
- You get an acknowledgement, a fix timeline and credit if you want it.
- Anything that touches real user data is fixed before the report is discussed publicly.
Contact#
Questions about this page, or a request about your data, are answered in the support server — it is the one place every operator reads. A direct message to the bot is not a support channel and may go unanswered.
This page describes how bleh is run today. Features that are not listed here are not covered by it, and a new feature that changes any of the above is called out in the changelog.