23 million 人。22.5 million 条记录。再加 11 million 条。
这就是 ShopServe、Sourcenext 和 Burger King Japan——日本企业近几周披露的其中三起泄露事件。
它们并不是仅有的几起。
10 月 9 日，日本国会议员召开会议，讨论席卷全国企业的数据泄露事件。自民党网络安全小组负责人 Masaaki Taira称当前局势为紧急状态。他呼吁举全国之力应对，由政府与公众共同行动。
政府当天给出的建议很简单：尽快修复 Web 漏洞，检查您的供应商，并关注谁在访问您最重要的数据。
一周后，日本国家事件响应团队 JPCERT/CC 披露了攻击者的作案手法。他们利用 AI 搜寻已知弱点并攻击 API，甚至研究移动应用的代码，以找到更多可攻击的 API。
本期将从头到尾追踪这个故事。
本期内容
🌡️ 威胁等级：高度警戒
⚡ 新闻栏目报道其中三起泄露事件：Sourcenext、Burger King Japan 和 Studio。
🔎 深度解析带您深入 ShopServe：多年前就已离开该平台的店铺，依然受到了这次泄露的影响。
🎣 这是钓鱼吗？
🔬 技术研究：Metabase 的密码重置如何让攻击者获得管理员权限（CVE-2026-72898）
🛠️ 本周工具是 Blutter，JPCERT 在攻击者的工具包中发现了它。用它看看您自己的应用暴露了哪些信息。
👏 本周人物是 Loren Kohnfelder，Designing Secure Software 一书的作者
📅 本周活动是 11 月 17–18 日在东京举办的 CODE BLUE，JPCERT/CC 的 CTO Shusei Tomonaga 将在会上发表演讲。
📚 本周书籍是 Designing Secure Software，讲述如何设计出即使攻击者完全清楚其工作原理也依然安全的应用。
😅 本周梗图
❓ 离开前的一个问题
让我们开始吧。
🌡️ 威胁等级
⚡ 新闻
攻击者滥用 Sourcenext 的会员 API，使 22.5 million 条记录面临风险
Sourcenext 是一家面向消费者销售应用和 PC 软件的日本软件公司。
10 月 9 日至 13 日，攻击者滥用了 Sourcenext 用于查询会员信息的 API。该公司列出了 22,519,960 条记录可能受到影响。
视客户而定，这些记录可能包括电子邮件地址、密码、姓名、地址、电话号码、出生日期和账户信息。受影响的系统中并未存储银行卡信息。
为什么重要：泄露的数据可能包括客户的密码。这才是值得担心的部分。
大多数人会在不止一个地方使用同一个密码。因此，拿到您的电子邮件地址和 Sourcenext 密码后，攻击者就可以尝试登录您的邮箱、购物账户，甚至您的工作账户。如果您重复使用了这个密码，他们就能登录进去。
这就是为什么 Sourcenext 的公告要求客户在所有使用过该密码的其他地方更改密码。
Burger King Japan 的应用泄露了约 11 million 条会员记录
10 月 2 日至 7 日，攻击者侵入了管理 Burger King Japan 应用会员的系统。该公司确认约 11.18 million 条记录遭到泄露：包括姓名、联系方式、出生日期和会员信息。
该系统中没有保存银行卡号，目前也没有迹象表明密码遭到泄露。攻击者如何侵入仍在调查中。
为什么重要：没有泄露银行卡号，所以很容易认为这次事件无害。其实不然。
有了姓名、电话号码和出生日期，诈骗者就可以冒充 Burger King 给您发消息。因为它掌握了您的真实信息，看起来就像真的一样。您点开链接，一个虚假页面就会要求您输入密码或银行卡号。
这就是为什么 Burger King 提醒客户警惕可疑的电子邮件、短信和电话。
Studio 的数据经过了加密，但攻击者连密钥也拿到了。
日本网站搭建平台 Studio 中的一个漏洞让攻击者进入了其云环境。所有注册客户都可能受到影响。
可能遭到泄露的内容包括：账户信息、网站内容、表单回复，以及客户用来将 Studio 连接到其他服务的 API 密钥。Studio 尚未确认数据是否被下载，但正按照数据已被下载的情况进行应对。
为什么重要：Studio 这起事件值得仔细研读，因为三件通常让人觉得安全的事都没能守住：
已加密。部分数据经过了加密，但攻击者也拿到了用于解密的密钥。
已删除。留在回收站中的表单回复也可能遭到泄露。只有在 9 月 30 日之前被永久删除的回复不在其列。
已修复。给 Studio 打上补丁并不意味着事情结束。客户不得不自行更换部分用于连接其他服务的密钥。
网站搭建平台承载的不只是网站。它还掌握着这些网站所连接的一切服务的钥匙。
🔎 深度解析
ShopServe 的泄露事件暴露了早已离开该平台的店铺的客户
2022 年 8 月，日本文具公司 King Jim 将其主要网店迁出了 ShopServe。
四年后，它却在为 ShopServe 的一起泄露事件向客户道歉。
它是卷入这次泄露的 7,858 家现有和曾经入驻的店铺之一，这次泄露影响了约 23.36 million 人。
King Jim 早已不再使用 ShopServe。但当年在其店铺购物的顾客记录仍留在那里。ShopServe 遭到入侵时，这些记录也随之暴露。
因此，本期深度解析要问一个简单的问题：当您离开一个平台时，您留下的客户数据会怎样？
ShopServe 发生了什么
ShopServe 是由日本公司 E Store 运营的网店平台。数以千计的企业曾使用它在线销售商品。
2026 年 5 月 21 日至 8 月 1 日，攻击者利用其某个应用程序中的一个缺陷运行自己的程序，并将其数据库中的信息传出系统。E Store 尚未说明这个缺陷是什么。
E Store 于 10 月 16 日发布了最终报告。共有约 23.36 million 人受到影响，涉及 7,858 家现有和曾经入驻的店铺。其中约 2.1 million 人的部分银行卡信息遭到泄露，但不包括完整卡号或安全码。
攻击者拿到的不只是购物者的数据。他们还获取了店铺用于管理网店的登录凭据，以及 E Store 联盟计划的登录凭据。
请注意“现有和曾经入驻”这几个字。其中一些店铺早在很久以前就离开了 ShopServe，却仍然受到了这次泄露的影响。
两家已将主要网店迁出 ShopServe 却依然遭到泄露的店铺
文具店 King Jim 四年前就已离开。
King Jim 在 9 月 4 日的公告中确认，其过往客户的信息遭到泄露。其当前的网店未受影响。
而且受影响的不只是旧店铺。公告还涉及 Office Online——King Jim 旗下另一家早已关闭的店铺。那家店铺已经不复存在，但其客户的数据仍在这次泄露范围之内。
接下来是最棘手的部分。King Jim 表示，它无法核实任何一位客户是否受到影响，因为它没有进行核实所需的信息。它只能让客户带着疑问去找 E Store。
于是，King Jim 为一个它早已离开的平台上发生的泄露道歉，却仍然无法回答自己客户的问题。
PFU 的记录可以追溯到 2008 年。
PFU 是理光（Ricoh）集团旗下生产扫描仪的公司，于 2025 年 10 月将其主要店铺迁出 ShopServe。部分独立的销售页面则一直留在该平台上，直到 2026 年 9 月。
面临风险的记录可以追溯到 2008 年 12 月：多达 169,355 笔订单。
引人注目的是，PFU 花了多长时间才发现自己的客户也牵涉其中：
8 月 2 日：PFU 获悉此次泄露。
9 月 8 日：PFU 向 E Store 询问，得知其主要店铺的过往客户可能受到影响。
9 月 17 日：PFU 获得确认，其过往客户的数据确实受到影响。
9 月 18 日：PFU 发布道歉声明。
从获悉泄露到得知自己的客户也在其中，相隔了六周多。
店铺仍然要对自己的客户负责
泄露发生在 ShopServe。但给客户写信、道歉并回答问题的，却是 King Jim 和 PFU。
客户就是这样看待这件事的。他们不是在 E Store 购物，而是在 King Jim 或 PFU 购物。当他们的数据泄露时，他们看的是自己熟悉的那个名字。
离开平台并没有改变这一点，因为旧数据仍然留在那里。没有人说明为什么要保留这些数据，也没有人说明是否有人要求删除它们。
在 7,858 家店铺中，我们只读了这两家的公告。但任何一家离开了 ShopServe、旧客户数据却留在原处的店铺，都可能处于同样的境地。
离开供应商时该怎么做
以书面形式要求删除。迁出平台时，要求供应商删除您的客户数据，并确认删除已完成。
了解对方仍保留哪些数据。如果对方必须保留部分记录，弄清楚是哪些记录、保留多久。
约定对方遭到入侵时如何处理。对方应当尽快通知您，并告诉您哪些客户受到了影响，这样您就不必等上六周才知道。
更换平台是一步。让对方删除您客户的数据是另一步，而且很容易被遗忘。
来源： E Store 最终报告 · King Jim 公告 · PFU 公告
🎣 这是钓鱼吗？
一封来自“ShopServe Customer Support”的电子邮件称，您的信息在 ShopServe 泄露事件中遭到泄露。
它知道您的姓名、您以前的收货地址以及银行卡号的后四位。为了让您查看哪些信息遭到泄露，它要求您登录一个事件审查门户。
请仔细查看这条消息，以及按钮指向的地址。
这是钓鱼吗？
🔬 技术研究
Metabase 的密码重置如何让攻击者获得管理员权限（CVE-2026-72898）
任何人都可以使用密码重置页面。这正是它的意义所在：如果您忘记了密码，就没法先登录。
因此，该页面应当只要求两样东西——邮件中的重置令牌和一个新密码，并忽略您发送的其他任何内容。
Metabase 的重置页面并没有忽略其他内容。如果攻击者多发送一个字段，Metabase 就会把它直接放进数据库查询中。而且它在检查重置令牌是否有效之前就这样做了。
这就是 CVE-2026-72898，一个无需登录即可利用的 SQL 注入漏洞。它影响 Metabase——许多公司用来在数据仓库之上构建仪表板的开源工具。
它的评分为 CVSS 10.0。在修复发布之前，攻击者就已经在利用它：先是针对 Metabase 自己的云服务，然后针对世界各地在自有服务器上运行 Metabase 的公司。
它与本期主题紧密相关。JPCERT/CC 于 8 月 14 日针对这一漏洞发布了一份专门警报。10 月 8 日，它将 Metabase 攻击列为近期日本机构泄露潮背后的手法之一。
JPCERT 没有公布日本受害者的名称或数量，也没有任何公开信息将这一漏洞与我们深度解析中的 ShopServe 泄露事件联系起来。但它确实表明，一个可从互联网访问的内部工具，可以将攻击者引向其背后的客户数据。
Metabase 是什么，攻击者为何盯上它
Metabase 让整个公司的人员无需编写 SQL 就能构建仪表板和运行查询。为此，它会连接公司真实的数据库（PostgreSQL、MySQL、Snowflake、BigQuery、Redshift 等），并存储这些连接的凭据。
因此，从设计上看，它是这样一个系统：
持有公司最重要数据库的有效凭据。
可以查询并导出所有这些数据库中的数据。
通常由数据团队而非安全团队部署，有时为了方便人们随时随地使用，还会被设置为可从互联网访问。
Metabase 将其自身状态（用户、会话、API 密钥、设置以及上述连接信息）保存在一个内部的应用数据库中。这次注入攻击落在的正是这个内部数据库。
漏洞所在：重置端点接受了多余的字段
Metabase 的重置端点 POST /api/session/reset_password 声明了它所期望的两个字段：
request-body :- [:map
[:token ms/NonBlankString]
[:password ms/ValidPassword]]该模式会检查 token 和 password 是否存在且有效，但不会拒绝其他字段。
Metabase 使用的模式库 Malli 默认将 map 视为开放的，因此 JSON 请求体中的任何额外键都能通过验证，并与 token 和 password 一起被交给共享的登录代码。
该登录代码的开头如下（摘自 0.58.22 版本中的 auth_identity/provider.clj）：
(merge request (authenticate provider request))
...
(when-let [user-id (:user-id $)]
(t2/select-one [:model/User ...] :id user-id))它将请求与身份验证结果合并，然后通过 :user-id 查找用户。
身份验证成功时，结果中包含真实的 :user-id，并会覆盖请求中的任何值。
而当身份验证失败时（例如因为重置令牌无效），结果中没有 :user-id。Clojure 的 merge 只会覆盖两个 map 中都存在的键，因此攻击者提供的 user-id 会在合并后保留下来，随后代码便用它来查找用户。
这是第一个问题：即使身份验证已经失败，查找操作仍然会执行。
多余的字段如何变成 SQL 注入
单凭一个保留下来的 user-id，攻击者只能选择代码要获取哪条用户记录。真正让它变成 SQL 注入的，是 Metabase 构建查询的方式。
Metabase 使用 HoneySQL，这是一个用 Clojure 数据结构构建 SQL 的库。通常，值会作为参数发送，这正是查询保持安全的原因。但 HoneySQL 还支持一种 :raw 形式，其内容会不经参数化直接进入 SQL 文本。正如 Wiz 的分析所解释的，作为 user-id 发送的 JSON 对象会以 Clojure map 的形式到达，如果该 map 带有 raw 键，HoneySQL 就会将其视为一条指令，把字符串原样插入查询中。
综合起来：
攻击者发送一个重置请求，其中包含任意令牌、一个看似有效的密码，以及一个包含原始 SQL 片段的额外 user-id 字段。
验证通过，因为模式只检查它所声明的字段。
令牌检查失败，因此身份验证结果中没有可以覆盖攻击者所提供值的 user-id。
用户查找操作用攻击者的片段构建其 WHERE id = ... 子句，并在应用数据库上执行。
请求以 400 “Invalid reset token” 错误失败，但此时注入的 SQL 已经在应用数据库上执行了。
我们在这里解释的是漏洞本身，而不是提供可用的漏洞利用代码。确切的载荷取决于 Metabase 后端使用的是哪种数据库（H2、PostgreSQL、MySQL 或 MariaDB），而公开的概念验证代码自 8 月 10 日起就已经可以获取。
攻击者能得到什么：管理员权限以及所有已连接的数据库
注入针对的是 Metabase 的内部存储，而不是直接针对客户的数据。但由于内部存储中保存的内容，这仍然能让攻击者获得很多东西。厂商安全公告的标题是 “SQL injection using an unauthenticated endpoint leading to admin access”（通过未经身份验证的端点实现 SQL 注入并获取管理员权限），而 Bishop Fox 列出了由此带来的后果：
获得 Metabase 的完全管理员权限。
更改应用设置，并读取运行中的应用可获取的密钥。
以 Metabase 的权限，从Metabase 连接的每一个数据库中查询并导出数据。
这就是 CVSS 向量将作用域标记为“已改变”的原因。漏洞存在于 Metabase 中，但其破坏会波及它能查询的每一个数据库。
真实事件证实了这一点。Metabase 确认了该漏洞正遭到积极利用，CISA 于 8 月 11 日将该漏洞加入其已知被利用漏洞（KEV）目录，Framework、Tally、n8n 和 ChecklyHQ 等公司也披露了客户数据曾通过其 Metabase 实例遭到访问。
报告的数据包括姓名、电子邮件地址、电话号码、账单地址、密码哈希和 API 令牌。
Metabase 如何修复该漏洞
修复已在 0.58.24、0.59.21、0.60.17、0.61.11、0.62.9 和 0.63.5 中发布，并有对应的 Enterprise 1.x 版本。58 至 63 版本线中早于上述版本的自托管 Metabase 均受影响，而 Metabase Cloud 在公开安全公告之前就已打上补丁。
查看 Metabase 当前源代码中的重置和登录代码可以发现，这个问题现在不是在一处而是在多处被封堵：
端点模式已封闭。现在它是 [:map {:closed true} ...]，因此包含未声明字段的请求会被拒绝。
只传递预期的字段。处理程序调用 select-keys，只转发 :token 和 :password，不转发其他任何内容。
请求数据无法提供身份字段。在合并之前，登录代码会从请求中移除所有本应由身份验证设置的键，例如 :user-id、:user 和 :success?。
不成功就不查找。只有在身份验证确实成功、且 user-id 为正整数时，才会解析用户。其他任何情况都会被记录并拒绝。
其中任何一项都足以阻止这次漏洞利用。四项同时具备，意味着未来某一层出现失误时，更不容易演变成另一个 CVE。
如果您在运行 Metabase，需要检查什么
打补丁回答的是“我是否仍然存在漏洞？”，却回答不了“我是否已经被入侵？”
如果 /api/session/reset_password 在受影响版本上可从互联网访问，厂商和 JPCERT 都建议将该实例视为可能已被入侵：
查找漏洞利用模式。一个返回 400 的 POST /api/session/reset_password，紧接着一个返回 200 的 GET /api/user/current。JPCERT 表示，这一序列强烈表明系统已被入侵。Wiz 补充说，合法的重置请求只包含 token 和 password，因此任何带有 user-id 键的请求体都值得怀疑。
检查 JPCERT 公布的指标。2026 年 8 月上旬至 9 月上旬期间来自 213.163.202[.]171、221.216.140[.]49 或 221.216.140[.]129 的请求，或用户代理为 python-requests/2.33.1 或 Metabase-GHSA-vwf4/2.0 的请求。JPCERT 指出，这些 IP 现在可能已被合法使用。
吊销并轮换。删除 core_session 表中的所有行以结束每一个会话，移除无人认识的 API 密钥，审查管理员账户，并轮换每一个已连接数据库的凭据。
审查数据层面。检查 Metabase 的活动和查询历史以及您的数据仓库日志，查找团队中无人执行过的查询或导出。
如果您无法立即升级，请在反向代理或防火墙上屏蔽 /api/session/reset_password。
给开发人员的经验教训
验证您收到的内容，而不只是您期望的内容。一个只检查必填字段却接受多余字段的模式，就是一个有漏洞的过滤器。在未经身份验证的端点上，应拒绝未声明的字段，或只传递您需要的字段。
不要让请求数据与可信数据共享同一个命名空间。将用户输入合并到同时保存身份验证结果的 map 中，意味着一侧缺失的键会变成另一侧的攻击者输入。请将两者分开，或者先从输入中剥离可信键。
失败路径需要与成功路径同样的重视。这次查找是在身份验证已经失败之后执行的。在错误路径上运行的代码，仍然可以被任何能触发该错误的人访问，而在重置端点上，这意味着所有人。
使用查询构建器时，您仍需知道逃生口在哪里。HoneySQL 默认会对值进行参数化，但其 :raw 形式不会。如果不可信数据能够以结构而非标量的形式到达查询构建器，请检查该结构能否表达原始 SQL。
内部工具一旦面向互联网，就要按面向互联网的标准对待。JPCERT 10 月的警报特别点名了 BI 工具和员工系统：要用与面向公众的应用相同的措施检查它们。一个存储着数据仓库凭据的仪表板工具，是攻击者所能触及的最有价值的系统之一。
🛠️ 本周工具：Blutter
在其调查的一台服务器上，JPCERT/CC 发现了 Android 应用文件，以及与两款逆向工程工具相关的文件：JADX 反编译器和 Blutter。
攻击者对应用进行逆向工程，找出其背后的 API，然后测试这些 API 是否存在弱点。
Blutter 是专为 Flutter 应用打造的那一款。
Blutter 能做什么
像 JADX 这样的反编译器在面对 Flutter 应用时作用有限，因为 Dart 代码被编译成了 libapp.so 中的原生机器码。Blutter 正是为逆向这个文件而打造的。它可以为您提供：
带有恢复出的函数名的应用汇编代码。
应用 Dart 对象的转储，服务器地址和硬编码密钥会出现在其中。
一个用于在运行时 Hook 应用的 Frida 脚本模板。
如何在您自己的应用上使用 Blutter
在您自己的应用或您获得授权测试的应用上运行它。在提取出的对象中查找服务器地址和硬编码密钥，并检查每个密钥能访问什么。
局限性
仅支持 Android ARM64 和较新的 Dart 版本。iOS 支持尚未完成，对经过代码混淆的应用也未完全支持。
它不是一个完整的反编译器。您得到的是汇编代码和对象，而不是源代码。
安装需要构建工具，而且可能需要先编译对应版本的 Dart 运行时。
要点
有了这样的工具，任何下载了您应用的人都能弄清它是如何与您的服务器通信的。把 API 藏在应用里并不能保护它。
真正能保护它的，是服务器在每一个请求上检查是谁在请求、以及对方被允许看到什么。
👏 本周人物：Loren Kohnfelder
1978 年，Loren Kohnfelder 在 MIT 完成了他的本科毕业论文 Towards a Practical Public-key Cryptosystem。这篇论文提出了数字证书：一种将公钥与名称绑定在一起的签名记录。如今支撑 HTTPS 的证书正是建立在这一理念之上。
在 Microsoft，他与 Praerit Garg 共同创建了 STRIDE，这是梳理系统所面临威胁时使用最广泛的方法之一。他还领导了 .NET 平台的安全工作。在 Google，他供职于安全团队，参与创建了隐私团队，并审查了大型系统的安全设计。
如今他已退休，并将这些经验写进了本期的本周书籍。
感谢他四十多年来致力于让系统从设计上就安全，Loren Kohnfelder 当选本周人物。
📅 本周活动
CODE BLUE 2026
CODE BLUE 是在东京举办的国际安全会议。来自日本、亚洲其他地区、欧洲和美国的研究人员会在会上展示他们的最新成果，此外还有研讨会、竞赛以及一个面向 25 岁以下演讲者的专场。
在一期关于日本泄露潮的内容之后，它自然是下一站。大多数演讲都提供日英同声传译，因此您不需要会说日语也能跟上。
其中一场演讲与本期主题紧密契合。JPCERT/CC 的 CTO Shusei Tomonaga 和 Yuki Yano（来自其事件响应组）将带来演讲 Quality Assurance for Incident Response in the Age of AI。
泄露发生后，会有人撰写调查报告。但您如何知道这份报告真的能支撑其结论？
在演讲中，他们将介绍 JPCERT/CC 如何与 13 家日本事件响应服务商、CSIRT 和 SOC 团队合作，编写了两份检查清单和一份示例报告，然后构建了一个依据这些材料审查报告的 LLM 智能体。
📍 日本东京 Bellesalle Takadanobaba 📅 2026 年 11 月 17–18 日
📚 本周书籍
Designing Secure Software
本期反复回到同一个事实：攻击者会弄清您的系统是如何运作的。JPCERT 发现攻击者通过解读移动应用来摸清其背后的 API。
Designing Secure Software: A Guide for Developers 的作者是本周人物 Loren Kohnfelder，这本书正是从这一假设出发。它讲的是把安全融入系统设计之中，而不是在最后才添加。
书中的一种模式是 Transparent Design（透明设计）：即使攻击者完全清楚系统的工作原理，系统也应保持安全。这并不意味着公开密码或密钥，它们仍然要保密。它的意思是，设计本身不应依赖于被隐藏。
😅 本周梗图
如果您以前的某个供应商明天遭到入侵，您需要多长时间才能弄清自己的客户是否受到影响？
The Breach Brief，
Ostorlab 团队