Webmail CSS攻撃がAIメール防御の死角を露呈
Google Newsは、2026年4月以降に100万通を超えるフィッシングメールで確認されたwebmail CSS攻撃を取り上げた。このキャンペーンは、AIメールセキュリティにおける根本的な矛盾を露呈している。人間と機械は同じメッセージを受け取っても、まったく異なる内容を読む可能性がある。
報告された「text salting」と呼ばれる手法は、Cascading Style Sheetsを用いてHTMLメール内の埋め草テキストを隠すものだ。受信者に見える内容を変えずに、自動化システムによるメッセージ解釈を変化させる。
Barracudaの研究者は、報酬、ギフトカード、ロイヤルティポイント、または緊急の交換手続きをうたう小売業界を装ったフィッシングキャンペーンでこの手法を発見した。攻撃者は隠しテキストを使い、不審な文言を薄めて、悪意あるメールを自動フィルタに対してより安全に見せかけた。
これは単なるスパムフィルタ回避の新たな手口ではない。同じ可視性の隔たりは、逆方向にも機能しうる。隠された指示は、メールを要約したり、返信文を下書きしたり、メールボックスを検索したり、接続済みツールを呼び出したりするAIアシスタントを標的にできる。
ここに中核となるセキュリティ上のトレードオフがある。AIメールツールは、より多くの文脈を読み、より大きなアクセス権を得るほど有用になる。その同じ能力が、信頼できないメールコンテンツがモデルに影響を及ぼした際の影響範囲を拡大する。
従来の防御は、人に表示されるメッセージがおおむねソフトウェアが検査するメッセージと同等であることを前提としている。CSSは、1通のメールの中に、人間に見える版と機械が読める版を別々に作り出すことで、この前提を崩す。
当面の対応を迫られるのは、Google、Microsoft、メールセキュリティベンダー、そしてメールボックスのデータ上でアシスタントを構築する開発者だ。アクセシビリティや正当な書式を維持しながら、生のメッセージ分析とレンダリングされた内容を整合させなければならない。
Google Newsの報道が明らかにするText Salting
重要な変化は、攻撃者が隠しテキストを発見したことではない。古くからの回避手法が、いまやAIベースの判断に対して機能するようになったことだ。
Text saltingは、悪意あるメッセージに無害な、あるいは文脈と無関係な単語を追加する。セキュリティソフトウェアはそれらの単語を分析する一方、CSSにより受信者には見えないようにする。
Barracudaは、2026年4月以降、これらの手法を使った100万件の攻撃を検出したと報告している。メッセージは、報酬や交換オファーを中心に構成された小売業界を装うキャンペーンに属していた。
攻撃者は複数の一般的なCSSプロパティを使用した。clip-path: inset(100%)はテキストブロックの可視領域を完全になくした。高さゼロおよび行高ゼロのルールは、不審な空白を取り除いた。
別のルールはテキストを画面境界の外へ押し出した。大きな負のtext-indentはテキストを左へ数千ピクセル移動させ、overflow: hiddenは手掛かりとなるスクロールバーを表示させなかった。
攻撃者はフォントもゼロまで縮小した。これらのプロパティ自体に悪意があるわけではない。この曖昧さにより、正当なメールテンプレートでも類似のスタイリング手法が使われうるため、単純なブロックリストは信頼できないものとなる。
このキャンペーンは、侵害されたWebサイトまたは類似ドメインに依存していたと報じられている。一部のドメインは、認可されたドメインがメッセージに署名したことを検証するDomainKeys Identified Mail、すなわちDKIMを含む標準的なメール認証をサポートしていた。
DKIMはコンテンツが誠実かどうかを判断しない。ドメインレベルでのメッセージ処理と完全性を検証する。認証済みドメインを管理する悪意ある運用者でも、フィッシングを配布することは可能だ。
この違いが重要なのは、AIシステムが多くの場合、多数のシグナルを組み合わせるためだ。認証、自然言語、送信者の評判、表示されるリンク、メッセージ構造は、それぞれ分類に影響を与えうる。
Text saltingは言語シグナルを操作する。人間の受信者にはフィッシングの誘い文句を明確に残したまま、分類器に対しては無害に見えるテキストの量を増やす。
生のHTMLを検査するフィルタは、無関係な事業活動、カスタマーサービス、または通常の小売取引に関する段落に遭遇する可能性がある。受信者には、緊急の報酬通知とボタンだけが表示されるかもしれない。
これは、敵対的入力の意味論的な形態を生み出す。攻撃者は必ずしもソフトウェアのメモリ脆弱性を悪用しているわけではない。統計的な意思決定システムが用いる証拠を形成しているのだ。
生成AIは、多様な埋め草を作成するコストも引き下げる。攻撃者はメールごとに異なる無害な文章を生成でき、完全一致のテキスト照合の価値を下げられる。
したがってGoogle Newsの見出しは、より広範な変化を示している。メールコンテンツはいまや、ユーザー向けの一つの物語と、機械向けの別の物語という、二つの読者に向けて設計できる。
AIメールフィルタがレンダリング問題に直面する理由
AIモデルは、その入力が受信者に表示されるメッセージと一致しない場合、メールを信頼性高く判断できない。
多くのメールセキュリティシステムは、生のメッセージコンテンツに価値ある証拠が含まれるため、それを検査する。そこにはURL、HTML属性、メタデータ、エンコードされたセクション、そしてレンダリングによって隠される可能性のあるテキストが現れる。
隠しテキストが主にキーワードベースのスパムスコアリングを標的としていた時代には、このアプローチは理にかなっていた。防御側は不審な書式を探し、表示される単語を基礎となるソースと比較できた。
大規模言語モデルはこのプロセスを複雑にする。長い文章にわたって意味を推論できる一方で、その能力は隠し埋め草が分類に及ぼす影響も大きくする。
モデルは、通常の小売関連の言語が大半を占めるメッセージを見る可能性がある。目に見えるフィッシング要求は、機械可読な入力全体のごく一部しか占めないかもしれない。
この攻撃では、モデルが直接の命令に従う必要はない。見かけ上の話題、口調、または意図を十分に変え、無害という分類を導くだけで成功しうる。
レンダリング済みの分析にも問題がある。メールクライアントごとにHTMLとCSSのサポートは異なる。メッセージはGmail、Outlook、モバイルアプリケーション、専門的なwebmailソフトウェアで異なる表示になる場合がある。
アクセシビリティ機能も、標準の視覚的レンダリングでは隠れるテキストを露出させる可能性がある。スクリーンリーダー、高コントラストモード、簡易表示は、唯一の決定的な表示があるという主張を複雑にする。
したがってセキュリティツールには、スクリーンショット以上のものが必要だ。生のコンテンツ、計算済みレイアウト、アクセシビリティ出力、そして一般的なユーザーが知覚できる要素の間を構造的に比較する必要がある。
最も有用な問いは、あるプロパティが単独で不審に見えるかではない。スタイリングが、機械の解釈と人間の知覚の間に意味のある違いを生み出しているかどうかだ。
無関係な単語を数百語含むゼロサイズの段落は、単一の隠された書式ラベルよりも強いシグナルとなる。大きな画面外ブロックも同様に精査する価値がある。
防御側は、表示領域と隠し領域の言語的な意味も比較できる。ロイヤルティ報酬に関するメッセージに、無関係な請求書、旅行、カスタマーサポートについての隠された段落が含まれているべきではない。
ただし、攻撃者も適応できる。可視部分の話題に近い埋め草を生成し、悪意あるフレーズを薄めながら意味的な差異を小さくできる。
これにより、コンテンツ生成と可視性を意識した検知の間で軍拡競争が生じる。フィルタは、メッセージが何を言っているかだけでなく、受信者にとってどの部分が重要かも理解しなければならない。
機械学習がここで役に立たないわけではない。構造的な異常、送信者のパターン、キャンペーンのインフラ、スタイリングルールの異常な組み合わせを見つけるうえで、依然として価値がある。
問題はアーキテクチャ上の過信にある。言語モデルは、信頼された指示、信頼できないコンテンツ、不可視の素材を明確な境界なしに混在させる入力パイプラインを補うことはできない。
Googleは、間接的プロンプトインジェクションに対する多層防御を説明している。そのアプローチには、コンテンツ分類器、敵対的学習、レッドチーミング、機微な操作の前の確認が含まれる。
これらの対策は、メール防御が進むべき方向を示している。特にCSSによって観察者ごとに受け取る内容が変わる場合、単一モデルの判定だけでメールが安全かどうかを決めるべきではない。
隠しコンテンツはフィルタもアシスタントも標的にできる
同じCSSの可視性ギャップは、人間から無害なテキストを隠す攻撃と、人間から悪意ある指示を隠す攻撃という、相反する二つの攻撃を支える。
Text saltingは、悪意あるメールをセキュリティシステムに対して無害に見せようとする。間接的プロンプトインジェクションは、ユーザーが意図的に提供していない指示にAIアシスタントを従わせようとする。
OWASPは間接的プロンプトインジェクションを、AIシステムが後から処理する外部コンテンツに埋め込まれた悪意ある指示と定義している。誰でも多くのメールボックスに入力を送れるため、メールは自然な配信チャネルとなる。
攻撃者は、白いテキスト、ゼロサイズのフォント、画面外への配置、エンコードされた文字、または視覚的レンダラーが省略するHTML構造を使って指示を隠せる。
被害者は、未読メッセージを要約するようアシスタントに依頼するかもしれない。自律ワークフローは、直接の要求なしに受信トレイを処理する可能性がある。いずれの場合でも、モデルは攻撃者が作成した指示に遭遇しうる。
単純な攻撃は要約を操作する可能性がある。AIはセキュリティ警告を捏造したり、フィッシングの兆候を抑えたり、悪意あるメッセージを承認済みとして説明したりしかねない。
アシスタントが他のメッセージを検索し、接続済み文書を読み、送信メールを下書きし、または外部ツールを呼び出せる場合、より深刻な攻撃が可能になる。
その場合、悪意あるメールは制御入力として機能する。ユーザーのタスクからアシスタントをデータ取得、情報開示、または認可されていない操作へと誘導しようとすることができる。
Microsoftは2026年7月、Defender for Office 365における受信トレイ・インジェクション保護を発表した。この機能は、対象となる顧客向けにパブリックプレビューとして提供された。
Microsoftによれば、このシステムはメールフロー検査中に悪意あるAI指示を検出する。検出されたメッセージには高確信度のフィッシング判定が付与され、ユーザーや接続済みアシスタントに届く前に隔離できる。
この配置は重要だ。配信前に攻撃を遮断すれば、メールボックスの検索インデックス、検索・取得システム、要約、下流のエージェントコンテキストに侵入することを防げる。
ただし、ゲートウェイでの検知だけですべてのケースを解決できるわけではない。攻撃者は、侵害された社内アカウント、許可されたメーリングリスト、転送されたスレッド、または添付ファイルに悪意ある指示を置くことができる。
言語モデルにとって、指示とデータの区別も依然として難しい。どちらも自然言語として到着し、要求、引用されたコマンド、または手順書的なテキストを含みうる。
上司からのメールには、「添付ファイルを確認して、返信を送ってください」と正当に書かれているかもしれない。悪意あるインジェクションは、従業員ではなくAIに向けながら、ほぼ同じ文言を使える。
アシスタントは権限、出所、意図を推論しなければならない。自然言語を流暢に扱えるだけでは、こうしたセキュリティ特性は得られない。
だからこそ、フィルタ攻撃とアシスタント攻撃は同じ議論に属する。どちらも、表示されるコンテンツ、処理されるコンテンツ、認可されたコンテンツの間にある曖昧さを悪用している。
Google NewsはAI搭載メール防御に関する記事を取り上げたが、その意味合いはスパム分類を超える。メールボックスに接続するすべてのエージェントは、この未解決の入力境界問題を引き継ぐ。
EchoLeakが示した、メールがツールに到達したときに起こること
AIアシスタントが私的なコンテキストを取得し、メールボックスの外部と通信できる場合、隠されたメールは大幅に危険性を増す。
2025年のEchoLeakの開示は、具体的な警告となった。研究者らは、Microsoft 365 Copilotと巧妙に作成されたメールを使う多段階の攻撃を説明した。
MicrosoftはEchoLeakをCVE-2025-32711として特定し、問題は修正済みだとしている。同社はこれを、被害者がすでにアクセスできる限定的なデータを露出させる可能性があるクロスプロンプト・インジェクション手法と説明している。
MicrosoftのAIセキュリティガイダンスによると、一見無害なメッセージでも、Copilotが処理するコンテキストを汚染する可能性がある。この手法は、特定の条件下で意図しない情報開示を引き起こし得る。
この事案が重要だったのは、まずユーザーのパスワードを盗む必要がなかった点だ。攻撃者は、アシスタントが読むことを想定されていたデータを通じてアシスタントを標的にした。
EchoLeakは、Google Newsが取り上げたテキスト・ソルティングのキャンペーンより複雑だった。複数の段階と条件を伴う一方、テキスト・ソルティングは主に分類の回避を狙う。
それでも両事例は、同じ前提に疑問を投げかける。メールはコンテンツとして扱われるが、その一部はAIシステムに対する敵対的な指示として機能し得る。
リスクは、検索拡張生成、すなわちRAGによって高まる。この設計では、関連する非公開情報を取得し、回答を生成する前にモデルのコンテキストへ追加する。
RAGは、メールアシスタントがプロジェクト、予定、顧客、過去の議論に関する質問へ答える助けとなる。同時に、価値の高い情報を、攻撃者が制御するメッセージ内容の近くに配置することにもなる。
ツールへのアクセスは、さらに別の層を加える。要約のみを行うアシスタントはユーザーを誤導し得るが、メッセージングやファイル操作のツールを持つエージェントは、直接的な業務上の結果を引き起こし得る。
開発者はしばしば、悪意ある指示を無視するようモデルに指示するシステムプロンプトに依存する。この対策は有用だが、強固なセキュリティ境界を作るものではない。
LLMail-Injectと呼ばれる大規模な研究チャレンジでは、839人の参加者から208,095件の攻撃投稿が集められた。研究者らは、現実的なメールエージェント環境で、複数の防御策、モデル、検索構成をテストした。
投稿数の多さが重要なのは、適応的な攻撃者が明白なフレーズを一つ繰り返すわけではないためだ。攻撃者は、変換、表現方法、エンコード、社会的文脈、モデル固有の挙動を探る。
防御側は、あらゆる分類器やプロンプトガードが偽陰性を生み得ると想定すべきだ。機微な操作には、モデルの解釈に依存しない独立した認可制御が必要となる。
メール要約ツールは、メールを読めるというだけでメッセージ送信の権限まで得るべきではない。検索アクセスも、すべてのメールボックスフォルダーや接続済み文書へのアクセスを意味すべきではない。
ツール呼び出しには、各コンポーネントに現在のタスクで必要な権限だけを与える最小権限の原則を適用すべきだ。影響の大きい操作には、明示的なユーザー確認を求めるべきである。
セキュリティチームには、どのメッセージが出力や操作に影響したかを示すログも必要だ。プロベナンスがなければ、インシデント対応者は汚染された入力を容易に特定できない。
AIシステム向けのソース資料を管理するユーザーも、関連する課題に直面する。明確な情報収集とソースの分離はコンテキストの維持に役立つが、アプリケーションレベルの権限制御は依然として不可欠だ。
EchoLeakから得られる教訓は、すべてのメールアシスタントが安全でないということではない。セキュリティは会話上の見た目ではなく、その権限に応じて設計されなければならないということだ。
防御におけるトレードオフは可視性と有用性の間にある
すべての隠し要素を削除すれば一部の攻撃は減らせるが、正当なメールも損ない、より深い認可の失敗は未解決のまま残る。
厳格なサニタイザーなら、AIシステムがメッセージを読む前に、CSS、隠し要素、リモートリソース、複雑なHTMLを取り除ける。これにより攻撃対象領域は大幅に縮小する。
しかし、正当なメールをユーザーやモデルが理解する助けとなる構造も取り除かれる。表、レスポンシブレイアウト、引用、署名、アクセシビリティラベル、取引メールの書式はいずれも有用な意味を持ち得る。
一部の隠しコンテンツには運用上の目的がある。プレヘッダーテキストは短い受信トレイのプレビューを提供でき、レスポンシブデザインはデスクトップ画面とモバイル画面で異なる要素を表示する。
セキュリティ製品は、こうしたケースと、分類を操作するために設計された大きな隠しブロックを区別しなければならない。この判断を一つのCSSプロパティに依存することはできない。
制御されたブラウザー内で各メッセージをレンダリングすれば、可視性の分析を改善できる。一方で、計算コストが増加し、セキュリティパイプラインにブラウザーエンジンが導入されることになる。
レンダリング結果も、すべてのクライアントと一致するとは限らない。モバイル幅、ダークモード、ブロックされた画像、言語設定、アクセシビリティ設定は、いずれも結果を変え得る。
より安全な戦略は、複数の表現を用いることだ。システムはフォレンジック分析用に生コンテンツを保持し、正規化されたビューを計算し、隠れた領域や低可視性の領域を別途特定できる。
AI分類器には、そうした領域について明示的なラベルを渡すべきだ。隠しコンテンツを、表示コンテンツと同じ区別のないテキストストリームへ黙って流し込むべきではない。
アシスタントは、隠されたテキストを信頼できないメタデータとして扱える。ユーザーがセキュリティ分析を求めた場合にのみ、その隠しコンテンツを要約することもできる。
プロンプトインジェクション検出器は、もう一つの防御層を提供する。Microsoftの実装は、アシスタントが処理する前に、件名、本文、HTML、スタイル、転送されたコンテンツ、エンコードされた素材を検査する。
それでも、プロンプトインジェクションの検出は確率的なものだ。正当なメールにも、プロンプト、セキュリティテスト、自動化コマンド、引用された悪意あるメッセージに関する議論が含まれ得る。
研究チームは、本物の攻撃サンプルをメールで受け取る場合がある。受信者がそれを期待していても、セキュリティフィルターがそうしたメッセージを隔離する可能性がある。
偽陽性は、強制措置を緩める圧力を生む。重要なメールが頻繁に消えるなら、管理者は攻撃者が研究・悪用できる例外を追加する。
人による確認も完全ではない。特に反復作業の最中には、インターフェースが通常の手順として提示する要求を、ユーザーは日常的に承認してしまう。
したがって、確認では提案された操作、その対象、関与するデータを説明しなければならない。「続行」するかを尋ねる曖昧なプロンプトでは、ほとんど保護にならない。
最も強力な設計は、モデルの推論とポリシーの強制を分離する。モデルは操作を提案できる一方、決定論的なソフトウェアが権限、宛先、データ分類、承認要件を検査する。
このアプローチは、隠しプロンプトと通常のモデルエラーの双方による被害を抑える。操作されたアシスタントでも、言語コンテキストの外側で強制される境界を超えることはできない。
その代償は利便性の低下だ。ユーザーは、高リスクなタスクでより多くのプロンプト、より狭い連携、より遅い自動化に直面する可能性がある。
アシスタントが外部メッセージを送信し、機密文書を取得し、記録を変更し、または財務ワークフローを開始できる場合、その摩擦は正当化される。低リスクの要約には、より軽い制御を維持できる。
したがってAIメールツールは、段階的な権限を採用すべきだ。選択したメッセージの閲覧、フォルダーの検索、返信の下書き、その返信の送信は、それぞれ別個の権限レベルであるべきだ。
セキュリティチームが次に注視すべきこと
次の段階は、別のモデルベンチマークではなく、検出品質、権限設計、実環境での悪用を示す証拠によって評価される。
最初の兆候は、可視性を考慮したメール検査の利用拡大だ。Microsoftのパブリックプレビューは、プロンプトインジェクションが独立したメールセキュリティのカテゴリーになりつつあることを示している。
セキュリティチームは、ベンダーがこうした検出結果をどのように提示するかを注視すべきだ。有用な製品は、隠し領域を特定し、その役割を説明し、調査用の証拠を保持する。
一般的なフィッシング判定だけでは不十分だ。アナリストは、メッセージにCSSで隠されたフィラー、エンコードされた指示、不審なツール指令、あるいは表示内容と生コンテンツの異例な不一致が含まれていたかを知る必要がある。
二つ目の兆候は、Google、Microsoft、第三者開発者がメールボックス接続型エージェントをどのように制限するかだ。モデルのアップグレードよりも、検索とツール利用を取り囲む強制可能な境界の方が重要である。
購入者は、アシスタントが外部メッセージと内部指示を区別するかを尋ねるべきだ。また、取得されたコンテンツに送信者の身元、場所、信頼レベルが保持されるかも確認すべきである。
管理者には、特定の操作を制御する仕組みが必要だ。ポリシーでは、要約を許可しても、送信メール、ファイルアクセス、カレンダー変更、第三者API呼び出しを自動的に許可しないようにすべきだ。
三つ目の兆候は、悪用に関する検証済みの証拠だ。Barracudaのテキスト・ソルティングのデータは、フィルターに対する大規模な展開を示すが、すべてのメッセージがLLMベース製品を回避したことを裏付けるものではない。
ベンダーは可能な限り、手法と分母を公開すべきだ。検出件数だけでは、配信率、分類の成功、被害者とのやり取り、下流での侵害を明らかにできない。
同じ注意は、プロンプトインジェクションの実演にも当てはまる。研究室での攻撃はセキュリティ上の経路が存在することを証明するが、本番環境の制御によって実用上の信頼性は変わり得る。
逆に、公開されたインシデントがないことも安全の証明にはならない。AIエージェントの操作は通常のユーザー活動に似る可能性があり、詳細なログがなければインシデントの特定は困難になる。
組織は、完璧な測定を待つ必要はない。AIが受信メールを処理したり、メールボックスのコンテキストを取得したりするすべてのワークフローを洗い出すことから始められる。
チームは、各アシスタントが読めるもの、呼び出せるツール、承認を必要とする操作を文書化すべきだ。また、隠しコンテンツや画面外のコンテンツを含むメッセージもテストすべきである。
セキュリティ演習には、両方の攻撃方向を含めるべきだ。一つのテストでは、分類を回避するために無害なフィラーを隠す。もう一つでは、アシスタントを狙った悪意ある指示を隠す。
開発者は、システムが不確実性を説明するかを評価すべきだ。矛盾する指示や隠された指示を検出したアシスタントは、処理を停止し、不審なソースを特定すべきである。
ユーザーは、メール要約内にあるAI生成の警告に対しても懐疑的であり続けるべきだ。洗練された警告であっても、インターフェースが信頼できるプロバイダーのものでも、攻撃者が制御するコンテンツに由来する可能性がある。
情報提供を目的とするワークフローでは、元のソースを利用可能な状態に保ち、行動する前に重要な主張を検証する。AI要約はレビューを加速すべきであり、プロベナンスを置き換えるべきではない。
Google NewsはWebメールのCSS攻撃への関心を再び高めたが、永続的な問題は一つのキャンペーンより大きい。メールは今や、人間、分類器、検索システム、自律型ツールのためのコンテンツを運ぶ。
こうした対象は、同じメッセージを同じようには認識しない。セキュリティシステムがこの違いを直接モデル化するまで、攻撃者は人間が見るものと機械が読むものの隔たりを利用し続けるだろう。
