2026 年 8 月，AmIBeingPwned 团队披露 N-able Passportal 浏览器扩展（Chrome / Microsoft Edge）存在高危消息来源验证漏洞，编号 CVE-2026-15580，CVSS v4.0 基础评分 9.4。N-able 在收到完整报告后 24 小时内发布版本 3.49.6 修复该缺陷。Passportal 是面向 MSP 与内部 IT 部门的特权访问与密码管理平台，每周活跃浏览器扩展用户约 7.3 万人；该漏洞使任何一个用户访问的恶意网站或注入的第三方 iframe 即可取走整个组织的密码保险库与二步验证码。
事件概述
Passportal 浏览器扩展采用 window.postMessage 作为内容脚本与扩展 iframe 之间的进程间通信机制，但其消息处理器未对 origin 做严格校验。任何与扩展已登录用户接触的网页（例如访问的网站、嵌入广告中的 iframe、第三方追踪脚本）都可构造伪造 postMessage 请求，扩展会把可用身份令牌直接回复给伪造源。攻击者得到令牌后可以枚举保险库条目、请求解密密码、抓取实时 TOTP 二步验证码，并通过 refresh token 维持 100 天以内的持久会话。AmIBeingPwned 同时指出 Passportal 架构为”服务端解密 + 返回明文”，与零信任密码学惯例相悖，扩大了风险敞口。
技术细节
CVE-2026-15580 触发链：
- 扩展内容脚本调用 window.postMessage 与扩展 iframe 通信；
- 扩展端消息处理器未校验 event.origin、未校验消息签名、未引入一次性 nonce；
- 恶意网站/JavaScript 主动 postMessage 至目标扩展并请求解密的口令/TOTP；
- 扩展在已经登录的情况下，将令牌与明文数据直接返回给攻击者控制的 origin；
- Passportal 返回的访问令牌为 JWT，包含密钥相关材料，未单独加密（JWT 默认仅保证完整性不保证机密性），因此泄漏即等同于会话密钥泄漏。
具备适当权限的攻击者获取令牌后可执行：
- 遍历 Passportal 全部密码条目（含客户系统、远程服务器、VPN、内部 SaaS 应用）；
- 实时拉取任意条目的 TOTP 6 位验证码，借此登录需要 2FA 的内部系统、邮箱、远程跳板；
- 在 100 天内借助 refresh token 维持对 Passportal API 的访问，不需要再次经过浏览器即可扩展攻击半径；
- 对 MSP 客户而言，这意味着扩展单一受害者即可渗透其全部客户系统的远程管理路径。
影响评估
CVSS v4.0 评分维度：
- AV:N（网络），AC:L（低复杂度），PR:N（无需权限），UI:P（需要用户行为-访问恶意页面），S:U（未变更），C:H/I:H/A:H → 9.4；
- 实际利用条件（用户已安装扩展并已登录）是大多数真实环境中的常态：MSP 工程师为完成运维任务几乎全天保持扩展登录。
- 威胁利用门槛：构造一条恶意页面或一段被投毒广告触发即可，符合供应链式水坑攻击与 SEO 投毒组合的标准路径。
Passportal 客户中超过半数为 MSP 服务商，下游客户往往涉及税务、医疗、法律等高合规要求的系统，单点扩展失陷可引发跨多家被服务企业的连锁入侵。
修复与缓解
官方修复（N-able Passportal 3.49.6）：
- 对所有 postMessage 调用引入严格的 origin 校验与扩展自校验；
- 对 iframe 来源增加可信域白名单校验；
- 在消息处理路径中要求一次性 nonce；
- 统一审计扩展消息通道，移除直接 window.postMessage 暴露。
管理员侧的执行步骤：
- 立即盘点所有 Chrome / Edge / Firefox 实例的 Passportal 扩展版本，强制全部升级到 3.49.6 或以上，并对未升级客户端执行 MDM 推送；
- 对所有高层级客户系统、VPN、域名注册商、邮件平台、AWS/Azure 控制台、3PAO、PCI 范围内的口令条目强制轮换；
- 对所有 TOTP seed 进行强制重置与重新注册，废除 100 天内的 refresh token；
- 开启 24-72 小时密集观察：SIEM 检测 Passportal API 大规模枚举、TOTP 拉取频次异常、refresh token 离线调用；
- 企业 IT 层面把浏览器扩展治理纳入企业浏览器管理策略，对关键岗位员工规定”仅启用 MDM 审批通过的扩展”。
架构层启示
AmIBeingPwned 在公开报告中指出，Passportal 的”服务端解密 + 返回明文”架构本身就是长期风险。即使 CVE-2026-15580 被修补，攻击者仍可在服务端解密路径上获得明文口令，企业用户应推动厂商向”客户端 E2EE 解密”模型迁移（如 1Password、Bitwarden 等已采用 PBKDF2+Argon2 在客户端派生密钥并完成解密）。同时建议把”扩展消息通道”作为浏览器扩展供应商安全审计的优先项，任何依赖 window.postMessage 且未做 origin/nonce 校验的扩展都应被纳入高风险评估。