Fnet 云网安 260929

️NSOC（网络·安全·云一体化运营中心）

7×24 主动监控与专家值守，网络可用性 99.99%，安全事件 百分百全 闭环，云资源一站式管理

今日热点 Top 5

S1 Cloudflare 容器与沙箱产品的共享存储池未做回收清零，付费客户可读出同一物理机上其他客户的残留数据

核心内容

9 月 27 日前后，安全媒体披露了 Cloudflare 容器产品线的一处跨租户数据残留缺陷，厂商随后在自家博客给出完整说明，并把它定性为一次越过租户隔离边界的数据披露。

问题的位置非常具体。

每个容器的可写根盘由瘦供给机制支撑，物理存储块只在真正写入时才分配，容器被删除之后这些块回到一个同时服务多个客户账号的共享池。

厂商的池采用六十四千字节的块，正常情况下底层会在把块交给新负载之前做一次清零，而这个配置项当时处在关闭状态。

研究者的做法是往新容器磁盘的空闲区域只写四千字节，这个动作会触发一个六十四千字节物理块的分配；
由于没有清零，那次写入只覆盖了四千字节，剩下六十千字节以上一个客户写入的内容原样可读。

发现者是 Accomplish 的研究员 Oren Yomtov，他于 9 月 4 日通过漏洞奖励平台提交。

实测数据说明了它的稳定程度：在二十四次容器放置里有十八次读到残留内容，覆盖参与测试的二十二台底层主机中的二十台；
在五千六百一十四个可测目录块里，两千七百个包含属于其他容器客户的目录索引节点。

读到的东西不是零散碎片，而是结构完整的产物，包括目录列表、SQLite 数据库、Chromium 浏览器配置目录、环境变量文件与凭据文件。

范围比容器本身更大。

厂商明确表示沙箱产品同样受影响，而这个产品正是这条产品线里被明确定位为执行不可信代码的那一层，AI 智能体代码执行、浏览器自动化与第三方插件都依赖它；
浏览器渲染服务也在范围内，三者共用同一套底层存储池配置。

时间线是：9 月 14 日重新开启新分配块的清零，9 月 19 日完成全集群清理，包括停用全部存量容器磁盘、清除可能仍指向旧数据映射的缓存快照，9 月 24 日公开披露。

厂商核查日志、遥测与历史数据后称，那种小规模写入后紧跟大额读取的特征模式只在研究者与获得授权的工程师身上出现过，没有发现被实际利用的证据，因此不需要客户采取任何动作，但组织可以依据自身风险口径考虑轮换相关凭据。

Cloudflare Containers跨租户隔离存储回收共享宿主机沙箱服务

为什么重要

• 计算隔离与存储清理是两道各自独立的控制，彼此不继承对方的保证：一台容器的计算可以用微虚拟机或语言运行时隔离做得很干净，但它的磁盘来自一个没有在租户之间清空的共享池。这两层只是被装在同一件产品里，就被默认当成了一件事，而这次证明它们不是。

• 特别值得警惕的恰恰是那条被当作隔离层的产品线：沙箱服务的核心价值就是安全地运行来自外部的代码，而缺陷就存在于提供隔离的那个产品里。把不可信工作负载交给第三方执行环境时，要验收的内容必须包括存储回收，而不只是计算层的隔离强度。

• 这个开关在关掉之后不产生任何可见差异：写进去、删掉、回收，每一步都正常返回结果，它只在下一个客户拿到同一块的时候才被读到。这类配置项写进模板之后没人回头复核，出问题之前也没有信号可以把这件事提示出来。

• 残留内容的形态比多数人预期的完整：不是零散字节，而是结构完整的数据库、凭据文件与浏览器配置目录。这意味着一旦这一层被跨越，对方拿到的往往不是无法使用的数据碎片，而是可以直接使用的凭据与业务数据。

• 「客户不需要采取任何动作」与「建议考虑轮换凭据」是同一份文档里的两句话：前者基于厂商对日志与遥测的核查结论，后者基于共享环境上的审慎原则。把两句放在一起读才是完整结论，只读前一句会得到一个比事实更强的保证。

顾问金句

它不是被突破了，它是从来没有被擦干净过。

建议企业做四件事。

首先，把共享宿主机这件事从抽象变成清单：梳理哪些业务跑在第三方容器、无服务器容器或按需执行的代码环境上，标注它们是否与其他客户共用物理宿主，以及是否处理访问密钥、会话令牌或个人信息，这一类是这次与事实直接对应的那部分暴露面。

其次，把「容器已销毁」和「磁盘已清空」拆成两个待验收项：在与供应商的对话里明确要求，回收存储块在交给下一位客户之前执行清零，并把这个要求写进合同条款与年度复核项，而不是默认它成立。

再者，按自己的口径而不是厂商的口径去定轮换范围：排查共享容器平台上曾经落过凭据、环境变量与数据库连接串的工作负载，对其中周期性任务与临时实例那一批做轮换，因为这一批既容易被遗忘，又经常在平台上反复重建。

而后，重排处置的顺序：不要把「供应商已修复」当作这条风险的终点，而是把它当作一次需要复核的起点，把共享执行环境的隔离假设写进自己的风险台账并指定复核责任人。

S2 Carbonato 僵尸集群攻陷未认证的 Docker 守护进程，把开源 AI 智能体框架改造成聊天工具控制面

核心内容

安全厂商 ThreatDown 披露了一个代号 Carbonato 的僵尸集群。

它的入口十分老派：瞄准暴露在 2375 端口且没有开启认证的 Docker 守护进程接口。

拿下主机之后拉起一个特权容器，在底层宿主机上执行命令，建立持久化与远程访问，然后以每五分钟一次的节奏扫描相邻网段寻找下一个同样敞开的守护进程，这让它在控制投递之外还拥有了类似蠕虫的自传播能力。

交付链路是一条 shell 脚本：先在受害者与一台位于 Costa Rica 的中继之间建立反向 SSH 隧道，再安装一个带操作者公钥的 SSH 服务，接着通过聊天工具 Telegram 把新一台主机的容器详情报告出去。

隐蔽手段包括伪装成系统组件，并把持久化挂在定时任务与守护脚本上，保证即使有人清掉了恶意构件，它也会被重新拉起。

真正的落点是 AI。

攻击者在每一台主机上安装开源智能体框架 Hermes Agent，安装过程不改动框架本身，只覆盖它的角色文件，写入一段三十九行的提示词，要求它扮演一名署名 GH0ST 的资深渗透与漏洞研究员，通过聊天工具接收任务、维持持久化、执行操作者提出的任何动作，并且不带任何限制。

角色文件里明确把 AI 接口密钥与其他凭据列为优先收集目标。

随后智能体进入一个交互循环：把聊天工具收到的自然语言任务转交给后端模型，由模型写出终端命令，再执行并把结果回传给聊天频道。

也就是说，攻击者的操作界面从命令行变成了一个聊天窗口，而这个窗口背后是一台能自己拼命令的机器。

语言、时区与基础设施线索都指向 Costa Rica，活动目前没有被归属到任何已知团伙。

同一套框架在此之前已被多次观察到以聊天工具作为指挥通道出现在其他行动中，另一种用法是不受约束的执行模式。

同期还出现了名为 CLOSEDQUORUM 的新植入体，它用轮询多个模型供应商的方式在失陷后自主决定下一步动作，且在平票时有固定的优先级顺序，把控制链路里连续人工指令这一步也省掉了。

CarbonatoHermes AgentDocker 2375AI 智能体武器化僵尸集群

为什么重要

• AI 智能体在这次攻击里占据的是控制层的位置，而不是辅助角色：它是那个接收自然语言任务、翻译成命令、执行并回传结果的位置。攻击形态从人操作工具变成了人下达意图，这意味着守方过去依赖的操作手法、命令习惯与值守节奏这些线索会同时变淡。

• 入口依旧是那个被反复提了很多年的问题，2375 端口上没有认证。过去占据这个位置的是挖矿程序，这一次换成了一个带模型的执行体，进门条件没有变。漫长的提醒也没有改变它的排名：不充分的服务暴露依旧是回报率居高的一类入口。

• 凭据收集被写进了角色定义而不是脚本逻辑：角色文件里把 AI 接口密钥排在优先位置，于是被攻陷的主机不只是一个计算资源，还是一个会主动去找云凭据与接口密钥的位置。拿到凭据之后的下一步通常发生在云侧，而不是这一台主机上。

• 持久化依赖恢复机制而不是隐藏：守护脚本的作用是保证恶意构件被删也会被重新拉起。这意味着只做清理的处置在下一次触发时会失效，处置必须同时覆盖入口、持久化钩子与已经记录下来的主机清单。

• 这件事的单位成本变了：同样的效果过去需要一个运营团队来维持，现在一个聊天通道加一段角色文件就够了。防御侧如果还是按发现样本、下发封禁的节奏走，追上的是样本，追不上的是交付方式的成本曲线。

顾问金句

它没有攻破什么，它只是省掉了中间那个人。

建议企业做四件事。

首先，把容器守护与管理接口的暴露当作一类独立资产来清点：扫描内网与云主机上所有对容器守护进程、容器管理面板与远程守护端口的监听，按可从互联网触达与仅内部可达分两档建台账，凡是无需暴露对外的，一律收回到内部访问路径上，这一件事对应的是本次事件里那个起决定作用的进门条件。

其次，把长期在线的构建机一并纳入管理：这类守护进程通常活在创建不息、退出缓慢的构建机上，常常既不在主机补丁表里，也不在终端资产表里，而它所使用的却是生产级别的算力与凭据。

再者，补一道针对异常出向与自恢复行为的观测：重点看主机上出现的反向远程访问隧道、非计划的定时任务与守护脚本，以及突然出现的容器创建动作，并把这些行为放在同一条时间线上看。

而后，把 AI 接口密钥当作一类生产凭据来治理：清点自研与第三方应用持有的模型接口密钥，标注可用范围与有效期，纳入定期轮换，并把它从环境变量这种随手可写的地方挪出去。

A3 Apple 修复 CoreGraphics 越界写入 CVE-2026-86950，称可能已在针对特定个人的攻击中被利用

核心内容

9 月 28 日，Apple 发布安全更新修复一处位于 CoreGraphics 组件的越界写入缺陷，编号 CVE-2026-86950。

厂商的描述是，处理一个被恶意构造的文件可能导致任意代码执行，修复方式是加强边界检查，致谢对象为 Meta Product Security。

真正引起注意的是它附带的那一句：Apple 已注意到一份报告，称此问题可能已在针对特定个人的极其复杂的攻击中被利用，发生在 iOS 27 之前的版本上。

厂商没有说明被针对的人数、是否有尝试成功，也没有给出首次发生的时间。

修复落在三条分支上：iOS 26.7.1 与 iPadOS 26.7.1，覆盖 iPhone 11 及之后、iPad Pro 12.9 英寸第三代及之后、iPad Pro 11 英寸初代及之后、iPad Air 第三代及之后、iPad 第八代及之后以及 iPad mini 第五代及之后；
macOS Tahoe 26.7.1；
macOS Sequoia 15.8.1。

同一天发布的 iOS 27.0.1 与 iPadOS 27.0.1 并未列出这个编号，也就是说已经升到新大版本的设备不在受影响范围内，而这次补丁真正服务的对象是留在旧分支上的那批设备。

这里有一个容易被混淆的点：同日的两个更新在做不同的事，27.0.1 处理的是特定机型上的脸部识别重启问题，与这个编号无关。

美国网络安全和基础设施安全局给出的通用漏洞评分体系基准分是 8.8。

前情也值得对照：今年 2 月，Apple 修复过一处位于动态链接器的数据损坏缺陷 CVE-2026-20700，评分 7.8，当时同样用了被武器化于复杂攻击的措辞。

两次的共同之处除了厂商措辞，还有发现者的身份：都不是厂商自己的测试流程发现的，而是来自另一家公司专门做威胁发现的产品安全团队。

AppleCVE-2026-86950CoreGraphics定向攻击终端分支治理

为什么重要

• 多分支并存时，补丁的生效条件里多了一个变量：你在哪条分支上。这次修复只落在旧大版本的一条小分支与两条桌面分支上，而已经跨到新大版本的设备不需要它。用有没有补丁来做判断，会同时产生遗漏和误判。

• 范围表述先于细节：厂商没有给被针对人数、成功与否和首次时间，只给了一个框架性表述。这类措辞的信息量是被刻意收窄的，它通常意味着事态严重，但同时它也不足以支撑分母估算，处置时只能按后果已经发生的前提推进，而无法做精细分层。

• 发现者来自另一家大型技术公司的产品安全团队，而不是厂商自身的测试流程。出现在这种位置的缺陷，通常是在对真实设备的取证或对流窜线索的追查中被翻出来的，它本身就是一条关于这类攻击是否仍在手上的信号。

• 图形与渲染组件是近年被反复翻出的地方：它处理来自任意来源的图片与文档，许多时候不需要一个明确的二次确认就会完成解析。这条路径绕开了别点开可疑附件这类把判断交给人的建议。

• 移动与桌面终端正在成为企业数据出口的主干：邮件、即时消息、财税与视频会议都在上面跑，而笔记本承担着越来越多过去只在数据中心里进行的动作。终端分支合规在这个前提下的含义，已经从小版本追赶变成了一项需要有人负责的运营工作。

顾问金句

这次的难点不在补丁，而在判断谁需要它。

建议企业做四件事。

首先，把终端合规性从版本号改成分支画像：按设备型号、所在大版本、可升级的目标版本分三层建台账，标注哪些设备因为型号限制而无法继续升级，这些设备这一次能拿到修复，下一次未必，它们才是需要单独写方案的那一批。

其次，把处置的重心放在完整覆盖而不是等待结论上：面对信息量被刻意收窄的开局型披露，处置要坚持优先假设后果已经发生，而不是等待更多细节，因为厂商在这类表述下通常不会再补充数据。

再者，把这三条补丁分支与设备管理系统里的合规基线挂钩，明确升级截止时间、例外审批人和例外到期时间，避免把更新这件事长期停留在提醒用户自己去装这个环节上。

而后，对承担高敏感职责的账号补充一层设备侧的收敛：限制高风险岗位在移动设备上处理敏感文档的范围，并为其开放更严格的设备模式，把那一类不需要交互就能完成的解析路径尽可能收窄。

A4 JADEPUFFER 用两条失陷的服务主体在十八小时内完成破坏性云删除，凭据早在一份公开页面里

核心内容

微软发布了一份技术分析，把这件事称为该团伙手法的演进，并把它归在自己追踪为 Storm-3168 的名下。

攻击发生在今年 6 月上旬，整体跨度约十八小时。

攻击方的落点是两条同属一个租户的服务主体，也就是那种不属于某个具体的人、拿来完成自动化对接的非人类身份。

其中一条负责摸底，在接近十六小时里执行了三百多次读取操作，枚举 Azure 虚拟机、订阅、资源组与各类资源。

九十分钟后另一条服务主体加入，在五秒内枚举了两个订阅上的虚拟机与资源组。

到第十六个小时，它成功读取了 Azure 应用服务的配置存储，看起来是在寻找写在配置里没有保护好的凭据。

随后就是破坏：这一条服务主体在三十五分钟内执行了一百五十多次与破坏或凭据收集有关的动作，其中真正的核心序列只用了七分钟，包含一百多次存储账户删除尝试。

目标清单涵盖存储账户、SQL 数据库、密钥保管库、函数应用、虚拟机与应用服务托管计划。

数据库删除尝试全部失败，原因是攻击方调用了一个该资源类型不支持的接口版本。

多数被瞄准的存储账户被成功删除，但有少数被拦住了：资源锁与存储账户级别的删除保护发挥了作用。

微软的评价很直接，在一个失陷身份已经握有宽泛管理权限的情况下，这类独立保障措施依然有效。

凭据是怎么丢的更值得记录：这个服务主体的客户端标识、客户端密钥与租户标识，曾经以明文出现在受害组织一名员工发布的一份公开页面里。

密钥后来被删除了，但它仍然可以通过那份页面的公开编辑历史读出来。

意图判定偏向勒索，攻击方同时删掉了备份与恢复相关的资源，明显是为了削弱恢复能力，不过此次没有观察到勒索信，也没有观察到成功的数据外泄。

微软还提到，探测到与该团伙基础设施相关的多次重复行为，对多个客户的应用服务进行试探，考虑到多条服务主体之间的分工与操作时间间隔，这些动作很可能是自动化或脚本化完成的。

JADEPUFFERStorm-3168Azure 服务主体非人类身份破坏性删除

为什么重要

• 非人类身份正在成为云侧的主入口，而它的治理密度远低于人员账号：服务主体、托管身份与自动化对接凭据通常没有明确的归属人、没有定期轮换，也没有入离职这种天然的触发点，它的存活时间远远长于创建它的人在这个岗位上的时间。

• 删除不等于不可读：密钥从页面上被拿掉之后，仍然留在那份页面的公开编辑历史里。这个细节值得写进每一份研发规范，因为它不是罕见情形，而是版本记录对外可见部分的默认行为。

• 十六小时的摸底与七分钟的破坏之间是不成比例的，而前者几乎不产生告警：三百多次读取分布在十六小时里，粒度被拉得很细。按频次或阈值设计的检测在这一段默不作声，真正被看见的时候已经到了不可逆的那一段。

• 在这次实际起作用的防线与身份无关：资源锁与存储账户级别的删除保护不是访问控制，而是独立于身份之外的约束。这说明把防护全部压在身份与权限上的做法，在失去身份的那一刻就没有兜底了。

• 事件的目的是削弱恢复能力而不是索取赎金：攻击方同时瞄准了备份与恢复相关的资源，且没有留下勒索信。把恢复体系作为攻击目标这条路一旦走通，勒索这个步骤其实可以省略。

顾问金句

它不是猜出来的，它是被人写在纸上又被删掉了。

建议企业做四件事。

首先，把非人类身份从隐性资产变成有一项项属性的对象来管：清点全部服务主体、托管身份与自动化对接凭据，为每一条指定归属人、用途说明、到期时间与复核节奏，并注销掉那些已经联系不上归属人的条目。

其次，把脱敏标准从当前不可见提高到历史不可读：检查沉淀在代码仓库、协作平台公开页面与项目记录里的接口参数，凡是曾经出现过密钥的位置，即使已经删除也要按已泄露处理并立即轮换，同时把对外可见范围与页面历史的清理流程写成规范。

再者，在权限之外补一道与身份无关的物理约束：对关键存储、数据库与备份资源开启资源锁与删除保护，确认备份与恢复资源不在同一套凭据可及的范围内，因为这是本次事件里实际起作用的那道防线。

而后，把读的动作也纳入异常检测：为单个身份的查询行为建立基线，重点看短时间内跨订阅、跨资源组的大范围枚举，而不是只盯着写入与删除。

A5 两个被攻陷的工作流组件仓库重新上线，版本标签仍指向 5 月植入的恶意代码，下游流水线自动恢复执行

核心内容

第三方安全公司 Socket 披露，两个曾在 5 月遭到攻陷的自动化工作流组件被恢复公开访问，而指向恶意代码的版本标签并没有被清理，导致引用它们的企业流水线在没有经过任何变更的情况下重新执行了恶意内容。

两个组件是 actions-cool/issues-helper 与 actions-cool/maintain-one-comment，它们原先在 5 月 18 日那次代号为 Mini Shai-Hulud 的供应链行动中被攻陷，攻击方把前者五十三个版本标签、后者十五个版本标签重定向到了包含混淆载荷的提交。

平台在 5 月 19 日停用了两个仓库，下游流水线因此无法获取。

9 月 16 日，两个仓库重新可访问，但那些版本标签依旧解析到 5 月 18 日那次提交，也就是 index.js 里藏着混淆载荷的那一版。

于是任何以可变版本标签引用的流水线，在下一次触发时就自动下载并执行了那份代码。

Socket 在 9 月 25 日发现两个组件再次被停用，此时流水线会失败而不会再去下载载荷，暴露窗口从 9 月 16 日持续到 9 月 25 日，超过一周。

至于为什么在没有清理标签的情况下被恢复，原因尚不清楚，无从判断是来自仓库持有人的请求还是一次内部管理操作。

规模层面，平台公开的依赖关系图显示约有一万五千个仓库依赖 issues-helper，这不代表它们都执行了恶意代码，取决于引用方式；
但这两个组件通常用于议题与拉取请求的日常维护，触发极为频繁。

载荷的做法也值得一提：它先下载一个运行时环境，再扫描运行器进程的内存空间，那里正是流水线临时存放解密后密钥的地方，随后把数据发往攻击方控制的地点。

这个组织在 5 月那一轮影响了三百二十三个包、六百三十九个版本，8 月出现的一个高度变异的变种又覆盖了四百四十四个包，累计月度下载量达到二十亿量级。

处置建议也很具体：在工作流目录里检索这两个组件名，移除引用或把引用锁定到经过验证的干净提交；
复核 9 月 16 日以来的运行记录；
轮换那些流水线曾经可以访问的令牌与凭据，并复核自动化令牌的权限范围与仓库里出现的意外提交。

Mini Shai-HuludGitHub Actions可变版本标签CI/CD 供应链凭据外传

为什么重要

• 停用只切断了获取路径，没有改变被引用的内容：仅仅把可用性恢复这一个动作，就让一次已经平息四个月的攻击重新开始工作。攻击方在这一轮里没有部署任何新东西，也没有修改任何代码，生效的是一次状态变更。

• 版本标签是一个指针而不是指纹：写成 @v1 的引用随时可以被持有仓库写权限的人重定向到完全不同的代码，而消费方的工作流文件一个字都不用改。锁定到具体提交则相反，代码一变，指纹就变，工作流会失败而不是静默地跑未知代码。

• 这类组件的外表通常毫无攻击性：它们做议题整理与回复提醒这类日常事务，触发频繁、体积很小、几乎不被审查。正因为如此，它们能在 DevOps 这边长期保有高权限的上下文，包括一整套可以读取密文的自动化凭据。

• 外传发生在运行器进程的内存里而不是磁盘上：载荷读的是流水线运行时临时存放解密后密钥的那段空间，文件清理与镜像扫描都不会触及它。这让「我们扫过了、没问题」这一类结论在方法上就对不上对象。

• 问题的根源在于依赖是否安全是在执行时才被决定的：不是在下载时一次性确定，而是每一次运行那一刻重新确定。任何把审查固定在引入时点而不是运行时的机制，都拦不住一次标签重定向。

顾问金句

它不是重新被攻击了，它只是重新开门了。

建议企业做四件事。

首先，把可变引用在这一周内清零：在全量代码资产里检索外部工作流组件的引用，凡是用版本标签、分支名等可移动指针的，一律改为锁定到经过验证的具体提交，并把这条写进流水线模板与代码评审的检查项，让它成为默认值而不是要求。

其次，复核这一段时间内的运行记录而不是只看当前状态：拉取 9 月 16 日以来所有相关流水线的执行日志，检查是否有异常的运行时下载动作与意外的对外连接，因为真正发生过什么只写在运行记录里，不在当前的配置文件里。

再者，把自动化令牌当作生产凭据而不是零成本资源来治理：收窄自动化令牌的默认权限范围，按够用即可的范围放行，并为高价值仓库启用独立环境与另行审批的键值读取路径，同时轮换这一批流水线曾经能拿到的凭据。

而后，指定一个人负责已停用这类状态的后续：把第三方组件的下架、恢复与版本重定向做成一条需要人确认的事件流，而不是让它在平台侧悄无声息地完成。

趋势分析

本周期五条热点讲的是同一件事：收尾动作与它承诺的效果，不在同一个执行阶段完成。

Cloudflare 的容器存储池关掉了一个清零选项，容器被删除后六十四千字节的物理块回到一个服务多个客户的共享池，下一个客户写四千字节就能读出剩下六十千字节上一个客户留下的内容，而受影响的产品里有一个正是不用说明也必须做到干净的那个：专门用来跑不可信代码的沙箱服务。

Apple 给出了补丁，但补丁落在 iOS 26.7.1 与 macOS Sequoia 15.8.1 这几条分支上，已经升到 iOS 27 的设备不在范围内，于是「有没有补丁」这句话中间被塞进了一个新变量，你在哪条分支上。

Carbonato 钻的还是那扇没关的门，2375 端口上没有认证，只是这一次住进来的是一段把聊天工具当控制台的 AI 智能体。

JADEPUFFER 拿到的三个身份参数早就从公开页面上删掉了，只是它们还留在那份页面的公开编辑历史里。

两个曾经被攻陷的工作流组件仓库在 9 月 16 日恢复可用，版本标签仍指向 5 月植入的恶意提交，什么都没改，仅仅重新开放访问，依赖它的流水线就自己把那份代码跑了起来。

这五件事里没有一件是被新技术打穿的，它们全部坏在同一个地方：删除、下线、修复、关门这些动作在执行到一半就停了，而没有一个岗位负责回头验收。

这也解释了为什么近期这段时间受害的组织往往不是没做防护的那一批，而是做完了防护就把这件事从清单上划掉的那批。