米国の個人向け証券取引プラットフォーム「Robinhood」で、アカウント作成フローのHTML注入脆弱性が攻撃者に悪用された。送信元は本物の noreply@robinhood.com、SPFとDKIMの検証も通過済み——にもかかわらずフィッシングメールが大量配送されたこの事件は、「メール認証さえ通っていれば安全」という思い込みを正面から崩す。

何が起きたのか

2026年4月27日の夜、Robinhoodの利用者のもとに「認識されていないデバイスからのログイン」を警告するメールが届き始めた。メール内の「Review Activity Now」ボタンをクリックすると robinhood[.]casevaultreview[.]com というフィッシングサイトへ誘導され、認証情報の窃取が試みられた。

Robinhoodは後にX（旧Twitter）上で公式声明を投稿し、「アカウント作成フローの悪用によるものであり、システムや顧客口座への侵害ではない」と認めた。問題のフィールドは既に削除され、現時点で脆弱性は修正済みだ。

攻撃の仕組み：入力サニタイズの欠如が招いたHTML注入

技術的な攻撃経路は明快だ。Robinhoodでは新規アカウント作成時、登録したメールアドレス宛に確認メールを自動送信する。このメールには登録時刻・IPアドレス・デバイス情報・おおよその位置情報が含まれていた。

問題はデバイス情報フィールド（Device: フィールド）にあった。攻撃者はHTTPリクエストのデバイス関連メタデータを改ざんし、任意のHTMLを埋め込んだ。Robinhoodのバックエンドがこの値を適切にサニタイズせずそのままメール本文にレンダリングしたため、攻撃者が仕込んだ「アカウント不審活動」の偽警告セクションが正規メールの一部として表示された。

加えて攻撃者はGmailのドット別名（Dot Aliasing）動作も利用した。Gmailでは user.name@gmail.com と username@gmail.com は同一の受信箱に届く。この仕様を使い、既知の被害者メールアドレス（2021年のRobinhood情報漏洩で流出した700万件以上のデータが利用されたとみられる）の変形バリエーションを使って偽アカウントを量産。正規の確認メールをターゲットに届けることが可能だった。

SPF/DKIMを通過した理由

ここが重要なポイントだ。SPF（Sender Policy Framework）とDKIM（DomainKeys Identified Mail）は、「そのドメインの正規サーバーから送信されたか」を検証する仕組みであり、「メール本文の内容に不正な要素が含まれていないか」は検証しない。

今回のメールは確かにRobinhoodの正規サーバーから noreply@robinhood.com として送信されたため、両チェックをクリアした。メール認証の合格が「メールの安全性」を保証しないことを、この事件は改めて示している。DMARC（Domain-based Message Authentication, Reporting & Conformance）も同様で、ドメインなりすましへの対策にはなるが、今回のような「正規フロー内への悪意ある注入」には無力だ。

実務への影響：日本のエンジニア・IT管理者が今日から見直すべきこと

この事件は遠い海外のサービスの話ではない。ユーザー入力をシステムメールに含める設計は、あらゆるWebサービスで同様のリスクを内包している。

1. メール生成時のテンプレートエスケープを必ず確認する デバイス情報・ユーザーエージェント・住所・姓名など「ユーザーが制御できる文字列」をメール本文に挿入するすべての箇所で、HTMLエスケープ（またはプレーンテキスト強制）が実装されているか確認する。HTMLメール生成ライブラリのオートエスケープ設定は「有効か」だけでなく「抜け穴がないか」まで見ること。

2. トランザクションメールをセキュリティレビューの対象に含める 「ユーザーへの通知メール」はビジネスロジックの一部として機能するが、セキュリティレビューの対象から外れやすい。コードレビューのチェックリストに「メール本文への可変値挿入」を明示的に追加する。

3. 2021年のRobinhood漏洩データが今も悪用されていることを念頭に置く 今回の攻撃者は旧来の漏洩データをターゲットリスト作成に流用したとみられる。自社サービスユーザーのメールアドレスが過去のリスト流出に含まれている可能性を前提に、フィッシング耐性（パスキー導入・MFA必須化）の強化を検討する。

4. 「正規アドレス発のメールでも疑う」教育を従業員・ユーザーに SPF/DKIM通過・正規ドメイン発という条件が「安全の証明」にならないことを、社内セキュリティ教育のアップデートに盛り込む。特に金融系・ECサービス利用者への啓発が急務だ。

筆者の見解

正直に言うと、セキュリティ案件は細かい話が多くて得意分野とは言いにくい。ただ、今回のような「根本的な入力サニタイズの欠如」が実際の攻撃に使われた事例は、技術的に非常に興味深い。

見方を変えれば、これは「高度な攻撃」ではない。攻撃手法としては古典的なHTML注入だ。それが2026年に、上場企業のトランザクションメールフローで発動した。「今動いているから大丈夫」の姿勢がいかに危険かを示す事例として、教科書に載せられるレベルだと思う。

Gmailのドット別名を使ったアカウント量産も、長年知られている仕様だ。「既知の仕様が攻撃に組み合わされる」パターンは今後も増える。新しい脆弱性を追うより、基本的な防御の穴をふさぐことの方が、多くの現場で今すぐ優先されるべきだと感じる。

Robinhoodは迅速に修正しており、対応自体は評価できる。ただ、700万件の漏洩から5年後に、その漏洩データを使った攻撃を受けているという事実は重い。一度流出した情報は永続的に攻撃リストとして機能する——この現実を、サービス運営者もユーザーも改めて認識する機会にしてほしい。

出典: この記事は Robinhood account creation flaw abused to send phishing emails の内容をもとに、筆者の見解を加えて独自に執筆したものです。