The "Pending Invites" counter didn't seem to work correctly for this instance.

It works fine; the attacker individually cancelled each invite after sending it. It's probably easiest to just put a very low rate limit on this, since no reasonable install needs to bulk-cancel a large number of invites.

I think my plan here is basically:

• Give instance members a cancelled status instead of deleting them. When canceling an invitation, put the member in this status. When inviting a member, check for an existing canceled invite.
• There's some adjacent mess with actual invites (the one-time code part) that likely needs cleanup. These are separate objects but we want them to act more or less as one object.
• Give instances an "outstanding invite" limit. This is the number of invited + cancelled members the instance is permitted to have. It can probably be computed automatically as "20 + (2 * number of actual members)" or similar.
• Give each member a hasInvited flag or similar. This distinguishes between queued invitations and sent invitations.
• When you create an invite or a user registers, we invite random queued members up to the "outstanding invite" limit and set their hasInvited flag.
• When a user creates an instance, hard-limit them if they're a member of too many (test/free/active?) instances already.

That shouldn't impact any legitimate users (if you have 200 actual users to invite, you can still do it without any issues) but should dampen the ability to use invites for spam.

General idea is that when you invite a ton of users, we send out a small number of random invites. As those get accepted, we send out more and more. If they don't get accepted (i.e., you're just spamming) the vast majority of your spam list stays queued.

Possible additional adjustments:

• Don't include custom messages in test instance invites (attackers can create real instances instead, but at least they have to pick names for them). Seems like complexity with little real deterrent effect, though.
• CAPTCHA everything.
• Staff approvals? But: big yuck.

• I cherry-picked to stable and deployed to admin.
• I launched a test instance, invited 32 users, and saw only 20 invites actually go out.
• After accepting two invites, I saw more invites go out.
• I cancelled some invites, for good measure.

So I think this should be effectively fixed now. Possibly still on deck is throttling/limiting instance launches, but I plan to wait and see if the attackers adapt or not. This channel seems so slow, complicated, and low-value that I imagine this change may be a sufficient barrier on its own.