️NSOC（网络·安全·云一体化运营中心）
7×24 主动监控与专家值守，网络可用性 99.99%，安全事件 百分百全 闭环，云资源一站式管理
今日热点 Top 5
S1 Cisco 数据中心交换机曝五颗严重缺陷可取得 root 权限，同批许可管理系统另有一颗满分缺陷
核心内容
十月八日，Cisco 为其 NX-OS 这套数据中心交换机操作系统发布了五颗严重缺陷的安全公告，编号分别是 CVE-2026-76471、CVE-2026-76485、CVE-2026-76486、CVE-2026-76501 与 CVE-2026-76465。
利用成功的结果是两种：以 root 权限在这台交换机上执行任意代码；
做不到这一点时，也可以让进程崩溃并迫使设备重新加载，也就是一次拒绝服务。
五颗缺陷全部源于校验不足，而且全部需要设备上至少开启一项功能才可能被用到。
CVE-2026-76471 是输入校验不充分，攻击者向 NX-API 这个接口发送精心构造的 HTTP 请求即可触发，而 NX-API 默认是关闭的；
CVE-2026-76485、CVE-2026-76486 与 CVE-2026-76501 都是对 IP 流量的校验不当，需要开启 NGOAM 这项运维检测功能，通过向 IP 接口发送构造报文触发；
CVE-2026-76465 是对 MPLS echo-request 报文的校验不当，需要显式开启 MPLS OAM，而这项功能默认关闭。
其中 CVE-2026-76486 还要求额外开启基于 IPv6 的段路由或者一项虚拟化叠加功能，后者要求有映射到 NVE 接口的 VXLAN 标识并且至少学习到一个对端隧道端点；
CVE-2026-76501 只在部分 Nexus 9000 型号支持段路由时成立；
带 Silicon One 芯片的 Nexus 9000 不支持 MPLS OAM，因此不受这一颗影响。
厂商同时说明，Nexus 7000 与运行在 ACI 模式下的 Nexus 9000 不受这五颗影响。
处置方面，Cisco 建议用它的版本检查工具确认并升级到已修复版本；
如果这些功能用不上，直接关掉 NGOAM、NX-API 或 MPLS OAM 就等于把这个攻击面整个拿掉；
对于暂时不能升级重启的交换机，厂商为这五颗都提供了 Live Protect 临时防护规则。
五颗都是厂商在内部安全测试中发现的，公告发布时没有看到公开披露或被用于攻击的证据。
值得单独拿出来说的是同批的另一组：Cisco 还为 Cisco License（此前叫 Smart Software Manager）发布了加固更新，四颗分别是关键功能缺少认证（CVE-2026-76480，九点八分）、加密签名校验不当（CVE-2026-76482，满分十点零）、凭据保护不足（CVE-2026-76483，九点一分）与代码注入（CVE-2026-76484，八点八分）。
与交换机那五颗不同的是，这一组的受影响版本不论怎么配置都在范围内，厂商建议升级到 10-202609，并且没有任何变通方案；
仍以 Smart Software Manager 品牌发布的旧版本不会拿到补丁，厂商建议迁移到受支持的版本。
CVE-2026-76471Cisco NX-OSNexus 9000root 权限执行Cisco License
为什么重要
能不能被攻，取决于这台设备上开了哪一项功能。NX-API 与 MPLS OAM 默认关闭，但默认关闭不等于现在没开；功能开关通常不在资产台账上，也不在漏洞扫描的覆盖范围里，判断依据只能回到设备自身的配置。
交换机所在的位置决定了后果量级：root 权限落在的是承载东西向流量的那一层，从这里可以读到配置、看到流量、横向移动；而它的告警通常由另一套系统负责，那套系统看不到这台设备内部的进程。
五颗的成因都是校验不足，分布在三个彼此独立的功能上。按编号逐条跟踪会把它们看成五件事，而按设备来看，这是一台机器上三个入口同时失守。
许可管理那一组的性质完全不同：它不论配置都在范围内，且没有变通方案。把两组放在一起读会得到一条清楚的排序——先处理不论配置都成立的那一组，再按功能开启状态逐台核对另一组。
旧品牌版本拿不到补丁，等于这条产品线的一部分实例只能靠迁移解决。这与交换机侧形成对照：一边是关掉功能就能立刻收敛攻击面，一边是除了换版本没有别的路。
顾问金句
功能开关不在台账上，而这一次能不能被攻恰恰由它决定。
建议企业做四件事。
首先，把判断顺序倒过来：先按设备导出一份当前开启的功能清单，再与这五颗的前提条件做比对，凡是开着 NX-API、NGOAM 或 MPLS OAM 的先按可被利用来对待；
这一步补的是台账，因为功能开关通常既不在资产表里，也不在扫描器的报告里。
其次，把关闭功能当作本次的主要动作而不是过渡动作：这三项功能如果确实用不上，关掉就等于把攻击面整个拿掉，效果与打补丁等价，而且不需要重启窗口。
再者，把无法立即升级重启的设备单独立项：厂商为这五颗都提供了临时防护规则，用它争取时间，并给这批设备一个明确的升级排期，不要用等下一次维护窗口来回答。
而后，把许可与授权管理系统当作一项独立资产来对待：这一组不论配置都成立且没有变通方案，先升这一组；
仍在旧品牌版本上的实例要给出迁移结论，而不是挂在待定里。
S2 日本 IDC Frontier 云平台遭勒索攻击，东部区域一中断并波及四百九十五家客户
核心内容
十月八日，日本云与数字基础设施企业 IDC Frontier 披露，其 IDCF Cloud 服务遭到第三方发起的勒索攻击，导致服务该国东部地区的一个数据中心集群中断。
这家公司是软银集团旗下子公司，IDCF Cloud 是一个基础设施即服务平台，客户用它租用虚拟主机、存储与联网资源，在日本的数据中心里运行网站、应用与业务系统。
公司说明，攻击从十月七日当地时间凌晨三点四十分开始，迫使它关停了相关系统与联网；
随后确认东部区域一的服务中断由第三方的勒索攻击造成，并表示仍在调查确切原因与影响范围。
处置动作分两个层次：先隔离并关停东部区域一受影响的系统以阻止扩散；
同时在核实其他区域安全性的过程中，主动关闭了所有区域客户对管理控制台的访问，确认安全之后再恢复。
这一条对客户的影响比较直接——控制台在核实期间是不可用的。
攻击方在控制台上留下的截图被客户在失去访问之前拍到，截图中的说法称攻入东部区域一的基础设施用了七分钟，加密了二百二十五个数据库、合计三点六 PB 数据，触及二百三十九台宿主机，封存了一万六千个虚拟机磁盘，并清除了五十五万四千一百五十三个快照。
需要说明的是，这些数字来自攻击方自己留在控制台上的说法，尚无独立核实。
受影响客户方面，公司称这次事件波及四百九十五家企业与地方公共部门。
同一时间线上还有一起尚未确认关联的中断：日本水产与食品企业 Nissui 于十月七日公布，其物流子公司 Nissui Logistics 因所用第三方数据中心疑似遭到未授权访问而发生系统中断，导致货物无法出入库，公司正在调查个人信息或客户数据是否外泄；
两家之间的关联目前不明确。
背景数据同样值得记录：安全企业 Macnica 的研究员 Yutaka Sejiyama 表示，按同一口径统计，今年截至十月六日，日本公开披露的、涉及个人信息被窃或数据外泄的事件有一百一十九起，近期这批集中在七月之后；
作为对照，二零二五年全年为八十四起，二零二四年全年为六十二起。
这名研究员对 BleepingComputer 表示，长期以来要找出某个网站特有的弱点需要投入大量时间与精力，因此小目标并不划算；
而能力强、价格低的 AI 工具的出现，可能是大面积细致探查安全弱点这件事正在发生变化的原因。
IDCF Cloud勒索攻击快照清除业务连续性IDC Frontier
为什么重要
数字由攻击方给出，但指向的动作是真的：一万六千个虚拟机磁盘被封存、五十五万四千多个快照被清除。恢复所依赖的那份副本与被打掉的数据放在同一个平台上，这不是一个备份策略问题，而是一个恢复依赖集中度问题。
服务方的处置动作是关闭所有区域的管理控制台。客户自己的运维通道在事件期间由对方掌握，意味着什么时候能动手不由自己决定，这一条需要在合同与预案层面先问清楚。
波及四百九十五家企业与地方公共部门，说明一次云侧事件的下游是成批的。对下游企业来说，这既是一次业务中断，也是一次供应商集中度事件。
攻击方自称七分钟完成突破，这个数字来自对方；但与之呼应的是 Macnica 观察到的趋势——找出某个站点特有的弱点过去要靠大量人力，因此小目标不划算，而现在便宜且好用的自动化工具改变了这笔账。
Nissui 物流子公司的中断原因被归到所用第三方数据中心，与本次事件是否相关尚未确认。这一条比事件本身更有普遍意义：多数企业的业务连续性预案里，第三方数据中心这一层往往只有一份联系方式，没有一份依赖关系说明。
顾问金句
恢复用的那份副本，和被加密的那份数据，放在了同一个平台上。
建议企业做四件事。
首先，把恢复依赖画成一张图：为每一个关键业务系统标注它的数据、快照、备份与控制台分别托管在哪里、由谁控制开关；
这次值得记的是快照被清除这一项，许多组织的恢复预案默认快照一直在。
其次，把不可变副本与异地副本作为一项独立验收项：要求副本存放在与生产不同的凭据域里，且不能被生产侧的账号删除，并定期真正恢复一次，而不是只检查备份任务是否成功。
再者，把云与托管服务按供应商集中度来管理：登记每个关键系统落在哪一家、哪一个区域、是否有跨区域副本，以及对方在事件中有权单方面关闭哪些入口；
这次客户控制台被全区域关闭，是容易被忽略的一类影响。
而后，为运维通道由对方掌握的时段准备一份替代动作清单：事件期间能做什么、谁来对外沟通、业务侧怎么降级运行；
这份清单要在事件之前写好，而不是在控制台打不开的时候现想。
A3 JPCERT/CC 就日本数据泄露激增发出告警：入口是手机应用背后的接口与已知缺陷
核心内容
十月八日，日本 JPCERT 协调中心发出告警，说明近期一批日本组织的数据泄露事件中，攻击者滥用手机应用所使用的接口，并利用已知缺陷。
告警基于收到的事件报告与其他信息，既没有点名攻击者，也没有点名受害组织；
中心称自己所掌握的情况有限且零散，并说明这不意味着每起事件的手段相同。
受影响的系统除了面向消费者的应用，还包括商业智能工具与企业内部管理系统——运营方原本并不认为公众能够触达这些系统，而存放在其中的数据在一些案例里已经泄露。
告警给出八条来源 IP 地址、五个 User-Agent 字符串，以及一组接口管控建议，其中包括对每一个端点都施加访问控制，无论它是否对外公开。
告警点名的产品只有一个，就是 Metabase 这款商业智能工具，它有一个已知缺陷且已被利用；
Metabase 建议用户升级到一份标注为安全下限的版本清单中的版本，这份清单上一次更新是八月十四日，列出的版本比该缺陷的首个修复版本更新。
规模方面，告警引用了日本企业 Macnica 安全研究中心十月七日发布的分析：该中心统计，今年截至十月六日，日本公开披露的、经由组织运营的网站系统导致个人信息被窃或泄露的事件有一百一十九起，其中八十一起来自七月或以后；
作为对照，二零二五年全年为八十四起，二零二四年全年为六十二起。
这个统计只涵盖 Macnica 判断与当前这一批相似的案例，不含勒索攻击与已归属其他攻击团伙的事件。
在这八十一起来自七月之后的事件里，有六十五起公开披露的细节太少，无法判断攻击者是如何进入的。
Macnica 还在另外十三个国家和地区发现九十九起类似案例，大多发生在七月到九月之间，其中韩国三十起、法国十一起、波兰八起；
中心不清楚日本是否为仅有目标，并说明各国的信息披露法律与做法不同。
两个案例可以看清规模：Park24 于九月二十八日说明，第三方从其共享汽车服务的网站系统取得了约六百六十万个账号的数据，次日补充说约一百六十万个账号的身份证件影像也已泄露；
经营餐饮连锁的 Monogatari 公司说明，其会员系统有一千零七十八万九千九百六十三条记录泄露。
两家公司当时都表示原因仍在调查。
手法方面，告警描述了三类。
其一是对应用背后的管理接口发起未授权请求，有些请求直接改写了信息；
中心收到的报告提到三种做法：反编译公开发布的手机应用，找出其中的接口地址与密钥；
攻击那些在应用界面上根本用不到的内部接口，报告中的动作包括修改用户权限、创建未授权账号、对比增删请求头或发送畸形认证令牌时服务端的应答差异、以及通过盲注取得账号详情；
以及使用在其他系统失陷时被窃走的接口密钥。
第二类是一个尚未证实的可能：攻击者也许不是依赖所有目标共有的某一个缺陷，而是对每一个目标扫描一批已知缺陷并逐个尝试。
第三类是口令强度不足的管理后台与已知缺陷的利用，在部分案例中得到确认。
Macnica 的分析还记录了另一条：在一些案例里，攻击者从手机应用里取出接口密钥，然后以一种看起来与正常使用没有差别的方式调用接口。
此外，攻击者会在每个站点与其接口上寻找任何能取到数据的弱点，包括返回了超出必要范围数据的接口、权限过大的接口、匿名用户也能访问的会员功能、逻辑错误与会话管理缺陷。
JPCERT/CC接口滥用Metabase数据泄露移动应用
为什么重要
被打的接口在应用界面上根本不存在。界面是人维护台账的依据，界面上看不到的端点，既进不了资产清单，也进不了渗透测试的用例——它们只有在对应用做逆向或读接口定义时才会出现。
六十五起来自七月之后的事件中，公开披露的细节不足以判断入口。这不是披露质量的问题，而是说明这一类事件里入口通常要很久才被说清，而企业能据此行动的东西恰恰是入口。
攻击者调用接口的方式看起来与正常使用没有差别：密钥来自应用本身，请求来自正常路径。以异常检测为主的监控在这一类流量上基本不产生信号，能发现它的只有接口侧的授权校验与返回范围控制。
告警给出的建议是对每一个端点施加访问控制，不论它是否对外公开。这一条背后的判断是：把接口分成对外与内部两类，本身就是这一类失守的成因。
已点名的产品只有 Metabase 这一个，而它建议升级到的版本比首个修复版本更新——也就是说，打过补丁不等于落在安全版本上。这与同一批事件里已知缺陷被利用这条描述是同一件事的两面。
顾问金句
界面是给人看的，攻击者看的是接口。
建议企业做五件事。
首先，为每一个对外应用建立一份接口台账，来源不是界面而是接口定义、网关配置与对应用本身的逆向结果，并把界面上不存在但可被调用的端点单独标出来。
其次，把授权校验下沉到每一个端点本身，而不是依赖这个接口不对公众开放这样的分类判断；
同时把返回范围收窄到当前调用所必需的字段。
再者，把应用内嵌的密钥按公开资料处理：它在应用包里就等于在攻击者手里，改为服务端签发、可吊销、绑定设备与会话，并为调用频率与来源设定告警。
而后，把第三方接口密钥与共享凭据纳入轮换范围，因为这次明确记录了用别处失陷时窃得的密钥这一条路径。
另外，为商业智能与内部管理系统单独做一次可达性核对，这类系统常被当作内部系统而从未做过对外暴露面检查。
A4 FakeGit 卷土重来，一万七千余个代码托管仓库在三十四小时内被重新指向窃密程序
核心内容
十月八日，代码供应链安全企业 Apiiro 发布报告，称 FakeGit 这个行动在本月四日恢复活动，目前在 GitHub 上用一万七千六百一十个仓库投放 SmartLoader，并借它进一步投递 StealC 窃密程序。
这些仓库伪装得很像正常项目：说明文件写得完整，里面有一个下载按钮，指向一个压缩包，包里就是初始载荷。
行动方多数使用一次性账号，但研究者识别出至少七百个账号看起来属于真实的研发人员。
规模背后的速度更值得看：在三十四小时里，FakeGit 推出了一万三千多个仓库，峰值达到每小时两千九百九十九个；
研究者抽查的提交里，百分之九十七只改动了说明文件，百分之八十八把下载按钮指向了那个安装 SmartLoader 的压缩包。
报告里有一句话点明了机制：没有人需要新建一个仓库，这批仓库一直都在，只是被重新瞄了一遍。
这个行动并非新出现：类似活动至少从一月起就被观察到，FakeGit 这个名字来自七月，当时企业浏览器平台 Island 发布报告，记录了七千六百个推送 SmartLoader 的假仓库，其中八百个伪装成 AI 技能或 MCP 服务器，出现在公开的 AI 注册表与目录里。
为什么它能一直存活，研究者给了三条原因。
首先，仓库下架依赖的是清单，而清单只覆盖其中一小部分：研究者称，在自己报告之前，这批仓库中有百分之七十一不在 URLhaus 的记录里；
而且域名级的 DNS 拦截清单没法在不封掉整个平台的前提下拦掉平台上的一个文件。
其次，被列入黑名单的载荷与备份副本依然可取，行动方只要换掉下载链接就能让同一批仓库继续工作。
再者，恶意压缩包分散在分叉仓库、历史版本文件、发布资产、议题附件与专门的下载托管仓库里，因此一个链接一个链接地删除是无效的——删掉一个，行动方就把诱饵指向一个备用副本，可以是分叉、旧压缩包、发布资产或议题附件。
给使用方的建议是：核对仓库的归属者；
安装 AI 技能与 MCP 服务器时只走官方注册表或厂商仓库；
一旦怀疑执行了 SmartLoader，就按账号可能已失陷来处置，吊销活跃的会话与访问令牌，并改用通行密钥。
FakeGitSmartLoaderStealCGitHub代码供应链
为什么重要
清单没有变，变的是指向。同一批仓库在几个月里反复被重新瞄准，说明以仓库清单为单位的下架与拦截，和以下载按钮指向哪为单位的攻击，不在同一个粒度上。
三十四小时一万三千多个仓库、峰值每小时近三千个，而且百分之九十七的提交只改说明文件——这是一个可以低成本重复执行的动作，而不是一次需要投入的事件。
至少七百个看起来属于真实研发人员的账号在参与，意味着仓库归属者可信这条判断依据在这里部分失效；而八百个伪装成 AI 技能或 MCP 服务器的仓库，正指向当下扩张很快的安装来源。
域名级拦截在这一类攻击面前没有着力点：要拦住平台上的一个文件，就得封掉整个平台。这一条决定了处置只能发生在安装这一侧。
处置动作被明确为按账号失陷来处置——吊销会话与访问令牌、改用通行密钥。也就是说，一次误装的后果不限于这台机器，还包括这个账号所能触达的所有仓库与流水线。
顾问金句
仓库一直都在，被改的只是那个按钮指向哪。
建议企业做五件事。
首先，把从代码托管平台安装这件事从个人动作变成受控动作：研发与运维所需的依赖、AI 技能与 MCP 服务器，只从官方注册表或厂商仓库获取，并在内部维护一份允许清单。
其次，把核对归属者写进安装前检查而不是事后审计：一次性账号、新注册账号、仓库历史很短但说明文件很完整的，先停下来。
再者，把误装的处置范围扩大到账号：一旦怀疑执行过，就吊销该账号的活跃会话与访问令牌，复核近期提交与流水线任务，并把通行密钥作为长期替代。
而后，把 AI 技能与 MCP 服务器单独立一条来源规则，因为这一类正在成为新的默认安装入口，而它继承的是安装者本人的全部权限。
另外，不要依赖域名级拦截清单来覆盖这一类风险，把检测放在安装侧与凭据使用侧。
A5 PoeLLM 借一首诗定位命令服务器，已感染三千四百余台对外暴露的 AI 与开发服务器
核心内容
十月七日，Lumen 旗下 Black Lotus Labs 发布报告，说明一个以对外暴露的 AI 服务为目标的挖矿行动。
攻击者用的恶意程序叫 PoeLLM，是一个名为 libgcrypt 的可执行文件，它会从一个托管在 GitHub、看起来是 Node.js 分叉仓库的样式文件中，取出一首题为《论连接的本质》的诗里的四个词或词组，再用一份硬编码的词典把这些词映射成数字，据此拼出一个 IPv4 地址，也就是命令服务器的地址。
要换地址，行动方只要改这首诗；
到目前为止已经改过十一次，研究者推测可能还有至少一次未观察到的更新。
规模上，研究者称已有三千四百多台服务器被攻陷，单日活跃的受感染系统在高峰时达到约八百台；
行动至少从四月就开始了，之后活跃度显著上升，迄今已经启用过十一个命令服务器。
报告发布时给的数字是两千一百台，研究者随后在报告里更新为三千四百台。
受害者运行的往往是暴露在公网上的 AI 工具，包括 LiteLLM 与 Ollama，也包括 Gotenberg 这个文档转换服务与 Gitea 这套研发协作工具，另外还发现了针对 Ivanti Sentry 的迹象。
研究者解释这类目标吸引人的原因：配置往往很随意、直接暴露在公网上，而且通常跑在适合挖矿的高性能图形处理器集群上。
载荷的能力不止于挖矿：它带有远程 shell、XMRig 与 Iron 两款挖矿程序、HTTP/S 扫描与漏洞投放能力；
研究者发现受害者会与一个叫 Kryptex 的挖矿服务通信。
更关键的是它扩散的方式：一台服务器被攻陷之后会变成下一轮攻击的跳板，它会扫描三千与四千这两个端口——分别对应 Gotenberg 与 LiteLLM——并尝试利用 CVE-2026-42271。
这个缺陷位于 LiteLLM 的 MCP 服务器测试端点，起初披露时被描述为需要认证、评分是高危；
Horizon.ai 的研究者确认它可以与另一处问题 CVE-2026-48710 串接，形成无需认证的远程代码执行。
基础设施侧还有一条细节：研究者分析发现，几个命令服务器上带有存在缺陷的路由器管理界面，说明攻击者复用了此前被攻陷的路由器。
归属方面，研究者无法给出高置信判断，但依据恶意程序里的注释与管理界面托管在意大利的一台服务器上，以中等置信度评估运营者在意大利。
防护建议是：及时打上更新、减少关键资产的公网暴露、把外部访问限制到可信地址，并查阅联网监控日志中是否出现研究者给出的那批指标。
PoeLLMLiteLLMOllamaCVE-2026-42271挖矿
为什么重要
暴露面与工作负载方向一致：这一类 AI 与开发服务之所以被盯上，不是因为它们有缺陷，而是因为它们既对外开放、又跑在有算力的机器上。这一类资产常常由研发团队自行搭建，不进资产台账，也不归运维团队管理。
被攻陷的机器立刻变成下一轮的扫描器与投放点，扫描三千与四千端口并尝试利用一个已知缺陷。这意味着这一类暴露不是单点事件，而是会自我放大的，处理窗口因此以小时计。
一枚需要认证的高危缺陷，在与另一处问题串接之后变成无需认证的远程代码执行——评分与前提是在单独评估时给出的，而攻击者用的时候不按单独评估来用。
命令地址藏在一首诗里，且已经改过十一次。基于域名与地址的拦截清单，面对的是一个可以随时改变指向的目标，而承载这首诗的仓库看起来只是一个普通的分叉。
基础设施里还有被攻陷的路由器管理界面。攻击者的控制面与被攻击的目标共用同一类顺手部署、之后无人管理的东西，这一层在多数企业里没有固定的清理与核对动作。
顾问金句
它不是先找到缺陷，而是先找到开着门的机器。
建议企业做五件事。
首先，把 AI 与开发类的对外服务单独建一份台账——模型服务、推理网关、文档转换、代码托管以及它们各自监听的端口，因为这一类通常由团队自建、不进资产表。
其次，把公网暴露作为主要收敛动作：这些服务默认就对外，能放进内网或零信任入口的就不要留在公网，并把外部访问限制到可信地址。
再者，把端口级扫描纳入日常监测，特别是这一类服务常用的端口区间；
出现来自已受控主机的扫描要按事件处理，因为被攻陷的机器会立刻变成跳板。
而后，把需要认证这一类评分前提单独记一条：已知缺陷在串接之后可能不再需要认证，修复顺序应按串接后的后果排，而不是按单条评分排。
另外，把这一类机器的失陷后果按跳板来评估——它会被用来攻击别人，出向行为因此必须被记录与告警。
趋势分析
本周期五条热点讲的是同一件事：攻击改动的是指向关系，而治理维护的是清单，两者不在同一层。
FakeGit 的那批仓库一直都在，这次只是把说明文件里的下载按钮重新指向了一个压缩包，三十四小时推出一万三千多个仓库，仓库清单从头到尾没有变过；
PoeLLM 的命令服务器也还是那几台，改的是一首诗里的四个词，运营方改诗就换地址，已经改过十一次。
日本这批数据泄露里被打的接口，从来不在任何人维护的台账上，因为它们在手机应用的界面上根本不存在；
Cisco 那五颗缺陷能不能被用，取决于这台交换机开了哪一项功能，而功能开关通常也不在资产台账上；
IDCF 云上被一并按住的三点六 PB 数据与五十五万个快照，指向的是同一个平台，客户手里的控制台被关掉的那一刻才知道恢复要依赖谁。
把它们放在一起看：一次清单核对回答不了「它现在指向哪」，而这一次的差别恰恰发生在指向上。
热门跟贴