Am 27. April 2026 haben Kunden des US-Brokers Robinhood eine Sicherheitswarnung in ihrer Inbox gefunden. Absender: noreply@robinhood.com. SPF, DKIM und DMARC alle bestanden. Bei Gmail-Empfängern erschien sogar das BIMI-Logo. Inhalt der Mail: "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. Ich habe mir 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 john.doe@gmail.com und johndoe@gmail.com als identische Adressen – beide landen im selben Postfach. Robinhood sieht das anders: Aus Robinhoods Datenbank-Sicht sind das zwei unterschiedliche Email-Adressen, also können beide separat ein Konto registrieren. Die Angreifer haben aus Datenleaks bekannte Robinhood-Kunden-Mails wie victim@gmail.com genommen und mit modifizierter Punkt-Notation neue Konten registriert. Robinhoods System schickt brav die Bestätigungs-Mail an vi.ctim@gmail.com – die landet aber in der Inbox von victim@gmail.com, 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.15
Robinhood 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 etwas:
</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 Email-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&lt;>wird zu&gt;&wird zu&amp;"wird zu&quot;'wird zu&#39;
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 Email-Skript ist es per Default aus. Das ist 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 Template-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 ich für mich festgehalten habe:
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" Email-Adressen reduzieren können (Punkte vor dem @ ignorieren bei Gmail-Adressen), dann hätten die Angreifer ihre eigenen Mails bekommen, nicht die der Opfer. Das ist eine einzelne Zeile in der Validierung. In der Email-Branche ist Email-Normalisierung ein bekanntes Thema, aber selten in Anti-Fraud-Kontexten.
Was mich 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 Email-Adresse. Beides ein paar 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, Email-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.
Quellen: BleepingComputer, Help Net Security, The National CIO Review, Protos, jeweils vom 27.–28.04.2026. Robinhood-Statement auf X vom 27.04.2026.