Edgeを起動するたびに、保存されたすべてのパスワードが平文でRAM上に展開される。使う予定のないサイトの認証情報も含め、ブラウザを開いた瞬間から終了するまで、その状態が続く。デバイスがマルウェア感染していれば、攻撃者はメモリを読み取るだけで全認証情報を一括取得できる。ノルウェーのセキュリティ研究者 Tom Jøran Sønstebyseter Rønning氏がこの挙動を公開し、概念実証ツールを公開したのは2026年5月4日のこと。Microsoftは当初「設計通りの機能」と主張したが、コミュニティからの批判を受けて約10日後に修正を決定した。修正後もMicrosoftは「ユーザーは新たなリスクにさらされていなかった」という立場を崩していない。
EdgeのVault起動時展開 vs Chromeの需要時復号：技術設計の分かれ道
Chromiumをベースとするブラウザが複数存在する中で、この挙動が確認されたのはEdgeだけだ。ChromeはApplication-Bound Encryption（ABE、アプリケーション紐づけ暗号化）を2024年7月のバージョン127で導入し、パスワードの復号をそれが実際に必要なタイミングに限定した。復号鍵はChromeプロセス自体に紐づけられており、別プロセスからのアクセスには追加の認証が必要とされている。
Rønning氏が実地テストしたChrome・Brave・その他のChromiumベースブラウザはいずれも同様の「需要時復号」モデルを採用していたと報告されている。EdgeはこれらChromiumベースブラウザの中で唯一、異なる設計を選択していた。
EdgeはWindowsの認証情報管理機能（Vault）を利用しているが、その展開タイミングがEdge起動時と設定されていた。ユーザーがEdgeを開いた時点で、保存済みパスワードがすべて平文でRAM上に置かれる。ブラウザのセッション中ずっとその状態が続くため、Edgeのプロセスメモリを読み取れる状態に達した攻撃者は、認証情報を一括取得できる。Rønning氏が公開した概念実証ツール「EdgeSavedPasswordsDumper」はGitHubで公開されており、管理者権限があれば別のユーザーが使用しているEdgeプロセスからでもパスワードをダンプできることが確認されている。同一ユーザーのプロセスであれば管理者権限なしでも同様の操作が可能だ。
この設計がとくに問題視されたのは、RDS（Remote Desktop Services）やCitrixのような共有環境だ。複数のユーザーが同一のWindowsサーバー上でEdgeを使う環境では、管理者権限を持つ攻撃者が全ユーザーの認証情報をメモリから取得できる可能性がある。Secure.com CEOのUzair Gadit 氏は「共有環境での単一の特権侵害が、複数ユーザーにまたがる大規模な認証情報露出に発展しうる」と指摘している。
Edgeが「脅威モデル外」で対処を拒んだ設計思想と、それを覆すに至ったコミュニティ圧力
Rønning氏はノルウェーの国家電力グリッド運営会社Statnett SFのセキュリティリードという立場から、2026年4月29日、Palo Alto Networks Norwayが主催した「BIG Bite of Tech」カンファレンスでこの調査結果を発表した。その後5月4日にX（旧Twitter）で動画解説とEdgeSavedPasswordsDumperを公開したことで、情報がセキュリティコミュニティに広く知れ渡った。SANSインターネットストームセンターはこの問題を独立して再現し、WindowsのTask ManagerとSysinternalsのstringsユーティリティという一般的なツールで数分以内に確認できたと報告している。
Microsoftの初期回答は「expected feature of the application（アプリケーションの想定された機能）」だった。根拠として示されたのが既存の脅威モデルだ。「デバイスがすでに侵害されている状態を前提とした攻撃は、想定する脅威スコープの外にある」という論理で、メモリ読み取りが可能な攻撃者にパスワードが見えてしまう問題は対処する設計になっていないという立場だ。企業セキュリティの世界でこの線引き自体は珍しくない。ChromeのABEは同じ「侵害後」のシナリオでも攻撃者のコストを上げる設計であり、Edgeはその選択をしなかった—これが研究者側の核心的な反論だ。
コミュニティからの批判が大きくなると、Microsoftは2026年5月14日、Edge build 148以降で起動時の平文パスワードメモリロードを廃止すると発表した。修正はすでにCanaryチャンネルで有効になっており、Stable・Beta・Dev・Extended Stableの全チャンネルに順次展開される予定だ。ユーザー側での操作は不要で、通常のEdge更新を通じて適用される。
修正は決まったが「リスクはなかった」は変わらず：Microsoftの矛盾
発表の中でEdge Security LeadのGareth Evans氏は「Secure Future Initiative（SFI、セキュア・フューチャー・イニシアチブ）へのコミットメントと顧客フィードバックを踏まえ、defense-in-depth（多層防御）の改善として取り組む」と述べた。SFIは2023年11月にMicrosoftが発足させたサイバーセキュリティ強化の多年計画で、34,000人相当のエンジニアが投入されているとMicrosoftは主張する。今回の修正をSFIの文脈に位置づけることで、脆弱性への対応としてではなく継続的なセキュリティ改善の一環として提示する意図が読み取れる。
Microsoft VP for Edge SecurityのAndrew Ritz氏のコメントはこの構造をよく表している。同氏は「報告された挙動はユーザーを新たなリスクにさらすものではないが、それが作業の終点ではなく始点だ」と述べた。設計上の問題と位置づけずに修正した。修正発表がRønning 氏のX公開から約10日後に起きたことを考えれば、外部からのコミュニティ圧力が意思決定を動かしたと見るのが自然だ。「リスクはなかった」という主張を維持したまま修正を決定した構造は、技術的評価の変化ではなく外部圧力への対応であることを示している。
インフォスティーラー全盛期に設計論争が突きつける問い
BeyondTrustのChief Security AdvisorであるMorey Haber氏は「パスワードはもともと一時的な秘密情報として設計されており、入力・検証・破棄というライフサイクルを想定していた。それがシステムメモリ上に長期間残存するものに変わってしまった」と述べている。現代のインフォスティーラーマルウェアは、まさにこのギャップを狙っている。
この現実は統計に表れている。Recorded FutureやSpyCloud等の調査では、2025年に18億件超の認証情報が窃取された。企業IDへの被害割合は2024年初頭の約6%から2025年末には約14%へ倍増した。
Approov CEOのTed Miracco 氏は「現代のインフォスティーラーは、保存時に暗号化された認証情報が実行時に露出するギャップで生きている。業界はapp-bound（アプリ紐づけ）でジャストインタイムなアクセスへ移行する必要がある」と指摘する。ChromeのABEは万全ではなく、2024年9月時点でLummaC2・Vidarといった複数のインフォスティーラーにバイパスされていたことが確認されている。それでも、起動時に全件を平文展開するEdgeの設計と比べれば、攻撃者に課されるコストが根本的に異なる。セキュリティ設計の目標は「侵害を100%防ぐ」ことではなく、攻撃を割に合わないものにするコスト設計にある。
研究者対応プロセスの見直しが問われる本当の理由
Andrew Ritz 氏はLinkedInで、研究者レポートへの対応プロセスを「スピード・明確性・defense-in-depth思考の早期適用を重視する方向で見直す」と表明し、改善内容を近く共有すると述べた。これは「設計通り」という初期回答が妥当だったかどうかを問われた文脈での発言であり、今回の一連の対応が研究者コミュニティとの関係においてどう受け止められるかを意識した内容だ。
Responsible Disclosure（責任ある情報開示）のプロセスで研究者が直面する課題の一つは、ベンダーが「脅威モデル外」と判断した問題に対して交渉の余地をどう確保するかだ。Rønning 氏はカンファレンス発表とPoCツール公開という形でコミュニティへの働きかけを選んだ。方針転換はそこから約10日後に起きた。Andrew Ritz 氏のコメントには「リスクはなかった」という主張が含まれたままであり、研究者側が本来求めていたものとのギャップは埋まっていない。
ベンダーが脅威モデルを守り続ける理由は一つではない。技術的な修正コスト、責任認定を避けるための法的リスク管理、あるいは設計思想の慣性—いずれも組織の判断に影響する。Microsoftが「リスクはなかった」を手放さない理由もここにある。ベンダーは脅威モデルの枠組みで法的責任を限定したいのであり、その枠組み自体を変えるには業界全体からの圧力が必要だ。build 148での修正が展開された今、Edgeユーザーが得るのは設計の改善であって、Microsoftの判断基準の変化ではない。ChromeのABEのような「攻撃コスト上昇型」の設計を業界標準として求めるか、ベンダーの「設計通り」という判断に委ねるかを選ぶのは、最終的にはユーザーとコミュニティの圧力次第だ。