Fnet 云网安 260922

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

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

今日热点 Top 5

S1 打开陌生人的仓库问一句话就够了：OpenAI Codex 沙箱两处逃逸，把执行权交回给了仓库作者

核心内容

安全机构 Accomplish AI 的研究员 Oren Yomtov 找到了两条走出 OpenAI Codex 沙箱的路，其中一条能在 Codex 严格的那档模式下、没有任何审批弹窗、屏幕上也不显示任何提示的情况下，直接在研发人员的机器上运行命令。

两处问题于 8 月 12 日报告给 OpenAI，八天内完成修复。

危害更大的那处被命名为 Heapjack，目标是一个叫 node_repl 的组件。

Codex 桌面版在安装时把它写进全局配置文件 ~/.codex/config.toml，既没有开关也无法关闭，命令行版用户虽然没有主动选择，也一样继承了它。

这个组件在一个 Node.js 进程里同时维持两个脚本执行上下文：一个是受信任的，装着 OpenAI 自己的调度代码；
另一个是不受信任的，运行智能体与外部项目的代码。

受信任一侧要向一个不受沙箱约束的原生父进程证明身份，凭据是每次启动重新生成的随机令牌。

问题在于两个上下文共用同一块堆内存，那段令牌对不受信任的一侧来说就是躺在内存里的一段明文字符串。

攻击路径因此变得很朴素：用堆快照接口拍一张内存快照，逐个去试长得像令牌的字符串；
猜错时接口返回未授权，猜对但参数不对时返回真正的校验错误，这个差异本身就是一台判别机。

拿到令牌之后，不受信任的代码把自己的请求写进受信任一侧与父进程通话的那条管道，父进程验过令牌就照做。

演示里用的是系统的打开命令，在 Codex 的进程树之外启动了应用；
同样的通道可以够到任意 Unix 套接字，其中 Docker 守护进程的套接字是更显眼的那个，也可以够到能改写全局配置文件的工具，改完之后的权限在下次启动继续生效。

这套动作全部发生在只读模式下，那本该是智能体一个字都不许写的档位。

落到真实场景就是一句大白话：打开别人的仓库，问一句关于代码的问题，写这个仓库的人就在你的机器上拿到了不受沙箱约束的命令执行。

第二处叫 Overpatch，位于开源的命令行版里。

工作区写入模式下智能体只应该在工程目录内写东西，但打补丁的工具在计算权限时，会用补丁内容里出现的路径来决定放行范围，而且放行的粒度是那个路径的上一层目录——补丁里只要提到临时目录，放行范围就扩到了磁盘根。

可用的利用是两处改动拼起来的：一处提到临时目录，作用只是把权限撑开；
另一处通过符号链接往 shell 启动文件里追加一行。

去掉前一处，写入被拒绝；
带上它，研发人员下一次打开终端就在沙箱之外执行了攻击者那一行。

两处问题的形状是一样的：执行机制的判定依据，被放在了它自己要去判定的那个东西里面。

社区里有两句评价很到位，一句说脚本上下文隔离的是全局变量而不是内存，所以那个沙箱其实是堆从来没有同意过的一个承诺；
另一句把这条信任边界称作一道房间隔断。

OpenAI 在桌面版 26.818.21641 与命令行版 0.149.0 中修复了这两处问题。

这里还有一个交付层面的落差值得单独点出：编码智能体通常是研发人员自己装的、自己决定什么时候更新，这个补丁不会跟着操作系统更新一起推送到机器上。

OpenAI Codex沙箱逃逸HeapjackAI 编码智能体研发终端

为什么重要

• 信任边界画在了脚本上下文之间，真正的边界却是进程与内存：两个上下文共用同一块堆，令牌就成了可读的明文。隔离设计里更常见的一类失效，就是把边界画在一层抽象上，而实际生效的边界在下一层。

• 攻击形态退化成一次日常操作：不需要诱导安装、不需要伪造依赖、不需要任何权限，只要有人打开那个仓库并问一句关于代码的话。智能体让看代码这个动作本身变成了执行入口。

• 严格的那档模式没有拦住它：只读模式本该是智能体不写入任何内容的档位，而 Heapjack 在只读模式下就能拿到不受沙箱约束的执行。这说明更严格的档位保护的是写文件这个动作，不是获取执行权这个结果。

• 补丁不会自己走到机器上：这类工具由研发人员自行安装与更新，不在企业补丁推送范围内。企业里实际运行的版本分布，只能靠主动清点得到，而多数组织没有这份清单。

• 同一个思路在四款工具上都出现过：今年七月已有研究者在 Cursor、Codex、命令行助手与另一款桌面智能体上演示过同类思路——留在沙箱里的智能体写一个文件，由沙箱之外受信任的工具稍后去执行。这不是某一家的实现失误，而是这一类架构共同的结构性缺口。

顾问金句

这两处问题的形状是一样的：守门的人把钥匙放在了他要守的那个房间里。

建议企业做四件事。

首先，把人工智能编码工具纳入需要主动清点的资产：统计组织内实际安装的编码智能体种类与版本，命令行版用版本查询命令核对是否达到 0.149.0，桌面版核对是否达到 26.818.21641；
这类工具不在操作系统更新推送范围内，版本号只能靠一次全量清点拿到，而不是靠补丁合规报告。

其次，重新审视沙箱这个词的假设边界：沙箱隔离的是脚本上下文，不是进程，也不是内存，凡是声称在同一进程内切分信任的设计，都要单独问一句凭据放在哪里、能不能被同进程读到。

再者，把打开外部仓库这个动作本身列为需要审批的动作，对来源不在白名单内的代码库默认禁止智能体自主访问，并限制其可触及的套接字与配置文件范围，其中容器守护进程的套接字要单独收口。

而后，给研发终端补齐行为侧的观测：父进程异常派生、配置文件被改写、启动文件被追加，这三类行为在单一控制台上都不会被判定为高危，但串起来就是这次的完整路径。

A2 一枚被重新注册的 CDN 域名，至今决定着数千个站点每次加载什么

核心内容

2025 年 7 月，有人注册了一枚曾经属于某家内容分发服务的域名。

那家服务商多年前已经关停，这枚域名随之过期，但有一件事它没有失去——调用它的那些人。

数千个网站、代码仓库与文档页面至今仍然硬编码引用着它下面的主机名，而新的持有者拥有整个域的通配解析，任何一个主机名现在都指向他控制的设施。

就目前而言，主域名提供的是一个广告密集的下载页面，本身平淡无奇。

真正值得停下来想的是另一件事：这数千个页面接下来加载什么，决定权在一个陌生人手里，而没有任何相关方收到过通知，因为从外面看，一切正常，什么都没有坏。

这个模式既不新鲜，也不罕见。

2024 年 6 月，被超过 11 万个站点嵌入的脚本兼容层 polyfill.io 变更了所有权，开始对移动端访客做条件跳转。

那些站点并没有被入侵，它们只是在多年以前外包了一个脚本标签，此后再没有回看过这个决定。

两件事共享同一个问题，而多数安全团队对这个问题没有任何控制手段：恶意代码从来没有在他们的服务器上出现过，而且它是在更后一次部署之后很久才到达的。

服务端工具看的是一个错的地方。

静态分析、依赖扫描与成分分析检查的都是组织自己构建和发布的东西，而第三方脚本不属于其中任何一类——它由访客的浏览器、从一台组织既不运行也无法控制的服务器上、在每一次页面浏览时实时拉取。

这让它天然地对抗常规测试：返回内容可以随地理位置、浏览器标识、来源页、时段与会话而变。

从数据中心地址段抓一次拿到的是干净版本；
另一个国家蜂窝移动网上的购物者拿到的可能是完全不同的东西。

与此同时，第三方脚本在页面里拥有的权限与自有方代码完全一样：它可以读文档对象、逐字符读取正在输入的表单、读取 Cookie 与本地存储，也可以向任意位置发起外联。

这类攻击不需要服务器失陷，只需要一个已经被批准的脚本标签开始行为不同。

有一个观察者对每一次页面浏览都稳定在场，那就是执行了这段代码的浏览器。

内容安全策略通常被当作对抗跨站脚本的手段，但它的第二个作用对还没搞清楚自己在跑什么代码的安全团队更有用：它可以规定哪些代码允许在你的站点上执行、拦下未经授权的代码，并且在这件事发生时告诉你。

这些告警来自真实会话、真实地理位置、真实用户手上的真实设备——一个只针对某个国家已登录用户触发的载荷依然会被报出来，因为发出告警的正是执行它的那个浏览器。

这不是理论上的收益。

就在 2026 年 9 月，某告警收集服务从浏览器侧回传的告警里发现了一批运行点击修复类社工活动的电商站点：内容管理系统里被植入了编码过的加载器，经跳转链引到一个伪造的身份验证浮层，把一条命令放进受害者的剪贴板，并以计划任务的形式完成驻留。

攻击者控制的主机名出现在受害者浏览器发出的告警里，而其中若干个域名在当时主流信誉服务的评级仍然是干净的。

没有扫描器标记这些页面，因为在服务器上，它们是干净的。

还有一条已经不是选择题：凡是在站点上处理银行卡支付的组织，支付卡行业数据安全标准 4.0.1 版的 6.4.3 与 11.6.1 两条要求，已于 2025 年 3 月 31 日从较优实践变为强制。

两条合起来要求支付页面上的每一个脚本都经过授权、完整性有保证、存在带业务理由的书面清单，并且有一套机制能发现并告警页面内容与响应头的未授权变更。

审核员会索要这份清单、这套告警机制，以及它产生过的证据链。

CDN 域名重注册第三方脚本内容安全策略子资源完整性客户端供应链

为什么重要

• 失效的是一个已经停业的第三方，而不是自家任何一行代码：组织对外包标签的依赖不会因为对方停止运营而消失，硬编码引用会在代码、文档与仓库里长期存活，且没有任何机制提醒它们已经变成了别人的资产。

• 从外面看什么都没坏，这是它更危险的地方：页面照常加载，功能照常可用，监控照常是绿的。所有基于可用性的观测都会给出正常结论，而决定权已经换手。

• 服务端扫描在看服务器，加载发生在浏览器：静态分析、成分分析与依赖扫描的对象都是组织构建与发布的东西。这次的差距不在工具的精度，而在它们观察的位置与事情发生的位置根本不是同一个。

• 第三方脚本与自有方代码同权：它能读文档对象、逐字符读输入中的表单、读本地存储、向任意位置外联。攻击门槛不是拿到一台服务器，而是让一个已经获批的标签改变行为。

• 合规已经把这件事从建议变成义务：支付卡行业标准的脚本清单与变更告警两条要求已于 2025 年 3 月 31 日转为强制，审核员会直接索要清单、告警机制与它产生过的证据链。

顾问金句

这数千个站点没有被入侵，它们只是在很多年前把一小段决定权交了出去，之后再没有回看。

建议企业做四件事。

首先，做一次外部脚本清单：抓取生产页面，把每一个第三方来源连同它的引入方式、引入时间与业务理由列成台账——这份清单才是真正的暴露面，而不是依赖树。

其次，给所有外部资源标签加上完整性校验：为当前加载的第三方文件生成哈希并写入标签属性，这样一次静默替换会变成一次被浏览器拒绝的加载，而不是一次无声的成功。

这一条不花钱，却正好打在这类攻击的命门上。

再者，先以仅报告模式部署内容安全策略，收集三十天的违规报告，把标签管理器与营销像素注入的脚本一起纳入视野，摸清真实清单之后再转为执行，并保留报告地址以维持可见性。

而后，把域名注册状态纳入监控对象：为页面引用的每一个第三方来源订阅注册信息变更提醒，一旦发生持有人变更或临近到期，按一级安全事件处理。

对于处理卡支付的组织，这条路径已经不是选择题——清单一开始就要按审核口径来建。

A3 十个 npm 包把恶意代码藏进了运行时：六月装上的那道门，拦的是一个不再发生的时刻

核心内容

Checkmarx 的研究人员发现，一个名为 indexed-btree 的包正在冒充合法的 sorted-btree 库，并且已经累计到每周约 200 万次下载。

这次行动的可取之处不在于用了什么新手法，而在于它把触发条件放到了一个几乎所有人都不再看的位置。

今年六月，代码托管平台公布了一组针对 npm 的安全措施，用以应对自 2025 年末以来反复冲击开源生态的供应链攻击：其中关键的一条是默认阻断依赖的安装前、安装中与安装后脚本，除非显式批准；
另外几条则阻止 npm 在未获许可的情况下从代码仓库或远程地址自动取依赖。

这个包绕开这些措施的方式是不使用任何安装脚本，而是把加载器藏进了 BTree 原型上的写入方法里——那恰恰是每个使用者都会不停调用的主函数。

当调用时传入的键等于一个特定数值、且包内那个压缩过的加载文件存在时，代码会以分离的子进程方式把它启动起来。

结果就是安装环节看起来完全干净，没有触发任何一道审批机制。

加载文件本身用了字符串数组编码与自校验数组轮转两类混淆。

运行起来之后，它会收集系统架构、主机名、处理器、内存与运行时长，通过硬编码的协作平台频道与即时通讯频道把这些信息送出去；
随后轮询一条部署在测试网上的智能合约，从中取得控制端的地址；
再用密钥交换派生出对称密钥，解密合约里分片存放的第二阶段载荷。

把控制端地址放在链上意味着即便域名或地址被封，运营方只要改一下合约里的值就能换一个去处。

这个包还带自我清理能力，可以在收手时删掉自己的文件，并从包代码里移除那个触发点。

为了让项目看起来可信，运营方做了不少功课：准备了一个像样的代码仓库、填充了提交历史、经营了账号形象，而仓库里并不包含 npm 包中那段恶意代码。

研究人员还另外发现了九个同源的包并已从注册表移除，它们的下载量都不小：ordered-kv-index 约 44.8 万次、btree-leaderboard 约 49.4 万次、priority-slot-queue 约 40.3 万次、btree-range-store 约 46.8 万次、btree-core 约 195 万次、btree-time-index 约 42.5 万次、btree-lru-cache 约 37.2 万次、neighbor-key-map 约 36.6 万次、sliding-score-window 约 44.8 万次，合计每周超过 700 万次下载。

研究人员同时指出，运营方持有的一个钱包里有 109 个以太币，但报告并未说明这些资金来自何处。

给出的处置建议也很直接：不要只依赖安装期扫描，还要引入运行时行为分析；
凡是装过上述任何一个包的组织，都应轮换受影响环境中的全部密钥，并从安全备份恢复开发环境。

npm 供应链indexed-btree运行时触发链上控制端依赖治理

为什么重要

• 防线守在了一个不再发生事情的时刻：安装期控制只能证明这个包在被安装的那一会儿是安静的。当触发器被放进一个正常业务流程里反复调用的函数，安装检查与运行风险之间就出现了一段没人看的空白。

• 混淆的对象是正常行为而不是异常行为：加载器藏在主函数里，随正常使用被调用。这类攻击不会因为行为突兀而被发现，它恰恰藏在更平常的那条调用路径上。

• 控制端放在链上让封禁失效：域名与地址可以被封，合约里的一个值改一下就换了新的去处。这把处置手段从封禁变成了持续对抗，而多数组织的处置流程是按一次性封禁设计的。

• 自我清理抹掉了取证窗口：它可以删掉自己的文件并移除触发点。等到有人察觉，现场已经被清扫过，事后追溯的难度陡增。

• 影响面横跨研发、构建与生产：这个包会在研发终端、持续集成运行器、构建发布系统，以及任何安装了它的生产服务里被触发。测试套件在自动执行时同样可能调用到那个方法，这意味着持续集成环境本身就是一条独立的暴露路径。

顾问金句

这道门装得很扎实，只是它守的时刻已经过去了。

建议企业做四件事。

首先，立刻在锁定文件与物料清单里检索上述十个包名，命中即视为已失陷处理：隔离受影响系统、轮换这些环境里的全部密钥、从已知的安全备份重建，而不是只卸载了事。

其次，把依赖防线从安装期延伸到运行期：在研发与预发环境里对脚本进程加上行为观测，重点看计划外的外联、超出预期路径的文件访问，以及来自业务代码之外的协作平台与即时通讯接口调用；
同时在构建与生产侧限制到区块链远程过程调用与协作平台接口的出向连接，除非业务明确需要。

再者，用锁定文件加完整性校验把版本钉死，生产环境不允许解析为浮动版本，并对与知名库形近的包名建立人工复核环节——这一次的伪装对象只是一个排序库，而它的下载量是百万级的。

而后，把供应链评审从静态成分分析扩展到动态：对新增与变更的依赖，先在隔离环境里实际跑一遍再放行，观察它运行时到底做了什么。

A4 一台运维工程师的笔记本：攻击组织借印度 IT 服务商进入客户内侧

核心内容

研究人员把一起针对某家小型印度 IT 服务商的入侵归因到一个同时被追踪为 TraderTraitor 与 UNC4899 的攻击组织。

入口不是这家服务商的服务器，也不是它的边界设备，而是一名运维工程师的手提电脑。

设备上被部署了两款后门，分别是 FLATROOF 与 ROOFDECK。

这两件工具此前都曾出现在该组织 2026 年对某 Web3 平台的攻击行动中，而该组织还与 2025 年一起约 15 亿美元规模的数字资产失窃事件相关联。

这条路径值得被单独拿出来看的原因，在于它把供应链信任从组织层下压到了个人设备层：服务商与客户之间签的是合同、做的是对接、管的是权限，但真正的接入点是一台不属于客户、也不在客户资产清单上的机器。

一旦这台机器被控制，攻击者所处的位置就已经在客户的内侧——他不需要再绕过什么，因为他用的正是那个被授权的工程师所拥有的身份、会话与访问路径。

这类结构在当下的企业环境里相当普遍：外包研发、托管运维、联合项目组、第三方实施，各方人员的设备与账号以各种形式接入客户的系统与代码库，而绝大多数组织的资产清单里，这一类入口要么不存在，要么只记录了机构名称而没有落到设备与账号。

同一时间窗口内还有一条相关的背景值得注意：某国执法与研究机构的联合公告指出，被攻陷的研发终端常被用于横向移动至雇主或客户侧的内部系统，进而把一次针对个人的攻击转化为知识产权窃取与情报活动。

对本周期的这条热点而言，由此得出的结论是清晰的——评估第三方风险时，问的对象不应该是这家服务商有哪些资质，而应该是它的人用什么设备、以什么身份、在哪些时段接入了我们的哪些系统。

Jade SleetTraderTraitor第三方入口供应链信任FLATROOF

为什么重要

• 入口是一台不在客户资产清单上的设备：服务商与客户之间管理的是合同与权限，而实际接入点属于个人。清单里没有的资产，就不会进入任何一轮加固与监控的排期。

• 攻击者落地的位置已经在内侧：控制了这台设备，就同时取得了被授权工程师的身份、会话与访问路径。此后不需要再绕过边界，因为边界本来就是为他打开的。

• 滥用的是合法权限而不是漏洞：这类入侵在日志里呈现为正常的登录与正常的操作，基于异常特征的检测很难把它与日常工作区分开，能区分的只有行为基线。

• 后门工具的复用指向规模化作业：两款工具都曾出现在该组织此前的行动中，说明这是一套成熟的、可复制的工具链，而不是为单一目标定制的一次性投入。

• 第三方风险管理普遍停在机构层：多数评估问的是资质、认证与合同条款，很少落到具体设备、具体账号与具体时段。这个粒度上的缺口，正是这类攻击的通行空间。

顾问金句

风险不在那家服务商的资质文件里，在工程师手上那台机器上。

建议企业做四件事。

首先，把第三方入口的粒度从机构下压到设备与账号：对每一家外包、托管与联合项目方，列出具体接入人员、所用设备、接入身份、可访问系统与允许时段，这份清单才是真正的第三方攻击面。

其次，对第三方账号实行按需授予与按时回收：权限按任务授予并写明到期时间，任务结束即回收，避免长期有效的通用账号在组织里沉淀。

再者，为第三方访问单独建立行为基线并纳入观测：同一账号在非约定时段登录、从非常用地点接入、访问与任务无关的系统、在工作范围之外批量读取数据，这几类偏离要能触发告警——攻击者用的是合法身份，能区分他的只有行为。

而后，在合同与验收条款里写明可核验项：第三方设备的终端防护与补丁状态、账号的多因素要求、事件通报时限，以及发生失陷时的配合义务，并在续约时复核这些项是否仍然成立。

A5 四国联合公告：三万台设备、超过七千个钱包，入口是一次看起来正常的面试

核心内容

日本、美国、澳大利亚与德国的执法机构联合发布公告，披露一个被追踪为 WaterPlum 的攻击组织在 2025 年 12 月至 2026 年 7 月之间，攻陷了分布在 100 多个国家的至少 30000 台设备，并涉嫌将约 17 亿日元、折合 1071 万美元的数字资产转移到该国境内。

公告同时指出，攻击者从超过 7000 个数字钱包中取走了资金或凭据。

这个组织被归入一个已持续多年的行动，该行动此前就以恶意代码包感染求职者的设备而知名。

攻击者的做法是冒充合法的人工智能、数字资产与数字藏品公司，或者借助招聘与自由职业平台去接触求职者。

在伪造的面试与编码测试环节中，受害者会被要求下载项目、排查一个并不存在的视频会议故障，或者执行一段代码。

公告把若干恶意程序家族与该组织的行动关联起来：一类是藏在代码包里的脚本型恶意程序，一类是脚本编写的后门，一类兼具远程控制与信息窃取能力，还有一类通过被投毒的开发工具项目投递，利用配置文件在文件夹被打开并标记为信任之后执行代码。

设备一旦被控制，攻击者会尝试窃取浏览器凭据、剪贴板内容、击键、数字资产私钥与助记词，以及文档内容，同时截取屏幕。

公告特别提示了一个被低估的方向：攻击者会借被感染的电脑进一步移动到雇主或客户侧的内部系统，把一次针对个人的攻击扩展为知识产权窃取与情报活动。

执法机构还直接把这个组织与该国的欺诈性远程 IT 劳工行动联系起来——部分成员同时以远程 IT 劳工身份为客户做开发工作，两类活动使用过相同的地址；
而这些劳工又会复用在攻击中窃得的身份文件去冒充受害者求职。

调查人员还发现，攻击者在在线面试中使用换脸工具，随后关闭摄像头并把原因归咎于连接问题。

公告给出的建议分两条线：组织应仔细核验求职者的身份、所在地与资质，并把其访问权限限制在执行工作所必需的系统与数据范围内；
研发人员不要在沙箱之外运行来源不明的代码，在执行前应检查所给文件与代码里是否存在拉取额外载荷的命令。

WaterPlum四国联合公告招聘攻击面远程身份核验终端隔离

为什么重要

• 入口是一个业务流程而不是一项技术：招聘、面试、编码测试，这些环节在设计时从未被当作攻击面，因此也不在任何安全控制清单上。防御体系里没有的东西，不会有人去加固。

• 规模说明它已经工业化：30000 台设备、100 多个国家、7000 多个钱包、八个月的持续活动时间。这不是零星的手工操作，而是有基础设施支撑的流水线作业。

• 被攻陷的个人设备是通往企业的跳板：公告明确指出攻击者会借感染设备移动到雇主或客户侧的内部系统。对个人设备的攻击，这笔账单终究会开在企业头上。

• 身份核验正在被技术性地绕过：换脸工具加关闭摄像头再加一句连接不好，这套组合对现有的远程面试核验流程是有效的。而窃得的身份文件还会被复用到下一次求职中。

• 给出的建议里有两条是组织可以立刻落地的：一是把访问权限限制到执行工作所必需的范围，二是让面试与编码测试在隔离环境中进行。这两条都不需要新的采购。

顾问金句

招聘流程从来不在安全清单上，而它恰恰是少数几个能让陌生人合理地请你运行一段代码的场合。

建议企业做四件事。

首先，把面试与编码测试放进隔离环境：候选人不应在自己的主力开发机上执行来源不明的代码与项目，组织应为面试环节准备一次性的虚拟环境或浏览器内的开发容器，这一条对面试官与候选人都成立。

其次，核验身份时不依赖对方提供的渠道：通过自行查找的官方途径确认公司与联系人，对视频面试中的异常表现——例如长时间关闭摄像头、以连接问题为由回避实时互动——建立复核环节，并把换脸这一可能性写进招聘团队的识别要点。

再者，把按需授权原则前移到入职之前：远程员工与外包人员的访问权限按任务授予、写明到期时间，只覆盖执行工作所必需的系统与数据，这一条既是公告的原话，也是把损失范围钉住的仅有办法。

而后，为研发终端补齐行为观测：脚本进程的异常派生、剪贴板的异常读取、浏览器凭据库的非常规访问，这三类行为在单一控制台上都不足以判定为高危，串起来才是这次的完整路径。

对已经在面试中运行过来历不明代码的员工，其设备应按已失陷处理——隔离、从干净系统改口令、核查钱包与凭据。

趋势分析

本周期五条热点分布在编码智能体、前端供应链、第三方脚本、外包服务与招聘流程五个层面，指向同一件事：防线守的位置，和攻击真正发生的位置，不在同一处。

Codex 的沙箱把信任边界画在两个脚本上下文之间，而真正决定能不能越过去的是它们共用的那块堆内存，于是打开一个陌生仓库、问一句关于代码的话，就足以让仓库作者在你的机器上拿到一个不受沙箱约束的命令执行；
npm 在六月默认拦住了安装脚本，攻击者就把触发条件挪进一个每个用户都会不停调用的函数里，安装环节干净得像没发生过任何事；
数千个站点至今仍从一枚已被他人重新注册的域名加载脚本，而组织自家的扫描器看着的是服务器上的文件，加载发生在访客的浏览器里；
一家印度 IT 服务商的运维工程师笔记本被攻陷之后，攻击者的位置就已经在客户的内侧；
四国执法机构的联合公告则把这条线推到了招聘流程上——三万台设备、超过 7000 个钱包、1071 万美元，入口是一次看起来再正常不过的面试。

一条主线是控制点正在被放在错误的地方：沙箱把判定依据放在它自己要判定的内存里，安装检查守在安装那一刻而执行发生在运行那一刻，服务端扫描守在服务器上而加载发生在浏览器里，企业边界守在边界上而入口在一台不属于自己的笔记本上。

另一条主线是这些错位都不产生告警——从外面看，什么都没坏。

对企业而言，本周期要补的三门课是：把每一道控制点的假设位置写下来并核对它是不是真的在那里，把第三方与外包侧的入口纳入同一份资产清单，以及把招聘与面试流程当成一条有攻击面的业务线来管。