Quick heads-up for other Mastodon admins: this registration spam wave isn't over yet.

On lsbt.me, we first saw a flood of API registrations using Python/aiohttp. The telltale signs were usernames following the pattern bp plus 16 hex characters, and the sign-up reason was always "Automated protocol deliverability probe". A narrow block on that user agent stopped the first wave.

Today, however, five new registrations came in with the same usernames and the same sign-up reason. This time the bot simply identified itself as Chrome 126. That's exactly why a user agent is only useful as a short-term filter. It's a header the client can set to anything.

The requests go to POST /api/v1/accounts. This endpoint lets client apps create a new local account directly in the app. No app needs it for OAuth connections to existing accounts. #FediSuite doesn't use it either. It registers itself via /api/v1/apps, obtains consent via /oauth/authorize, and then works with a user token. Regular sign-up through the Mastodon website is also handled separately via POST /auth.

So I've completely disabled API account creation on lsbt.me. Web sign-up, OAuth, and existing clients keep working as before. Anyone who wants a new account just signs up once on the web as usual and can then use any client.

If you'd also rather not offer this optional native sign-up path, you can add the following to your Nginx server block, before the general location / block. The example assumes the @proxy location that many Mastodon Nginx configs already include:

location = /api/v1/accounts {
 limit_except GET {
 deny all;
 }

 try_files $uri @proxy;
}

This returns a 403 only for POST /api/v1/accounts. The read-only GET endpoint remains reachable. As always, run nginx -t afterwards and only reload once the test passes.

#Mastodon #Fediverse #MastoAdmin #FediAdmin #FediMod #FediBlock #Moderation #Registration #Spam #Nginx #SelfHosting #SysAdmin #ActivityPub