I like the way this functions in practice enough that I've gone ahead and PR'd it upstream more robustly. I'd say using this here is safe under the same considerations mentioned in that PR (i.e. don't use this to redact accidental token leaks in things like eval, as that should be done in other ways to prevent user input guess & check)

We can use this solution safely until something like that is (if) merged upstream if we want

bump, I've added these changes in manually to my install but the majority of servers right now are still vulnerable. In a server of 10k people this really isn't something we can risk, and I see a lot of other server owners feeling the same way.

@Twentysix26 and other maintainers, please look into this.

@qwazwsx This PR is being considered, however, I'd argue that in a 10k people server the bot shouldn't have permissions to mass mention to begin with :)

I strongly disagree that a 10k person bot shouldn't be able to have mass mention perms. There may be announcements which actually should require it in any community. While the opportunity for them is few and far between in most well-run communities, whether a bot having those permissions makes sense is ultimately up to those communities to decide.

I'm aware of legitimate uses for mass mentions on big servers, however I was attempting to point out that there are plenty of ways to prevent unwanted mass mentions, even without touching any code.
For announcements, for example, is possible to give the bot mass mention permissions in one single channel (announcement channels are common), avoiding the risk of users triggering a mass mention in others.
@qwazwsx 's message sounded urgent, so I provided a ready solution.

I've done another pass over the various places we take in user input in any form, specifically for anything which could mass mention unintentionally. Searching for places we potentially take in links is a lot more intensive since even in embedded content, invite links need sanitization or discord will render an invite. The good news is, mentions inside of embeds don't actually ping users.

I consider the mass mentions the more important nuisance to kill (both would be ideal.) I feel this is ready enough for public use at this point as a solution, but I'm not sure I've covered everywhere this needs handling when it comes to filtering (specifically invite links from) embeds.

This can be 100% covered by automatically re-constructing all embed objects, but I felt this was too much a performance drain in practice on even a 200 user server that tried to help me break it. What it will come down to is applying selective filtering to content before placing it in an embed if from an untrusted source.

A note on behavior in embeds. It seems at some point after the August 4th raiding incident, discord Changed the behavior of invites to not be rendered in embeds. They are still rendered when in code blocks, and in a modlog entry we probably shouldn't be advertising servers just because someone having a mod action done to them was named as an invite. This leaves verifying all of the other locations for this behavior at a much lower priority, but still able to be changed as needed at a later date.