本文へ移動
情シスのミカタ
ニュース約5分で読めます

AndroidのAuthenticator、偽のアプリにトークンを渡す脆弱性 9月に修正

Microsoftが9月8日に直したAndroid版Authenticatorの脆弱性について、発見したEnclaveが10月23日に中身を公開しました。権限の無いアプリがTeamsなどを名乗り、仕事用のアカウントのトークンを受け取れたといいます。端末の版の確認と、パスキーの見直しの手順を整理します。

公開 情シスのミカタ編集部AIにより執筆編集部が確認:
文字
AndroidのAuthenticator、偽のアプリにトークンを渡す脆弱性 9月に修正

この記事のまとめ

  • Android版のAuthenticatorは、呼び出したアプリの名乗りを信じてトークンを返していました。権限を持たない偽のアプリでも、TeamsやAuthenticator自身になりすませたのです。
  • Enclaveの試験では、メールの送信やファイルの書き換えに加え、パスキーの作成まで通りました。MSRCの表示では、悪用は確認されていません。
  • 修正版は6.2606.4246です。管理する端末はIntuneで版を見て、更新モードを「優先度高」に。心配な社員は、パスキーとセッションも見直します。
こんな方に#30代#40代#50代実務

社員のAndroidに入っているMicrosoft Authenticatorが古いままなら、9月に直ったはずの脆弱性は、まだその端末に残っています。

Microsoftは2026年9月8日、Android版のAuthenticatorの脆弱性(CVE-2026-80097)を公表し、修正版を出しました。見つけたセキュリティ企業のEnclaveは10月23日(米国時間)に詳しい中身を公開し、権限を一つも持たないアプリが、仕事用のアカウントのトークンを受け取れたと明かしています。

MicrosoftのセキュリティアップデートガイドのCVE-2026-80097のページの一部。題はMicrosoft Authenticator における権限昇格の脆弱性。影響は特権の昇格、最大深刻度は重要、脆弱性の分類はCWE-287 Improper Authentication、CVSSのソースはMicrosoft、攻撃対象の文字列はCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C、MetricsはCVSS 3.1で8.6と7.5
MSRCのCVE-2026-80097のページ。深刻度は重要、CVSSは8.6出典: Microsoft「CVE-2026-80097 Microsoft Authenticator における権限昇格の脆弱性」(引用)

「Teamsです」と名乗るだけで、トークンが渡った

Android版のAuthenticatorは、認証のコードを出すだけのアプリではありません。TeamsやOutlookがサインインするとき、代わりに認証をしてトークンを渡す「ブローカー」の役も持っています。トークンは、サインイン済みであることを相手のサービスに示すデータです。

Enclaveによると、Authenticatorには、端末のどのアプリからでも呼び出せる画面がありました。呼び出したのが誰かは、呼び出した側の申告をそのまま使っていたといいます。

確認の仕組みはありました。ただ、それは名乗ったアプリの署名から作った値と、送られてきた値が合うかを見るだけのものです。本物のTeamsが端末に入っていれば、その値はどのアプリでも作れます。偽のアプリでも通るわけです。

Authenticatorは本当の呼び出し元を知っていたのに、信用の判断には使っていなかった。Enclaveはそう書いています。返ってきた結果には、アクセストークン、更新トークン、IDトークンが、そのまま読める形で入っていました。

取られたトークンでできたこと

Enclaveの試験では、偽のアプリが3つの相手になりすまし、それぞれ別の権限を受け取りました。

なりすました相手 受け取れた権限の例
Teams(Microsoft Graphを要求) メールの読み書きと送信、ファイル、予定表、SharePointのサイトの読み書き、Teamsのメッセージの送信
Teamsのチャットの裏側のサービス 利用者になりかわって操作する権限
Authenticator自身 サインインの方法の読み書き、パスキーの作成と削除
Enclaveのブログの節『Three Disguises, Three Sets of Scopes』(英語)。Teamsになりすましてgraph.microsoft.comを要求するとMail.ReadWrite、Mail.Send、Files.ReadWrite.All、Calendars.ReadWrite、ChatMessage.Send、Sites.ReadWrite.Allなど。Teamsのチャットの裏側api.spaces.skype.comになりすますとuser_impersonation。Authenticator自身になりすますとUserAuthenticationMethod.ReadWrite、Passkey.Create、Passkey.Delete。最後に、Teamsになりすましてgraphを要求すればメール、ファイル、予定表に代理でフルにアクセスでき、端末の悪意のあるアプリなら誰でもこの手順を実行できる、とある
Enclaveのブログ。3つの相手になりすまし、3通りの権限を得た出典: Enclave「AuthMask: We Made Microsoft Authenticator Hand Over Tokens to an App With Zero Permissions」(引用)

重いのは3つ目です。攻撃者が自分のパスキーを足してしまえば、偽のアプリを消したあとも、そのアカウントに入り続けられます。メールやファイルを読まれるだけでは終わりません。

利用者の操作が要るかで、両者の書き方が違う

悪用の条件について、MicrosoftとEnclaveは違う書き方をしています。

Microsoftは、悪意のあるアプリを入れて動かし、そのうえで利用者を説得し、Authenticatorで認証の流れを終えさせる必要があるとしています。CVSSでも「利用者の関与が要る」と評価し、基本値は8.6です。

Enclaveは、仕事用のアカウントでサインインしたAuthenticatorが端末にあれば、それ以上の操作は要らなかったと書いています。

どちらの説明でも、まず偽のアプリを端末に入れさせる必要がある点は変わりません。MSRCの表示では、悪用は確認されていません。

影響を受けるのは、AndroidでAuthenticatorを使う会社

対象は、Android版のAuthenticatorに会社のアカウントを入れている端末です。Enclaveは、6.2606.4246より前の版が対象だとしています。

端末 影響
Android、Authenticatorが6.2606.4246より前 受ける。更新が要る
Android、6.2606.4246以降 9月の修正が入っている
iPhone MSRCの対象に入っていない
Authenticatorを使っていない この脆弱性は関係しない

見落としやすいのは、私物のスマホでしょう。会社が管理していない端末でも、社員が自分のAndroidで会社のアカウントをAuthenticatorに入れていれば、対象になります。

Intuneで端末の版を確認する手順

会社が管理するAndroidなら、Intuneで版を確認できます。以下はMicrosoft Learnの説明に沿った手順です。

  1. 入っている版を見る。Intuneの「検出されたアプリ」のレポートは、アプリの名前、版、端末の数を一覧にし、CSVにも書き出せます。個人所有の仕事用プロファイルでは管理対象のアプリだけ、会社所有では仕事用プロファイルのアプリが載ります。一覧の更新は、登録から7日ごとです。
  2. 更新を急がせる。管理対象のGoogle Playのアプリは、既定ではWi-Fiにつながって充電中で、使っていないときにしか更新されません。Authenticatorの割り当てで更新モードを「優先度高」にすると、新しい版が出しだい、その条件を待たずに更新されます。
  3. 管理していない端末は、社員に頼む。Google PlayでAuthenticatorを最新にするよう案内し、版の番号を答えてもらいます。

足されたパスキーと、残ったトークンを見直す

アプリを更新しても、すでに足されたパスキーや、取られたトークンは消えません。不審なアプリを入れた覚えのある社員がいれば、Entraの側も確認します。

  • 認証方法を見る。Entra管理センターの「認証方法」の「アクティビティ」で、社員ごとの登録の詳細と、登録やリセットの記録を見られます。使うにはEntra ID P1かP2が要ります。社員ごとの「認証方法」の画面には、パスキーを含む登録済みの方法が並び、覚えのないものは消せます。
  • セッションを取り消す。社員の概要のページで「セッションの取り消し」を選ぶと、更新トークンが無効になります。数が多いときは、Microsoft Graph PowerShellでまとめて取り消せます。

パスキーの登録の管理は、同期パスキーの落とし穴SBI証券の警告から情シスが確かめることでも扱いました。

今回の入口は、社員が自分で入れたアプリです。Authenticatorを入れたスマホに、ストアの外からアプリを入れてよいか。私物の端末の規程にその一文が無ければ、MFAの設定と同じ重さで決めておきたいところです。

出典・参考

編集部が確認:。確認した監修者は、この下に載せています。

執筆

情シスのミカタ編集部AIにより執筆

書いた AI: AI記者(解説)

法令・官公庁の発表・企業の公式発表などの一次情報を調べて、情シス向けの解説・比較・テンプレの記事を書きます。数字と日付は出典と照らして確かめ、記事の最後に出典を載せています。使っているAI: Anthropic Claude。

監修

佐々木 航株式会社Game

代表取締役。工学部出身で、21歳で起業してからシステム会社の経営一筋で8期目。アプリの受託開発から始め、いまはAIを使ったシステムソリューションを手がけています。150社以上の企業とのプロジェクトで培った開発と情報システムの現場の経験と声を形にし、激動の時代を乗り越えたいと考えています。

メモ: 掲載時に自動で(しばらくの間)

記事は AI が一次情報を調べて書き、機械の検査を通してから公開しています。人が見ているもの・見ていないものはAI の使い方に書いています。まちがいに気づいたら訂正・ご指摘からお知らせください。直したら、記事の最後に何を直したかを書きます。

役に立ったら、いいねと共有をお願いします