Robinhood hat seine eigenen Kunden phishen lassen — mit perfekter E-Mail-Authentifizierung
Am 27. April 2026 fanden Kunden des US-Brokers Robinhood eine Sicherheitswarnung in ihrer Inbox. Absender: [email protected]. SPF, DKIM und DMARC alle bestanden. Bei Gmail-Empfängern erschien sogar das BIMI-Logo. Betreff: “Unrecognized Device Linked to Your Account — Review Activity Now”. Der Button führte auf robinhood[.]casevaultreview[.]com, eine Phishing-Seite zur Anmeldedaten-Abgabe.
Die Mail kam nicht aus einem Spoofing-Versuch. Sie kam tatsächlich von Robinhoods eigener E-Mail-Infrastruktur. Robinhood selbst hat sie generiert, signiert und verschickt. Wir haben uns den Vorfall genauer angesehen, weil die Erklärung “irgendwer hat halt Phishing gemacht” hier nicht trägt — und weil die eigentliche Lehre nichts mit E-Mail-Authentifizierung zu tun hat, sondern mit einem Defekt eine Schicht darüber.
Der Angriff in drei Stufen
Stufe 1: Gmail-Dot-Alias-Trick zur Empfänger-Auswahl. Gmail behandelt [email protected] und [email protected] als identische Adressen — beide landen im selben Postfach. Robinhood sieht das anders: Aus Robinhoods Datenbank-Sicht sind das zwei unterschiedliche E-Mail-Adressen, also können beide separat ein Konto registrieren. Die Angreifer haben aus Datenleaks bekannte Robinhood-Kunden-Adressen wie [email protected] genommen und mit modifizierter Punkt-Notation neue Konten registriert. Robinhoods System schickt brav die Bestätigungs-Mail an [email protected] — die landet aber in der Inbox von [email protected], also beim echten Robinhood-Kunden.
Stufe 2: HTML-Injection über das Device-Metadaten-Feld. Robinhoods Login-Bestätigungs-Mail enthält Felder wie Zeitpunkt, IP-Adresse, ungefähren Standort und — das ist das Einfallstor — ein “Device:“-Feld. Dieses Feld wird automatisch befüllt. Robinhood liest dafür den User-Agent-Header des HTTP-Requests aus, mit dem das Konto registriert wurde, oder ein device_name-Feld aus dem API-Body bei mobilen Apps.
Ein normaler User-Agent sieht etwa so aus:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15
(KHTML, like Gecko) Version/17.0 Safari/605.1.15Robinhood parst den, vereinfacht ihn und schreibt z. B. “MacBook (Safari 17)” ins Device-Feld der Mail. Der entscheidende Punkt: Diesen Header kann der Client beliebig setzen. Mit curl, Burp, Postman oder einem selbstgebauten Script ist das eine Zeile.
Die Angreifer haben den User-Agent durch HTML ersetzt — ungefähr so:
</td></tr><tr><td><h2>⚠ Unrecognized Device Linked to Your Account</h2>
We detected a login from an unfamiliar location.
<a href="https://robinhood.casevaultreview.com/verify">Review Activity Now</a></td></tr>Robinhood schreibt diese Zeichenkette unverarbeitet in das HTML-Template der Bestätigungs-Mail. Beim Empfänger interpretiert der Mail-Client (Gmail, Outlook) das HTML als Markup — nicht als Text. Aus Sicht des Empfängers sieht es aus wie eine echte Sicherheitswarnung, mit Button und allem.
Stufe 3: Die Authentifizierung tut, was sie soll. Die Mail wurde tatsächlich von Robinhoods Mailservern erzeugt. SPF prüft: stimmt, kommt von autorisierter IP. DKIM signiert den fertigen Mail-Body, einschließlich des injizierten HTMLs. DMARC prüft, ob die From-Domain zur signierenden Domain passt: stimmt. Aus Sicht aller drei Standards ist die Mail einwandfrei. Sie ist auch einwandfrei — als von Robinhood signierte Mail. Der Defekt sitzt nicht im Sendepfad, sondern in dem, was vor dem Sendepfad in die Mail geschrieben wurde.
Warum das ein klassischer Application-Security-Fehler ist
HTML-Injection in E-Mail-Templates ist die gleiche Familie wie Cross-Site-Scripting (XSS) auf Webseiten — nur dass das Rendering nicht im Browser auf einer Webseite passiert, sondern im Mail-Client beim Empfänger. Der Defekt liegt in einem Schritt, den jedes Output-Sicherheits-Konzept als kritisch markiert: User-Input wird direkt ins Template interpoliert, ohne Escaping.
Die Korrektur ist einfach. Bevor ein user-controlled Wert in einen HTML-Body eingesetzt wird, müssen die fünf HTML-Sonderzeichen ersetzt werden:
<wird zu<>wird zu>&wird zu&"wird zu"'wird zu'
Aus dem Phishing-HTML wird dann reiner Text — im Empfänger-Mail-Client steht dann sichtbar </td></tr><tr><td><h2>⚠ Unrecognized..., nicht ein gerenderter Block. Das wäre ungewöhnlich genug, dass der Empfänger stutzt — aber es würde keinen Phishing-Link rendern.
Wie verschiedene Template-Frameworks das handhaben
Hier liegt der eigentliche Lerninhalt für alle, die transaktionale Mails versenden. Die Default-Einstellungen variieren erheblich:
Mustache und Handlebars. Der Standard-Operator {{value}} escaped automatisch. Wer explizit unescaped HTML einsetzen will, muss {{{value}}} (drei Klammern) schreiben. Das macht die Unsicherheit explizit — aber es bedeutet auch, dass jemand bewusst dreifache Klammern setzen muss, um den Defekt zu erzeugen.
Jinja2 (Python). Standardmäßig wird gar nicht escaped, es sei denn, autoescape=True ist gesetzt. Bei Web-Frameworks wie Flask und Django ist Autoescape standardmäßig an. Bei direkter Jinja2-Nutzung in einem E-Mail-Skript ist es per Default aus. Ein klassischer Fallstrick.
ERB (Ruby on Rails). Rails hat seit Version 3 automatisches HTML-Escaping in Views. Das gilt aber nur für Strings, nicht für solche, die explizit als html_safe markiert sind. Wer einen vom User kommenden Wert irgendwo mit .html_safe aufruft, hat die Schutz-Schicht bewusst ausgeschaltet.
Twig (PHP/Symfony). Auto-Escape ist standardmäßig an. Wer es ausschalten will, schreibt {{ value|raw }}. Wieder explizit, wieder bewusst zu deaktivieren.
Razor (.NET). Ähnlich wie ERB — @value escaped automatisch, @Html.Raw(value) umgeht das.
String-Interpolation oder Concat in der Host-Sprache. Wer Mail-Bodies mit f"<td>{value}</td>" in Python oder `<td>${value}</td>` in JavaScript zusammensetzt, hat keinen automatischen Schutz. Das ist — aus Convenience — verbreiteter, als man denken würde.
Bei Robinhood scheint der Defekt im Bereich der letzten Kategorie gelegen zu haben. BleepingComputer hat berichtet, dass Robinhood den Fehler nicht durch nachträgliches Sanitizing behoben hat, sondern indem sie das Device-Feld komplett aus der Mail entfernt haben. Das ist die brutale Lösung — schneller als den Sanitizer einzubauen, sagt aber auch: Sie haben das Feld lieber komplett gestrichen als die Template-Pipeline anzufassen. Das deutet auf strukturelle Probleme hin, nicht auf einen einzelnen Bug.
Was die Lehre aus dem Vorfall ist
Drei Punkte, die wir festhalten:
Erstens: E-Mail-Authentifizierung ist kein Schutz gegen kompromittierte Inhalte. SPF, DKIM und DMARC sagen: Die Mail kommt wirklich von der angegebenen Domain. Sie sagen nichts darüber, ob der Inhalt sinnvoll, harmlos oder vertrauenswürdig ist. Wer eine Plattform betreibt, die User-Input in transaktionale Mails einbettet, kann seine eigene Domain als Phishing-Kanal benutzen lassen — mit perfekter Auth-Bilanz.
Zweitens: Jedes user-controlled Feld in einem ausgehenden Mail-Template ist ein potenzielles Phishing-Delivery-Vehikel. Nicht nur offensichtliche Felder wie “Display Name” oder “Notiz”. Auch unauffällige Metadaten wie User-Agent, Geräte-Name, Standort, sogar Zeitzonen-Informationen, wenn sie aus dem Client-Request stammen. Bei einem Audit lohnt es sich, einmal alle Stellen aufzulisten, an denen der Mail-Body überhaupt Input von außen interpoliert.
Drittens: Der Gmail-Dot-Alias-Trick ist eine seltene, aber elegante Verstärkung. Robinhood hätte die Account-Anlage auf “kanonische” E-Mail-Adressen reduzieren können (Punkte vor dem @ bei Gmail-Adressen ignorieren), dann hätten die Angreifer ihre eigenen Mails bekommen, nicht die der Opfer. Das ist eine einzelne Zeile in der Validierung. In der E-Mail-Branche ist E-Mail-Normalisierung ein bekanntes Thema, aber selten in Anti-Fraud-Kontexten.
Was an dem Vorfall nachdenklich macht
Die Auth-Header waren alle grün. Die Domain war echt. Das Logo wurde wegen BIMI angezeigt. Standard-Phishing-Erkennungs-Heuristiken (komische Schreibweisen, falsche Domains, fehlende Signaturen) hätten hier nichts gefunden. Der Empfänger hatte kein technisches Signal, dass etwas nicht stimmt — außer der Mail-Inhalt selbst, der für aufmerksame Leser etwas seltsam wirkte. Aufmerksamkeit allein ist aber keine Sicherheitsstrategie.
Was diesen Angriff bemerkenswert macht, ist die Asymmetrie zwischen Schutz und Bypass. Robinhood hat in DKIM, SPF, DMARC und BIMI investiert — das ist die richtige Investition, und sie wirkt gegen die meisten Phishing-Vektoren. Aber der Aufwand für den Bypass war: ein User-Agent-String und ein Punkt in einer E-Mail-Adresse. Beides Stunden-Arbeit.
Wer in der Rolle eines Plattform-Betreibers ist und Bestätigungs-Mails, Login-Alerts oder ähnliche transaktionale Kommunikation schickt, kann das Risiko mit relativ überschaubarem Aufwand schließen: Output-Encoding bei jeder Template-Interpolation, E-Mail-Normalisierung bei der Account-Anlage, regelmäßiges Auditing aller Felder, die in ausgehende Mails fließen. Klingt nach Standard-Hausaufgaben. Der Robinhood-Vorfall zeigt, dass diese Hausaufgaben in der Praxis nicht überall gemacht werden.
Was DMARCPulse hier kann — und was nicht
Wir bauen einen DMARC-Monitoring-Dienst, deshalb gehört eine ehrliche Einordnung dazu. DMARCPulse erkennt keine HTML-Injection in deinen eigenen transaktionalen Mail-Templates — das ist Application-Layer-Arbeit, die in deinem Engineering-Team verbleibt. Was DMARCPulse macht: das Fundament absichern. Es prüft, ob SPF, DKIM, DMARC, MTA-STS, TLS-RPT und BIMI korrekt konfiguriert sind, und es zeigt jeden Sender, der über deine Domain mailt — auch die nicht autorisierten.
Der Robinhood-Vorfall macht den Fall für beide Schichten. Sobald das Auth-Fundament steht, ist jede Phishing-Mail, die ein Empfänger sieht, entweder gespooft (und wird abgewiesen) oder authentifiziert (und wird damit als vertrauenswürdig wahrgenommen). Den Fall “authentifiziert und vertraut, aber bösartig” muss die Application-Schicht abfangen. Auf das Fundament zu verzichten, spart nicht die Application-Arbeit — es addiert nur eine zweite Phishing-Klasse obendrauf.
Wenn du wissen willst, wie das Fundament deiner Domain heute aussieht, ist unser kostenloser Domain-Check ein 30-Sekunden-Einstieg. Von dort gibt dir DMARCPulse kontinuierliches Monitoring, Sender-Sichtbarkeit und konkrete Empfehlungen mit Copy-and-Paste-DNS-Werten.
Quellen: BleepingComputer, Help Net Security, The National CIO Review, Protos — Berichte vom 27.–28. April 2026. Robinhood-Statement auf X vom 27. April 2026.