MENU

Gmail×Drive連携の脆弱性で30億ユーザーが対象|情シスの対応手順

Gmail を業務で使っている会社は多いです。

「Scanned by Gmail」というラベルが添付に出ていれば、なんとなく安心していました。私もそう思っていました。

ところが2026年5月11日、その前提を揺るがすリサーチが公開されました。Gmail のスキャナーがウイルスとブロックしたはずのファイルが、Google Drive を経由するとそのまま「Scanned by Gmail」の表示付きで受信トレイに届くという内容です。

発見したのは Pentera Labs の研究員 Ben Ilkashi(ベン・イルカシ)氏。Google には2025年12月に報告済みですが、2026年5月15日時点で公式の修正はリリースされていません。

「Gmail と Drive の連携部分」という、ふだん意識しない隙間に、ほぼすべての Gmail アカウント保有者に影響する設計欠陥が残っている。これは私自身、最初の報道を読んだとき「だと思います」と書いて手が動かなくなりました。検証を進めるほど、影響範囲が大きいことが分かってきたからです。

この記事では一次情報を整理しつつ、企業セキュリティチーム・情シスが今週中に判断すべき内容に絞ってまとめます。

## Pentera Labs が公開した内容を、一次情報ベースで整理する

まず事実関係です。報道の見出しだけ追うと不正確なので、Pentera 公式リサーチと Google の公式声明を突き合わせます。

### 発見者と公開タイミング

| 項目 | 内容 |
|—|—|
| 発見者 | Ben Ilkashi(Pentera Labs 所属) |
| 公開日 | 2026年5月11日 |
| 公開タイトル | Thinking Outside of the (In)Box: Getting Gmail’s “Stamp of Approval” on Malicious Payloads |
| Google への初回報告 | 2025年12月14日(Google Bug Hunters プログラム経由) |
| Google からの回答 | 2026年1月22日「修正タイムライン未定」 |
| 公開時点の修正状況 | 未リリース(UI 表記の明確化対応のみ告知) |

Pentera 側は公開時点で POC 動画・PDF レポートを同時公開しています。攻撃手法そのものは再現可能な状態で公開済みであり、検知側の対応が急がれます。

### 一次情報と二次情報を分ける

報道では「30億人が危険」という見出しが目立ちます。この30億という数字は、Gmail 副社長 Blake Barnes 氏の過去発言「3 billion users rely on Gmail」が根拠で、攻撃で30億人が被害を受けたという意味ではありません。

「Gmail を使っているほぼ全員が、構造上この攻撃の対象になり得る」という意味です。すでに悪用されたという報告は、2026年5月15日時点では出ていません。混同しないことが重要です。

### CVE 番号は割り当てられていない

セキュリティチームから「CVE 番号は?」と聞かれることがあると思います。今回は CVE が割り当てられていません。理由は、Pentera が Bug Hunters プログラム経由で報告し、研究レポートとして公開したためです。CVE が出ていないからといって深刻度が低いわけではありません。番号がないだけで、検知ルールを書く対象としては実在します。

## 攻撃チェーンを、防御の手がかりとして分解する

攻撃手法を解説するのは、防御側で検知ルールを書くためです。POC コードはこの記事には載せません。構造だけ追います。

### フロー1: Gmail のウイルススキャンを回避する経路

1. 攻撃者が悪性ファイル(例: SVG 内に JavaScript を仕込んだもの、または実行可能ファイル)を準備します
2. Gmail で直接添付しようとすると、Gmail のスキャナーが検出してブロックします
3. 同じファイルを Google Drive にアップロードします。ここで Drive 側のスキャンを通る経路では、ブロックされません
4. Gmail から Drive 上のファイルへの共有リンクを本文に貼り、メールを送ります
5. 受信者の受信トレイには「Scanned by Gmail」ラベル付きでメールが届きます
6. リンクから直接ファイルをダウンロードできます

ポイントは6番目です。Gmail のスキャナーが直接添付ではブロックしたファイルでも、Drive 経由のリンクであれば、同じ受信トレイに「スキャン済み」表示で着地します。

### フロー2: Drive 側の警告画面が出ないケース

Drive 上で「不正の疑いあり」と判定されたファイルは、本来 Drive を直接開いたときに警告画面が表示されます。ところが Gmail から Drive リンク経由で開くと、その警告が出ないケースがあります。Drive を直接開けば警告される、しかし Gmail 経由だと出ない、という非対称性です。

ユーザー側からすると「Gmail がスキャン済みと言っている」「警告も出ていない」、この2点を信じる以外の判断材料がほとんどありません。

### なぜ起きるのか、構造的に

Gmail と Drive は別々の脅威モデルで設計されています。

| サービス | 主な評価軸 | スキャンタイミング |
|—|—|—|
| Gmail | メール配信時のマルウェア配布リスク | 添付ファイル受信時 |
| Google Drive | ファイルホスティング・共有時のアクセス制御 | アップロード時・共有時(経路依存) |

連携部分では、Gmail が「Drive 上のファイルは Drive 側で検証済み」と暗黙に信頼します。実装上はリンク形式での共有なので、Gmail 側で再スキャンがかからないケースが生じます。

これは「バグ」というより、Gmail / Drive それぞれの設計思想の境界面に出てきた設計上のギャップです。Pentera 自身が “reproducible architectural gap”(再現可能な構造的ギャップ)と表現しています。修正には UI 変更だけでは足りず、信頼境界の再設計が必要になる可能性が高い。だから Google も「修正タイムラインなし」と返したと考えるのが自然です。

PR

今すぐ使える! Google Workspace & Chromebook 情報セキュリティ管理術(平塚知真子・井上勝・イーディーエル株式会社 著)

Google管理コンソールの初期設定からDLP・共有リンク制御・端末管理まで、Workspace特有のセキュリティ運用を体系的に押さえられる一冊。本記事のような「Gmail×Drive連携の隙間」を業務目線で塞ぐ前提知識づくりに向いています。

## 影響範囲の整理 ~ 個人と Workspace でリスク濃度が違う

「ほぼ全員が対象」と言われると判断に困るので、優先度で並べ替えます。

### リスク濃度の比較表

| 利用環境 | 直接的なリスク | 主な被害シナリオ | 優先度 |
|—|—|—|—|
| Gmail 個人(無料) | 高 | フィッシング誘導、個人情報漏えい、ランサムウェア感染 | 中 |
| Google Workspace(中小企業) | 非常に高 | 業務 PC のランサムウェア感染、認証情報窃取、サプライチェーン経由感染 | 最優先 |
| Google Workspace(エンタープライズ) | 非常に高 | 部署横断的なマルウェア拡散、機密情報漏えい、規制違反 | 最優先 |
| 他メールサービス(Outlook 等)に Drive リンクが届く | 中 | Gmail UI の信頼指標は出ないが、Drive 共有自体は機能する | 中 |

中小企業の Workspace 利用が最もリスクが高い理由は3つあります。1つ目は EDR や DLP の導入率がエンタープライズより低いこと。2つ目はセキュリティチームが専任ではなく情シス兼任で、ユーザー教育の頻度が低いこと。3つ目は経理・人事といった金銭・個人情報を扱う部門が直接 Gmail を業務で使っていることです。

### 「Scanned by Gmail」表示の何が問題か

Gmail のユーザーは、長年「Scanned by Gmail」ラベルを安全の指標として学習してきました。Pentera のリサーチ内でも “Users have been trained over years to trust Google’s safety labels” と指摘されています。

今回の問題は技術的な欠陥に加えて、「ユーザーが安全だと信じる UI を、攻撃者が悪用できる」という心理的な側面が大きいです。技術対策だけでは塞ぎきれず、教育とセットでないと機能しません。

### 攻撃シナリオを、業務文脈で具体化する

抽象的な「悪性ファイル」だとイメージが湧きにくいので、業務でありがちなシナリオに置き換えてみます。

#### シナリオA: 取引先を装った請求書 PDF の偽装

経理担当者宛てに「請求書の差し替えです」というメールが届きます。本文には Google Drive の共有リンクのみ。Gmail のラベルは「Scanned by Gmail」で、警告は出ません。リンクを開くと「請求書.pdf.exe」のような二重拡張子の実行ファイルがダウンロードされます。

経理担当者は普段から Drive 共有で見積書や請求書をやり取りしているため、警戒心が薄くなりがちです。ここで重要なのは「Drive 共有だから安全」という認識を業務文化から取り除くことです。

#### シナリオB: 採用候補者を装った履歴書 SVG

人事担当者宛てに「履歴書を Drive で共有しました」というメールが届きます。SVG 形式の履歴書は珍しいですが、デザイナー職の応募であれば違和感が薄いです。SVG 内に JavaScript が仕込まれていると、ブラウザでプレビュー時に悪意のあるリダイレクトや認証情報窃取に繋がる場合があります。

Pentera のリサーチでも SVG ペイロードが具体例として挙げられています。SVG は「画像」と思われがちですが、構造的には XML で JavaScript を含められる点に注意が必要です。

#### シナリオC: 社内を装った内部脅威の擬装

外部から侵害された Workspace アカウントが、社内の他メンバーへ Drive 共有でファイルを送る経路です。送信者が社内アドレスのため、警戒心はさらに下がります。受信側でも「同じドメインからの送信なので大丈夫」と判断しがちです。

このシナリオに対しては、組織内アカウントであっても挙動ベースで監査する仕組み(UEBA: User Entity Behavior Analytics 的な検知)が必要です。

## 検知と対応 ~ 今週中にやるべき5つの手順

公式パッチが出ていない状況で、できることを優先順に並べます。

### 手順1: Workspace 管理者は Drive 共有リンクを含むメールの監査ログを確認する

Google Workspace 管理コンソールの監査ログから、過去30日間の Drive 経由共有ファイルを抽出します。外部アカウントから自社ドメイン宛て、かつ実行可能ファイル拡張子(.exe / .bat / .vbs / .scr / .js / .svg 等)を含むものを優先的に確認します。

具体的な確認手順は次の通りです。管理コンソール → レポート → 監査と調査 → Drive ログイベント へ進み、フィルタで「イベント=共有可視性の変更」「対象=外部」を指定します。期間を直近30日に設定し、結果を CSV で出力します。Excel で開き、ファイル名カラムを拡張子別にソートして実行可能形式を抽出します。

### 手順2: Gmail コンテンツコンプライアンスルールを追加する

Google Workspace 管理コンソール → アプリ → Google Workspace → Gmail → コンプライアンス → 「コンテンツのコンプライアンス」で、本文に drive.google.com / docs.google.com のリンクを含むメールに対し、警告バナーの自動付加または管理者隔離を設定できます。

外部からの全リンクに対しては運用負荷が高いので、最初は実行可能ファイルへの直接リンクパターンを対象にすると現実的です。

### 手順3: DLP for Drive で外部共有ルールを強化する

DLP for Drive の検出器に「実行可能ファイル」「マクロ付き Office ファイル」「圧縮ファイル内の実行可能形式」を追加し、外部共有を検出した時点で管理者通知+共有ブロックの設定にします。Pentera のリサーチは「Drive 側のスキャンがそもそも回避される」点を問題にしているため、入口での DLP は不可欠です。

### 手順4: EDR / プロキシでの再スキャンを徹底する

ユーザーが Drive からダウンロードした時点で、エンドポイント側で再度スキャンする体制を整えます。EDR 製品が Drive ドメインからのダウンロードに対するルールを持っているか確認し、不足していればプロキシ層で全ダウンロードを多重スキャンします。

### 手順5: 社内アナウンスで「Scanned by Gmail = 安全保証ではない」を周知する

技術対策と並行して、全社員向けに今回の脆弱性の存在を共有します。詳細な技術論ではなく、「ファイルダウンロード時はラベル表示よりも、送信者・文脈・予期されたメールかを確認」という運用ルールに落とし込みます。

## 中小企業情シス向けチェックリスト

明日から動けるかを確認するためのチェックリストです。1つでも × があれば、その項目から着手します。

– [ ] Google Workspace 監査ログで過去30日の Drive 共有ファイルを確認した
– [ ] Gmail コンテンツコンプライアンスで Drive リンク検出ルールを設定した
– [ ] DLP for Drive で実行可能ファイル・マクロ付きファイルの外部共有を制御している
– [ ] EDR で Drive ドメインからのダウンロード時に再スキャンが動く
– [ ] プロキシで Drive 経由ダウンロードのファイル多重スキャンを実施している
– [ ] 経理・人事・経営層に対し、Drive 共有リンクを含むメールへの注意喚起を実施した
– [ ] 「Scanned by Gmail = 安全保証ではない」と社内アナウンスを出した
– [ ] フィッシング訓練のシナリオに Drive 共有を悪用するパターンを追加した
– [ ] Google から公式パッチが出た際に即時適用できる体制を確認した
– [ ] インシデント発生時の社内連絡フローに本件を反映した

10項目すべてに◯がついている会社は少ないと思います。私自身、最初に書き出したとき5項目しか◯にできませんでした。完璧を目指すより、上から順に潰す方が実用的です。

## よくある質問

### Q1. CVE 番号は割り当てられていますか?

A. 2026年5月15日時点で割り当てられていません。Pentera Labs が Google Bug Hunters プログラムを経由して報告し、研究レポートとして公開した経緯のため、CVE 採番のフローには載っていません。番号がないからといって対応を後回しにする理由にはなりません。

### Q2. すでに悪用されていますか?

A. 2026年5月15日時点で、本脆弱性を悪用した実攻撃の報告は確認できていません。ただし POC が公開済みのため、悪用のハードルは下がっています。検知側の対応を急ぐべき段階です。

### Q3. Gmail 個人ユーザーは何をすればよいですか?

A. 「Scanned by Gmail」表示を絶対視しないことが第一です。具体的には、予期しない Drive 共有リンクは送信者の正規メールアドレスを確認する、不審なファイルは VirusTotal などで多重スキャンする、ファイルをプレビューせずにダウンロードしない、の3点が現実的な対策です。

### Q4. Workspace の管理者ですが、まず何から手をつけますか?

A. 監査ログで過去30日間の Drive 共有ファイルの状況を確認するところから始めます。実行可能ファイル形式・マクロ付き Office ファイルが外部から自社ドメイン宛てに届いていないかを優先確認します。同時に、Gmail コンテンツコンプライアンスルールで Drive リンクを含むメールへの警告バナー追加を設定します。

### Q5. 「Scanned by Gmail」ラベル自体を無効化することはできますか?

A. 管理者側でラベルを非表示にする設定は提供されていません。ラベルの解釈をユーザー教育でアップデートする方が現実的です。

### Q6. EDR を導入していない中小企業はどうすればよいですか?

A. 最低限、Windows Defender や macOS の組み込みアンチマルウェアを最新の定義に保ち、ブラウザのダウンロード時スキャンを有効にします。プロキシ層で多重スキャンができれば理想ですが、それが難しい場合は社内ルールで「業務上必要な Drive 共有以外は開かない」という運用に倒します。

### Q7. Microsoft 365 を使っていれば影響はありませんか?

A. メール本文に Drive 共有リンクが含まれていれば、Outlook 経由でも同じ攻撃経路は成立します。Outlook 側では「Scanned by Gmail」ラベルは表示されませんが、Drive のリンク自体は機能します。Drive 共有を業務で使っていない組織でも、外部から送られてくる経路は塞げないため、注意は必要です。

### Q8. Google の公式パッチが出るのを待っても問題ありませんか?

A. 待つだけで対応を見送るのはおすすめしません。Pentera のリサーチでは Google が「修正タイムラインなし」と回答しており、Pentera は構造的ギャップと指摘しています。修正には数か月単位かかる可能性があります。その間、検知側で対応する必要があります。

## まとめ ~ 今日から動くために

今回の Gmail × Google Drive 脆弱性は、攻撃手法の華やかさより、ふだん信頼してきた UI ラベルが、構造的に裏切られていたという事実が重い問題です。

– 発見: 2026年5月11日 Pentera Labs(Ben Ilkashi 氏)
– 公式パッチ: 未リリース(5月15日時点)
– 影響: Gmail を使うほぼ全員、特に Workspace 利用の中小企業
– 攻撃チェーン: Gmail スキャン回避+Drive 警告画面バイパスの2系統
– 今週中の対応: 監査ログ確認、Gmail コンテンツコンプライアンス設定、DLP 強化、EDR / プロキシ再スキャン、社内アナウンス
– ユーザー教育: 「Scanned by Gmail」は安全保証ではないと伝え直す

明日からの会議で1つだけ持ち込むなら、Workspace 監査ログのチェックを最優先で組み込むことをおすすめします。「悪用されているか」を確認する基礎データになります。

セキュリティの実務は「全部やる」ではなく「優先順をつけて、今日できる1つを片付ける」の積み重ねです。この記事のチェックリストの上から、1つずつで構いません。

### あわせて読みたい本

PR

AWSではじめるクラウドセキュリティ クラウドで学ぶセキュリティ設計/実装(松本照吾・桐谷彰一・畠中亮・前田駿介 著)

IAM・データ保護・ログ監視・脅威検知といったクラウド共通テーマを、AWSの具体構成で読み解ける一冊。Workspaceに加えてIaaS/PaaS側のセキュリティ設計まで視野を広げたい情シス・インフラ担当者の入門書としておすすめです。

セキュリティマスターズ.TOKYO の無料メルマガでは、本記事のような企業情シス向けセキュリティ速報と、防御目線の具体的な手順を毎週お届けします。

無料メルマガに登録する

Let's share this post !

Author of this article

TOC