Mastodon als Mailrelay: nicht Opfer, sondern Waffe

Acht Tage lang haben Cyberkriminelle über meine Instanz Bestätigungsmails an fremde Postfächer verschickt. Wie ich das gestoppt habe und was wir daraus lernen sollten.

Vom 10. bis 17. September 2026 hat mein Mastodon-Server troet.fediverse.at 496 Bestätigungs­mails an fremde Adressen verschickt. Dafür wurden auf meinem Server 340 Konten angelegt, jedes von einer eigenen IP-Adresse. Die beim Anlegen automatisch vom Server versendeten Bestätigungs­mails waren das eigentliche Ziel. Ein Dienst namens SendFlood verkauft solche »Mailbombs« und lässt sich pro Mail bezahlen, die nachweislich im Posteingang des vom Kunden ausgewählten Opfers landet. In diesem »Geschäfts«-prozess sind wir im Fediverse nicht das Opfer – wir sind die Waffe des Angreifers.

Ich schreibe das auf, weil ich selbst eine Weile gebraucht habe, um vom Symptom (»Mailflut«) zum Verständnis der Hintergründe zu kommen – und weil ich dabei einiges entdeckt habe, das jede Fediverse-Instanz betrifft, nicht nur meine.

Was in den Logs steht

Meine erste Vermutung war die naheliegende: Bots füllen das Anmelde­formular aus. Das war falsch. Die Auswertung der nginx-Logs vom 9. bis 17. September zeigt ein anderes Bild:

Sechs Anfragen auf dem Formular, 565 auf der API. Der Weg führt über POST /api/v1/apps – dieser Endpunkt ist in Mastodon für jeden offen, ohne Anmeldung, damit Drittanbieter-Apps sich registrieren können. Man registriert dort eine App, holt sich mit deren Zugangsdaten ein Client-Credentials-Token und schickt damit POST /api/v1/accounts. Fertig ist das Konto, und die Bestätigungs­mail ist unterwegs.

337 der 340 Konten folgten dem Muster bp plus 16 Hexa­dezimal­zeichen. Das ist auch der Name, unter dem die Welle im Fediverse kursiert: bp-Spam.

Für meine Planung hatte das eine unmittelbare Folge: Die Maßnahme, die ich ursprünglich vorgesehen hatte – eine Rechenaufgabe vor dem Anmelde­formular – hätte diesen Angriff nicht berührt.

Die Bestätigungs­mails sind das Ziel

Den entscheidenden Hinweis hat nicht mein Log geliefert, sondern ein anderer Admin. @zoul@boskovice.social hat am 17. September eine Registrierung mit der Begründung »Registration-mail deliverability check for the sendflood.com compatibility matrix; recipient is the operator-approved own mailbox« bekommen und den Wortlaut im Fediverse gepostet. Der zweite Halbsatz sagt, wie die Kompatibilitäts­matrix entsteht: Der Dienst testet den Mailversand einer Instanz zuerst an ein eigenes Postfach, bevor er sie ins Angebot nimmt.

⊕ Das Angebot – »Trigger verification email at scale«: der Zähler oben nennt die Zahl der Sites, bei denen der Dienst den Mailversand auslösen kann. Verlinkt wird die Seite hier bewusst nicht; das Bildschirmfoto dient als Beleg für das Zitat.

SendFlood beschreibt sich selbst so:

SendFlood sends protocol-level registration/resend requests to supported sites and verifies delivery by INBOX evidence. You pay only for successful triggers.

⊕ Der Resend-Pfad ist deshalb interessant, weil sich pro angelegtem Konto die Mail beliebig oft neu auslösen lässt. Meine 340 Konten plus 156 Resends ergeben die rund 496 Mails – von einer Instanz. Abgerechnet wird pro erfolgreichem Treffer, bezahlt in USDT, und als Beleg zählt nicht die verschickte, sondern die zugestellte Mail. Bemerkenswert ist der Zähler oben im Bild. Die Startseite nannte am 17./18. September 4.918 unterstützte Sites, bei meinem Abruf am 18. September 6.316 – und auf dem Bildschirmfoto, wenige Minuten später entstanden, 6.318. Das »updating continuously« ist keine Werbefloskel. Wer den Betrieb dieses Dienstes beobachten will, hat in dieser Zahl einen Indikator.

Der Umweg über fremde Anmelde­formulare ist dabei nicht Umständ­lichkeit, sondern der Kern des Geschäfts­modells:

• Die Mails kommen von echten, reputablen Absendern mit gültigem SPF, DKIM und DMARC. Sie landen im Posteingang, nicht im Spam-Ordner. Eine Flut im Spam-Ordner wäre für den Zweck wertlos.
• Sie sind nicht filterbar, ohne echte Bestätigungs­mails mitzusperren. Jede einzelne ist für sich genommen eine legitime Mail eines anderen Dienstes.
• Der Angreifer braucht keine eigene Mail-Infrastruktur, keine IP-Reputation, kein Budget. Das stellen wir zur Verfügung.
• Die Zurechnung zeigt auf tausende unbeteiligte Dritte. Wer nachforscht, landet bei mir, nicht bei ihm.

Wozu Mailbombing?

Eine Mailflut ist selten Selbstzweck. Sie ist meistens Nebengeräusch, das etwas anderes übertönen soll. Vier Zwecke sind dokumentiert:

Betrugsalarme verstecken. Nach einer Kontoübernahme oder einem Karten­missbrauch flutet der Täter das Postfach des Opfers, damit die Mail der Bank oder die Bestätigung eines Einkaufs in tausenden Bestätigungs­mails untergeht. Ein paar Stunden Verzögerung reichen, um das Geld weiterzuleiten. Der Sicherheits­anbieter BlackCloak hat für diese Spielart 2022 den Begriff Registration Bomb geprägt; in dem von ihm beschriebenen Fall verschwand eine Kauf­bestätigung von Walmart.com unter mehr als 500 Registrierungs­mails.

Vorstufe zu Ransomware. Erst wird das Postfach eines Mitarbeiters geflutet, dann ruft jemand an, gibt sich als IT-Support aus, der »das Spam-Problem beheben« will, und lässt sich Fernzugriff geben. Microsoft hat diese Vorgehensweise 2024 bei der Gruppe beschrieben, die es Storm-1811 nennt.

Ein­schüchterung. Journalisten, Aktivisten, Ex-Partner. Brian Krebs hat es 2016 selbst abbekommen: eine Mail alle zwei bis drei Sekunden, das Gmail-Konto ein Wochenende lang unbrauchbar.

Lahmlegen von Rollen­postfächern. abuse@, support@, eine Beschwerde­stelle, eine Meldeadresse. Für eine kleine Organisation ist damit die Kommunikation erledigt.

Was davon auf meinen Fall zutrifft, weiß ich natürlich nicht – ich sehe nur die Adressen, nicht was sonst mit ihnen passiert. Auffällig ist aber die Verteilung: 115 der Empfänger hatten eine Adresse bei docomo.ne.jp, dazu kamen ezweb.ne.jp und weitere japanische Mobilfunk­domains. Das sind japanische Mobilfunk-Mailadressen, an die Rufnummer gebunden und dort traditionell die Adresse für Bank­benachrich­tigungen, Carrier-Billing und Zweitfaktor. Wenn jemand ausgerechnet solche Postfächer flutet, passt das zum ersten Motiv besser als zu den anderen. Mehr als eine Vermutung ist das von meiner Seite aus nicht.

Warum Filter nicht funktionieren

Im Fediverse kursieren seit Wochen Gegenmaßnahmen: Sperre den App-Namen, sperre das Username-Präfix, sperre die Mail-Domain, sperre den User-Agent. Meine eigene oauth_applications-Tabelle dokumentiert, was daraus wird. Seit dem 9. September sind dort 597 Applications angelegt worden, alle ohne Besitzer – also alle über den offenen Endpunkt:

Stufe 3 ist der Punkt, auf den es ankommt: Das sind die Namen, unter denen sich echte Clients registrieren. In meiner Tabelle steht ein legitimes Web aus dem Jahr 2022 daneben. Eine Namenssperre ist damit nicht bloß umgangen – sie lässt sich nicht mehr formulieren, ohne echte Clients mitzusperren.

Dasselbe gilt für alles andere Variable. Der User-Agent war bis zum 16. September Python/3.10 aiohttp, danach ein gefälschter Chrome. Beim Username-Präfix tauchten neben bp auch sa und ap auf. Jede Instanz, die abfällt, kostet den Betreiber Umsatz – also passt er an. Das ist der strukturelle Grund, warum jeder Zeichenketten-Filter binnen Tagen tot ist.

Nebenbei: Die letzte dieser Applications entstand am 17. September um 21:10, also nachdem ich die Registrierung geschlossen hatte. Es wird weiter probiert.

Fehler im Mastodon-Code?

Die Frage, die mich als Admin am meisten interessiert hat: Warum greift kein einziges Bordmittel? Die Antwort steht im Quellcode von Mastodon 4.7.2.

Api::V1::AccountsController#create ruft AppSignUpService auf. Der prüft allowed_registration? – also Single-User-Modus, registrations_mode, IP-Sperren und Einladungscode. Kein Captcha-Hook, kein Honeypot. Das Webformular hat wenigstens Honeypot-Felder und eine Mindestzeit fürs Ausfüllen; der RegistrationFormTimeValidator läuft zwar auch beim API-Weg mit, ist aber ohne Formularzeit wirkungslos.

Drei Punkte, die in der bisherigen Diskussion gefehlt haben:

1. hCaptcha sitzt an der falschen Stelle. Mastodon hängt es in den Auth::ConfirmationsController, also nach dem Mailversand. Es schützt davor, dass ein Bot ein nutzbares Konto bekommt – nicht davor, dass er eine Mail auslöst. Für einen Dienst, der pro Mail bezahlt wird, ist das der Unterschied zwischen wirkungslos und wirksam. 2. Genehmigungs­pflicht hilft nicht. Der Datensatz wird angelegt, Devise verschickt sofort, und die Moderation wird erst nach der Bestätigung durch den Empfänger informiert (after_confirmation_tasks). Die Mail ist längst draußen, bevor jemand draufschaut. 3. Es gibt keine globale Obergrenze. Sämtliche Rack::Attack-Drosseln sind pro IP, pro Konto oder pro Adresse angelegt. Der Angreifer hatte pro Konto eine eigene IP. Damit lief jede einzelne Drossel ins Leere.

Dazu kommt ein Pfad, den ich für schlimmer halte als den genutzten: POST /api/v1/emails/confirmations macht current_user.update!(email: params[:email]) und verschickt dann neu – an eine frei wählbare Adresse. Innerhalb der bestehenden Drossel von fünf Anfragen pro 30 Minuten kann ein einziges per API angelegtes, unbestätigtes Konto damit 240 Mails pro Tag an beliebige Empfänger auslösen. Und Konten sind gratis. Dass mein Angreifer das nicht genutzt hat, war Glück. Die 240 sind die Untergrenze. Nach dem Quellcode von Devise geht beim Adresswechsel bereits eine Bestätigungs­mail hinaus, und das anschließende erneute Senden löst eine zweite aus. Ausprobiert habe ich das nicht.

Ein weiterer Punkt für alle, die jetzt schnell die Registrierung schließen: allowed_registration? lässt die Anmeldung auch bei registrations_mode = none durch, sobald ein gültiger Einladungscode mitkommt – und POST /api/v1/accounts nimmt invite_code entgegen. Die geschlossene Registrierung ist nur so dicht wie die vorhandenen Einladungen. Bei mir lagen zwei unbefristete Codes aus dem Jahr 2023 herum, beide nie benutzt.

Ein gelöstes Problem, nur nicht in Mastodon

Wie eine Lösung aussehen kann, ließ sich bei mir selbst nachsehen. Neben der Mastodon-Instanz betreibe ich tube.fediverse.at, eine PeerTube-Instanz. Die hat dieselbe Welle abbekommen, am 9. und 10. September: 16 Registrierungs­anträge, Nutzernamen nach dem Muster bp plus 10 Hexa­dezimal­zeichen, dieselben japanischen Mobilfunk­adressen – und bei allen 16 derselbe Begründungs­text, »Automated protocol deliverability probe«. Das ist dieselbe Wortwahl, die auf der Mastodon-Seite als App-Name BoomProtocolProbe auftaucht.

Dort blieb es bei rund 20 Mails statt 496. Auch auf tube ist die Mail­bestätigung eingeschaltet, pro Antrag ging also eine Mail hinaus. Dass es so wenige blieben, lag nicht an der Software: Der Angreifer hat auf tube nur drei IP-Adressen benutzt, weshalb PeerTubes eingebaute Grenze von zwei Anmeldungen pro fünf Minuten und IP tatsächlich gegriffen hat – vier der 24 Aufrufe von POST /api/v1/users/register endeten in einem 429. Dieselbe Bauart – Begrenzung pro IP – hat auf der Mastodon-Seite nichts gebracht, weil dort jede Anmeldung von einer eigenen Adresse kam.

Der Unterschied, auf den es ankommt, ist ein anderer. Bei PeerTube ist die Mail­bestätigung eine Option, keine feste Stufe. Mit signup.requires_email_verification: false und signup.requires_approval: true löst ein Registrierungs­antrag überhaupt keine Mail an den Antragsteller aus – beides übrigens die Werte, die PeerTube selbst in seiner Beispiel­konfiguration ausliefert. So steht es im Registrierungs-Controller von PeerTube; auf tube habe ich das noch nicht umgestellt. Der Antrag landet in der Moderations­liste; erst wenn der Admin ihn annimmt, geht eine einzige Mail hinaus – an eine Adresse, die er sich vorher angesehen hat. Damit ist die Instanz als Mailrelay wertlos, unabhängig davon, wie viele IP-Adressen jemand mietet und welche Zeichenketten er in den Antrag schreibt.

In Mastodon ist die Bestätigung dagegen Devise :confirmable und fest verdrahtet. Die einzige Stellschraube ist registrations_mode, und die kennt nur offen, mit Freigabe oder geschlossen. Im Freigabe-Modus verhindert sie die Mail nicht.

Neu ist das Muster ohnehin nicht. Die Newsletter-Branche hat »Subscription Bombing« vor rund zehn Jahren abbekommen. Im August 2016 traf eine Welle mehr als 100 Regierungs­adressen verschiedener Länder, die binnen kurzer Zeit in große Mengen von Verteilern eingetragen wurden; ein einzelner Versender fand bei sich weniger als zehn Adressen, die in knapp 10.000 seiner Listen standen.

Spamhaus führte den Erfolg des Angriffs damals ausdrücklich darauf zurück, wie viele Newsletter den Grundschritt ausließen, eine Anmeldung bestätigen zu lassen. Die Rechnung dafür bekam nicht der Angreifer, sondern die Versender: Spamhaus wies die Provider an, Mails einiger der größten E-Mail-Dienstleister zu blocken, und deren Kunden brachten ihre Werbemails nicht mehr durch. Das ist derselbe Mechanismus, der im Fediverse gerade an der Mail-Reputation der Instanzen nagt.

Die Konsequenz, die Spamhaus im September 2016 zog, ist dieselbe, die hier fehlt: Ein Captcha am Eintragungs­formular, also vor dem Mailversand, sei »the single best thing«, um ein Formular abzusichern. Double-Opt-in allein reiche nicht, weil schon die Menge der Bestätigungs­mails das Problem sei. Große Plattformen halten es meines Wissens ebenso: Die Mensch-oder-Maschine-Prüfung sitzt beim Absenden des Formulars.

Zwei Unterschiede machen das Fediverse trotzdem zum lohnenderen Ziel. Erstens die offene, unauthen­tifizierte Konten-API – die bieten kommerzielle Plattformen meines Wissens nicht an. Sie ist dokumentiert, stabil und über tausende Instanzen hinweg identisch. Das ist die Voraussetzung dafür, dass jemand daraus ein Produkt mit Kompatibilitäts­matrix bauen kann; öffentliche Instanz­verzeichnisse liefern die Zielliste gleich mit. Zweitens fehlt die zentrale Abwehr: Bei einem großen Anbieter sieht ein Team das Muster und behebt es global. Hier arbeiten tausende Admins einzeln gegen denselben Gegner.

Was ich gemacht habe

Mein Ziel war eng gefasst: Die Registrierung soll wieder offen sein, mit Freigabe durch mich wie vorher. Der Missbrauch als Mailversender soll nicht mehr möglich sein. Umgesetzt habe ich das am 18. September.

Die API-Registrierung ist im nginx abgedreht. POST /api/v1/accounts und POST /api/v1/emails/confirmations beantwortet der Webserver mit einem 403 und einem Hinweistext in Alltagssprache. Das passiert vor Rails, es wird also nichts angelegt und nichts verschickt. Wichtig dabei: Die Sperre trifft nur den Pfad selbst, damit /api/v1/accounts/:id/follow, verify_credentials und der ganze Rest unberührt bleiben – und jede Location doppelt, mit und ohne abschließenden Schrägstrich. Rails bildet beide Schreibweisen auf dieselbe Route ab, nginx tut das nicht. Ohne die zweite Variante wäre die Sperre mit einem Schrägstrich zu umgehen.

POST /api/v1/apps habe ich ausdrücklich nicht gesperrt. Das würde den Login sämtlicher Drittanbieter-Apps brechen. Ohne den Weg über /api/v1/accounts ist die App-Registrierung dort wertlos.

⊕ 403 in der App – Registrierungsversuch aus Mastodon for iOS. Die App zeigt den Text der 403-Antwort tatsächlich an – damit war zu rechnen, deshalb ist der Hinweis in Alltagssprache formuliert und nennt die Web-Adresse. Die fehlenden Umlaute stammen aus der nginx-Konfiguration.

Den gleichen Workaround, nur mit einem anderen Werkzeug hat Tealk gebaut: crowdsec https://git.rollenspiel.monster/ansible-playbooks/proxymanager/commit/2ebe0a46c81092bd379b7925385b86c79b82a034

Ein globaler Deckel auf Anmeldemails. Die verbliebenen Webwege (POST /auth und POST /auth/confirmation) laufen jetzt über eine limit_req-Zone mit einem konstanten Schlüssel – nicht pro IP, sondern für alle zusammen. Was dieser Deckel leistet, ist allerdings begrenzt: 1r/m ist die feinste Rate, die nginx kennt, das sind 60 Mails pro Stunde. Mein Vorfall waren rund 2,6 Mails pro Stunde. Diesen Angriff hätte der Deckel um kein einziges Mail reduziert. Er ist eine Schadens­obergrenze für den Fall, dass jemand aufs Webformular wechselt und dort Volumen fährt. Ein echter Stundendeckel ginge nur in Mastodon selbst.

Überwachung. Bis jetzt wären mir die 340 Konten erst an der Mailflut aufgefallen – so ist es auch gekommen. Ein Nagios-Check zählt seither viertel­stündlich, wie vielen Nutzern in der letzten Stunde eine Bestätigungs­mail geschickt wurde (confirmation_sent_at). Diese Metrik erfasst jeden Mailweg, auch das erneute Senden, und auch einen, an den ich nicht gedacht habe. Warnung bei 5, kritisch bei 20.

Aufgeräumt. Die seit dem 9. September hinterlassenen OAuth-Applications sind gelöscht, 597 Stück samt ihren Zugriffstokens, nach einem Kriterium ohne jeden Namensbezug: angelegt seit 9. September, ohne Besitzer, und kein Token, das auf einen existierenden Nutzer zeigt. Das ist Hygiene, kein Sicherheits­gewinn – ein neues Token holt sich der Angreifer mit einem einzigen Request. Aber jetzt ist die Tabelle wieder lesbar.

Registrierung wieder offen, im Modus mit Freigabe durch mich.

Nachteile meines Workarounds

Die Registrierung direkt aus einer App heraus gibt es auf meiner Instanz nicht mehr. Von rund 40 echten Konten waren neun aus Apps heraus entstanden, acht über Mastodon for Android, eines über iOS. Das sind gut 20 Prozent.

Zwei Dinge kann ich dabei nicht abstellen. GET /api/v2/instance meldet weiterhin, dass Regis­trierungen möglich sind – Apps zeigen den Knopf also an, und man landet erst beim Absenden in der Fehlermeldung. Ohne Eingriff in den Mastodon-Quellcode ist das nicht zu ändern. Und wer die Fehlermeldung nicht liest, springt ab. Dagegen hilft vielleicht ein Hinweis in der Server­beschreibung.

Relativierend sei angemerkt: Bei Genehmigungs­pflicht war der App-Weg ohnehin halbgar – die App wartet dann auf eine Freigabe, die erst nach meiner manuellen Entscheidung kommt. Und die UX bei der Konten­registrierung via Mastodon-App ist ohnedies unterirdisch.

Mein Workaround wäre aber in einer Minute rückgängig zu machen: Eine include-Zeile aus­kommentieren, nginx neu laden.

Was es für eine nachhaltige Lösung braucht

Alles, was ich gemacht habe, ist eine Notlösung auf meinem Server. Das Problem liegt eine Ebene höher, und dort ist es meinem Wissensstand nach nicht gelöst.

Drei Wege wären in Mastodon denkbar, einer würde reichen:

• eine Einstellung, mit der sich die Registrierung über die API abschalten lässt, ohne den Reverse Proxy zu bemühen,
• ein Captcha-Hook in AppSignUpService, also an derselben Stelle, an der ihn jede kommerzielle Plattform hat,
• oder, im Modus mit Genehmigungs­pflicht, die Bestätigungs­mail erst nach der Freigabe zu verschicken.

Der dritte Weg ist der beste, und zwar aus einem praktischen Grund: Er ist der einzige, der die Registrierung aus der App erhält. Das Vorbild dafür: PeerTube.

Wo der Hebel säße

In app/models/user.rb laufen alle Mails, die Devise verschickt (Bestätigung, Passwort-Reset, Adresswechsel), durch eine einzige Methode – dort anzusetzen erfasst Webformular, API-Weg und das erneute Senden auf einmal. Die Freigabe eines noch unbestätigten Kontos verschickt heute nichts; das wäre die Stelle, an der der Mailversand (Bestätigung an den Neuling) nachzuholen wäre.

Ob eine Änderung in dieser Form taugt, weiß ich nicht – dafür bin ich zu wenig Entwickler.

Potentielle Probleme dieser Lösung

• Die Flut verschiebt sich von der Mail in die Datenbank. Ohne nginx-Sperre legen die Bots weiter Konten an, nur stumm. Für Postgres ist das nichts, aber jeder Datensatz belegt einen Namen, bis ihn jemand löscht.
• Die Oberfläche sagt dann etwas Falsches. Mastodons Anmelde­formular schickt auf »Überprüfe dein E-Mail-Postfach«, und dann kommt stundenlang nichts. PeerTubes Oberfläche kennt ihren Modus und kann ihn daher kommunizieren. Es bräuchte zusätzlich einen Hinweistext.
• Ich gäbe Adressen frei, die nicht verifiziert sind. Das halte ich für verkraftbar – anmelden kann sich trotzdem niemand, bevor er die Mail bekommen und geklickt hat.

Upstream

Es gibt ein offenes Issue zu dieser Welle, #40453 »feature: Block oauth applications«. Dessen Vorschlag ist allerdings selbst wieder ein Namensfilter; der Autor schreibt »I bet most spammers would change the name«, und das ist inzwischen eingetreten. Ein Issue zur eigentlichen Ursache – die Mail geht hinaus, bevor irgendeine Prüfung laufen kann – habe ich dort nicht gefunden, und eingebracht habe ich selbst bisher auch keines. Drei offene Issues kreisen darum herum:

• #33696 beschreibt den Weg meines Angreifers Schritt für Schritt: OAuth-App anlegen, Client-Credentials-Token holen, POST /api/v1/accounts. Dort geht es darum, dass das sogar funktioniert, wenn die Registrierung eigentlich auf einen externen Anmeldedienst umgeleitet ist. Offen seit Jänner 2025.
• #36435 schlägt vor, dass Apps für die Registrierung eine Webansicht öffnen, statt selbst POST /api/v1/accounts zu schicken – so, wie das Anmelden über OAuth schon heute läuft. Aufgeschrieben wurde das aus ganz anderen Gründen, nämlich weil die App sonst das Passwort des Nutzers in die Hand bekommt, Passkeys nicht funktionieren und jede App den Altersnachweis selbst einsammeln müsste. Für mich hätte es einen angenehmen Nebeneffekt: Wäre das umgesetzt, würde meine Sperre die Registrierung aus der App nicht mehr kosten. Offen seit Oktober 2025.
• #39455 fragt nach einer Mensch-oder-Maschine-Prüfung beim Anmelden. Der Vorschlag selbst ist eigenwillig – ein Video der eigenen Hand –, das Bedürfnis dahinter trifft die Sache.

Dass die Bausteine einzeln herumliegen und seit Monaten offen sind, ist kein gutes Zeichen.

Bis es eine Lösung gibt, gilt für Admins: Registrierung schließen wirkt, und zwar sofort. Aber sieh nach, ob noch offene Einladungs­codes herumliegen – die hebeln das aus. Und wer eine PeerTube-Instanz betreibt, hat es leichter: requires_email_verification: false zusammen mit requires_approval: true nimmt dem Angriff die Grundlage.

Fazit

Die Verlockung ist groß, das Ganze nur als Ärgernis für Fediverse-Admins zu sehen: volle Mailbox, Registrierung zu, lästig. Das eigentliche Problem ist aber viel größer. »Meine« 496 Mails sind in Postfächern gelandet, um möglicherweise eine Betrugswarnung zu verschleiern. Ein Fediverse-Server, den man offen lässt, ist in dieser Konstellation nicht das Opfer, das Mitleid verdient – er ist das Tatwerkzeug von Kriminellen.

Quellen

zoul. The strange #bpspam saga continues Beitrag auf boskovice.social, 17. September 2026. 🌐

Ingo Lantschner. Diskussion mit anderen Instanz-Admins Thread auf troet.fediverse.at, September 2026. 🌐

SendFlood. Trigger verification email at scale. Eigenwerbung des Dienstes, Startseite, Bildschirmfoto vom 18. September 2026. Auf eine Verlinkung wird bewusst verzichtet.

mastodon/mastodon. feature: Block oauth applications Issue #40453, GitHub. 🌐

BlackCloak. New Registration Bomb Email Attack Distracts Victims of Financial Fraud Anbieterbericht, syndiziert auf Security Boulevard, 1. März 2022. 🌐

Brian Krebs. Massive Email Bombs Target .Gov Addresses KrebsOnSecurity, August 2016. 🌐

PeerTube. config/default.yaml Voreinstellungen für signup.requires_approval und signup.requires_email_verification, Projekt-Repository. 🌐

PeerTube. server/core/controllers/api/users/registrations.ts Registrierungs-Controller: Mail an den Antragsteller nur bei requires_email_verification, eine Mail bei Annahme (v8.3.0). 🌐

mastodon/mastodon. Quellcode v4.7.2 app/services/app_sign_up_service.rb, app/helpers/registration_helper.rb, app/controllers/api/v1/emails/confirmations_controller.rb, app/controllers/auth/confirmations_controller.rb, app/models/user.rb, config/initializers/rack_attack.rb. 🌐

Spamhaus. Subscription Bombing: COI, CAPTCHA, and the Next Generation of Mail Bombs Blog des Spamhaus Project, 16. September 2016. 🌐

Microsoft. Threat actors misusing Quick Assist in social engineering attacks leading to ransomware Microsoft Security Blog, 15. Mai 2024 (Storm-1811). 🌐

Weitere Artikel aus der
Kategorie Medien

Der Gell-Mann-Amnesie-Effekt
Wir erkennen die Fehler in Artikeln über unser eigenes Fachgebiet – und halten den Rest der Zeitung trotzdem für verlässlich. Warum tun wir das?

Das Quellen-Dilemma – wenn Belege einfach verschwinden
Um eine Debatte zu versachlichen, müssen die Quellen offengelegt werden. Online kollidiert das möglicherweise mit dem Urheberrecht.

Der ORF, die Wasserfarben und deine Standortdaten
Im Cookie-Dialog erklärt der Gebührensender das Datensammeln mit niedlichen Beispielen. Die Wirklichkeit dahinter ist eine andere.

Überwacht durch Werbung – die Spionage ohne Hacking
Ronald Deibert warnt vor Überwachung aus dem Werbe-Ökosystem. Pikant: Auch das Medium, das ihn abdruckt, speist die Überwachungsmaschinerie.