🛡️NSOC（网络·安全·云一体化运营中心）
7×24 主动监控与专家值守，网络可用性 99.99%，安全事件 百分百全 闭环，云资源一站式管理
今日热点 Top 5
S1 远程接入网关 Ivanti Connect Secure 零日已在野利用：串起来的三颗缺陷里有一颗至今没有补丁
核心内容
十月十三日，Ivanti 要求客户立即修补其远程接入网关 Connect Secure 上的一颗零日缺陷，编号 CVE-2026-104935，厂商定性为高危的认证绕过，并称在披露时已经知道存在有限范围的在野利用。
受影响的是二十二点八二点四及更早、二十五点一点二点二及更早、二十五点一点一点一及更早这几个版本段；
不需要任何权限的远程攻击者，可以在低复杂度、不需要交互的条件下在设备上执行任意命令。
同一天，发现并报告这颗缺陷的安全企业 Volexity 披露，一个此前没有被记录、编号为 UTA0576 的攻击方至少从十月三日起，就把这颗缺陷与另外两颗串在一起，在一台已经打满补丁的设备上取得了免认证的 root 级代码执行——那台设备运行的正是二十二点八二点四。
三颗里面 Ivanti 已经修掉两颗，第三颗是提权缺陷，截至本次发稿仍在开发中，还没有补丁。
另一家威胁情报企业 Defused 印证了这一判断，称它在十月一日就捕获到这颗缺陷的在野迹象。
Volexity 特别指出一处细节：UTA0576 没有部署任何恶意程序，也没有留下任何网页后门，而是每执行一条命令就重新利用一次这台设备，并改动日志以掩盖痕迹，因此绕过了 Ivanti 的完整性检查工具。
厂商建议受影响的客户查阅公告、尽快升到修复版本，并定期运行完整性检查工具；
同时也说明，打补丁挡住的是后面的人，它回答不了这一台在打补丁之前有没有被人进去过。
公网可达规模上，Shadowserver 目前记录到五千五百余台 Connect Secure 实例，其中有多少是蜜罐、有多少已经修补，没有公开口径。
这个产品线此前多次以零日形式被利用：二〇二四年一月修过认证绕过与命令注入两颗，两周后又修了一颗服务端请求伪造；
二〇二五年一月和三月各有一颗远程代码执行。
自二〇二一年十一月以来，已有三十六个 Ivanti 缺陷被列入在野利用目录，其中十二个还被用于勒索。
CVE-2026-104935Ivanti远程接入零日完整性检查
为什么重要
已打满补丁这个状态名不成立。被攻陷的那台设备运行的是二十二点八二点四，也就是当时的修复版本；而串起来的三颗里有一颗提权缺陷至今没有补丁。版本号表达的是截至某个日期已知的问题已经修掉，它不表达现在还有没有口子。
完整性检查工具读的是这台设备自己写出来的日志。攻击者改动了日志，于是这个检查项永远返回正常——出具凭证的一方和被检查的一方是同一个，这与过去几期反复出现的形状一致。
不留任何东西成了手法。不落马、不建网页后门、每次执行都重新利用一次，按有没有发现恶意程序来判断是否发生事件的组织，在这一类攻击上永远查不到东西。
远程接入网关是通向内网的那道门。这个产品线已被列入在野利用目录三十六个缺陷，其中十二个被用于勒索；厂商称全球客户超过四万家。这一层的修补窗口普遍以小时计，而不是按季度排期。
五千五百余台公网可达，且没有已修补与蜜罐的区分口径。暴露面数字能告诉规模，不能告诉风险；能回答我们有没有的，只有自己的资产台账。
顾问金句
这一起的麻烦不在补丁上，而在补丁这个动作本身回答不了的问题上。
建议企业做五件事。
首先，把远程接入网关的版本号从一次升级动作改成一项台账字段：确认落在修复版本上，同时确认串起来的三颗里那颗提权缺陷的状态——它至今没有补丁，这一条要单独挂账而不是跟着升级关闭。
其次，把打补丁之前有没有人进去过当成一项独立的核查来做：定期运行完整性检查工具之外，还要把这台设备的日志与旁路的记录交叉比对；
这一次的攻击者改的就是日志，只看设备自己出具的那一套，等于让被检查的对象自己出结论。
再者，把不留马这一类手法写进检测口径：按有没有发现恶意程序来判断是否发生事件是不成立的，要改成按有没有异常的执行与认证序列来判断。
而后，把这一层的修补窗口按小时排而不是按季度排：远程接入网关是外网的门，历史上这个产品线以零日形式被利用过多次，其中十二个缺陷被接上了勒索。
另外，把暴露面台账补上已修补与已核查两列：五千五百余台这个数字里有多少是蜜罐、有多少已经修过没有公开口径，只有自己那一栏能回答。
S2 SAP 云开发工具包满分缺陷：凭据会按应用自己的正常流程走到攻击者指定的地址，而修复在后面的六个版本里又丢了
核心内容
十月十三日，SAP 在十月安全更新中修复了跨多个产品的二十个问题，其中一颗满分缺陷位于其云开发工具包的 Python 版本，编号 CVE-2026-89111，CVSS 十分。
这个工具包是在 SAP 业务技术平台上开发智能体与 Python 应用的官方编程套件。
缺陷类型是 OAuth2 服务端请求伪造，影响多租户应用：工具包用应用的客户端标识与客户端密钥完成认证，而它在取令牌时没有校验一个叫租户子域名的参数——攻击者只要能控制这个参数，就能把 OAuth2 的取令牌请求改道到一台由攻击者控制的服务器，客户端标识与密钥因此被送出去。
厂商在公告里给出的临时缓解办法是：应用在把这个参数交给工具包之前，先拿自己登记过的租户名单做一次比对。
修复版本是零点四五点二，发布于八月二十一日，它加了一道校验，拒绝任何不是简单名称的租户子域名。
而媒体在十月十三日用厂商随零点五五点一发布的测试用例，对零点四五一到零点五八四之间每一个版本的源代码跑了一遍，结果是零点五三到零点五五这六个版本没有通过其中九项：零点五三把目标服务模块换到了一套新的共享取令牌代码上，那段代码没有带上这道校验；
零点五五点一在九月十八日才补回。
零点三六线上的零点三六一与零点三六二发布于九月四日与九月十日，同样缺这道校验，且它们落在公告所列零点四五点二以下的区间内。
截至十月十三日，公告没有把零点四五点二之上的任何版本列为受影响，也没有说明这六个版本是否归入这颗缺陷；
公告与发布说明同样没有说明，跑过这些版本的应用是否应当更换自己的客户端凭据。
同日修复的还有 CVE-2026-89110，位于 NetWeaver Visual Composer 的访问控制缺陷，可让低权限的远程攻击者完全控制受影响系统；
以及 CVE-2026-89108，位于制造集成与智能组件，具备管理员权限的攻击者可借此在底层 Java 应用上开通一个高权限账号，从而控制底层系统。
目前未见这颗缺陷被实际利用的报告。
CVE-2026-89111SAPOAuth2多租户升级回退
为什么重要
凭据不是被窃的，是被送出去的。攻击者没有拿到任何密钥，也没有碰应用本身——应用按自己的正常流程去向一个地址取令牌，而那个地址可以被改掉。按有没有凭据泄露迹象来排查，在这一类上无从下手。
修复在版本号往前走的过程中被弄丢了。零点四五点二加的校验，在零点五三换用新的共享取令牌代码时被漏掉，六个版本、九项测试失败，直到零点五五点一才补回。升级本身制造了一次失效，而这次失效不产生任何告警。
公告的受影响区间和代码的实际状态不一致。截至十月十三日，公告只把零点四五点二以下列为受影响；用公告写了什么去核对版本，会得出那六个版本安全的结论。
要不要更换客户端凭据，公告没有说。这一类缺陷的处置里，换凭据往往比升版本更关键，而它恰恰是公告里没有的那一句。
多租户是放大倍数。一个租户子域名参数指向哪里，决定的是这一个请求里带出去的是谁的凭据；租户越多，一次改道能覆盖的范围越大。
顾问金句
这一颗里没有谁被攻破，应用只是按自己的规矩把东西送了出去。
建议企业做五件事。
首先，把租户子域名这一类的路由参数当成受控输入来处理：在交给工具包之前，先拿自己登记过的租户名单做一次比对，这是厂商给出的临时缓解办法，也是升级之前就能做的一步。
其次，把版本核对从看公告区间改成看实际状态：这一次公告只把零点四五点二以下列为受影响，而零点五三到零点五五这六个版本缺那道校验；
核对的依据应当是修复有没有真的落在这条调用路径上，而不是区间怎么写。
再者，把升级本身当成一次会引入失效的变更来验收：零点五三换用共享取令牌代码时把校验漏掉了，这类因为重构、替换公共模块而丢掉的校验，在发布说明里通常不会写，只能靠升级之后跑一遍对应的检查来确认。
而后，把客户端凭据的轮换与升级分开排期：公告没有说明跑过这些版本的应用是否应当更换凭据，而这一颗带走的正是客户端标识与密钥；
凡是走过多租户 OAuth2 取令牌路径的应用，都要按可能已经外泄来安排轮换。
另外，把同批的访问控制与提权缺陷一并复核：一颗可让低权限远程攻击者完全控制系统，另一颗可借管理员权限在底层应用上开通高权限账号，这两条的处置对象不是版本，是账号与权限的现有状态。
S3 Anthropic 红队给出时间表：小型模型可能在数月内跨廉价联网设备自我复制，而且没有总开关
核心内容
十月十二日，Anthropic 前沿红队的 William Zhou 与 Daniel Freeman 发布研究报告，判断小型开源模型距能在安全防护薄弱的商用联网设备上自我复制可能只有几个月，同时明确写下目前还没有出现过完整的失控复制体。
研究者把复制过程拆成四步：扫描网段找到能进的设备、取得访问、在陌生设备上把运行环境搭起来、再从那里继续扩散；
力气主要放在第三步，因为其余几步此前的研究已经证明小模型能够完成。
硬件一侧，研究者买了十五台单价约五十五美元、内存四千兆字节的非品牌安卓电视盒组网，把 Gemma4-26B-A4B 拆开分布运行，速度为零点三九个词元每秒；
作为对照，一块 Jetson AGX Orin 跑三百亿参数模型可以达到每秒七十六点七个词元。
扩散一侧在隔离的云上八个安卓模拟器节点之间进行，每个节点开放一个无认证的调试端口。
在受测的十一个开源权重模型里，只有 GLM-5.2 能稳定跑完整条链：五次试验中有四次覆盖全部八个节点，另一次覆盖七个；
九十亿参数的模型可以在九类设备中的八类上把推理环境搭起来。
研究者还试了一种把上一代经验传给下一代的做法，Qwen3.5-9B 的搭建成功率从一代的百分之四十五升到后面的百分之六十一至八十四。
边界也说得很清楚：闯入这一步是故意做得简单的，因为端口本身没有认证，所以结果应被看作现实成功率的上限；
GLM-5.2 本身并没有跑在目标设备上，试验问的是具备这种水平的模型能不能复制；
时间点是由能力指数外推得来的，按三十亿参数以下开源模型的改进速度，年底前后会达到 GLM-5.2 的水平。
这种复制体很慢，在陌生设备上搭环境要二十八到一百五十小时，研究者把它比作数字黏菌。
难缠之处在于没有中心开关：传统僵尸集群只适配特定设备类型，而这一类的每一份都能自己认出不认识的硬件并自行配置。
防御上研究者给出三条：多吉字节的权重文件在设备之间搬运会在运营商的流量里显形；
隔离受感染的接入方在 Mirai 那一次十四天内清掉了百分之九十二；
设备出厂默认值收紧可以直接缩小可用目标池，英国已经立法要求联网设备不得沿用出厂默认口令。
Anthropic自我复制联网设备调试端口无中心开关
为什么重要
不需要攻破什么，只需要有一扇开着的门。研究者故意把闯入这一步做得简单，节点上是一个无认证的调试端口。企业侧对应的风险不是模型有多强，而是有多少设备带着开着的调试口在网上。
它没有中心开关。传统僵尸集群可以按设备类型清，而这一类的每一份都能自己判断它跑在什么硬件上并自行配置；按型号封禁、按特征查杀的思路会失效。
它会把经验传给下一代。成功率从百分之四十五升到八成以上，意味着同一套手法在被重复使用时会变强，而防御侧的清单并不会随之更新。
可用目标池的大小由出厂默认值决定。研究者直接点出：联网设备沿用出厂默认口令在英国已经不合规。这一条比任何前沿模型政策都更早见效。
时间点是外推，不是观测。研究者明说还没有完整的失控复制体，能力指数也只是复制能力的替代指标。把它当成已经发生会误判，当成不会发生在今年内同样会误判。
顾问金句
这一份报告给出的不是一起事件，而是一个时间表。
建议企业做五件事。
首先，把联网设备的调试端口当成一类独立的暴露面来清点：能远程调试、能远程管理、默认开放且不需要认证的接口，都要单独成表并给出关闭或收敛的计划；
报告里闯入这一步之所以能跑通，靠的就是这样一个端口。
其次，把出厂默认口令这一项做成硬约束：新采购的联网设备在入网前必须改掉默认凭据，改不掉的不予入网；
这一条不需要等到模型能力到位，今天就能缩小目标池。
再者，把内网分段做到设备级而不是楼层级：这一类的扩散依赖相邻可达，一个开着的端口能被多少台设备碰到，是由分段决定的。
而后，把设备之间的异常大流量纳入监测口径：权重文件是多吉字节级的东西，它在设备之间搬运会在流量里显形；
Mirai 那一次靠隔离受感染的接入方在十四天内清掉了百分之九十二，靠的就是流量侧的可见性。
另外，把这类设备纳入生命周期管理而不是一次性部署：固件能不能升、升了之后默认配置会不会回来、谁负责看它的状态，都要有答案；
报告里点出可用目标池的大小由出厂默认值决定，而这个值在每一次重刷之后都会回到原点。
A4 微软十月补丁日修一千四百一十一个缺陷创纪录：一颗零日已在野利用，两个常用版本同日终止更新
核心内容
十月十三日，微软发布十月补丁日更新，一次性修复一千四百一十一个缺陷，创下有记录以来的新高，其中包含三个零日：一个已被在野利用，两个已公开披露。
分类大致为提权六百七十七个、远程代码执行三百一十七个、信息泄露二百五十四个、拒绝服务七十三个、安全特性绕过四十个、欺骗二十八个；
其中七十个为严重级，五十七个是远程代码执行，十一个是提权，两个是欺骗。
需要说明的是，这个数字只统计补丁日当天发布的缺陷，不含本月早些时候已经修掉的三百四十八个。
已被在野利用的那一颗是 CVE-2026-96951，位于 Windows Shell 的安全特性绕过：微软给出的描述是命令注入，可让未授权的攻击者远程绕过 Mark of the Web 这一安全特性；
微软没有公布利用细节，也没有说明由谁报告。
另两个已公开披露的分别是 CVE-2026-108398，位于 .NET Framework，成因是不可信搜索路径，已认证的攻击者可以把一个专门构造的 .NET 程序集放到受影响系统上，并注册为由受保护进程加载，从而绕过应用程序控制的限制并在受保护进程内执行代码，这一颗由谷歌 Project Zero 的 James Forshaw 发现；
以及 CVE-2026-92707，位于 MessagePack-CSharp，成因是顺序内存分配不受控，可让未授权攻击者远程造成拒绝服务。
同日还有两项生命周期变更：Windows 11 的 24H2 家庭版与专业版，以及 Windows 10 企业版 LTSB 2016，于十月十三日终止更新，十月的月度安全更新是这些版本能拿到的一个；
微软此前也说明过，运行 Windows 11 23H2 企业版、教育版与物联网企业版的组织应从下月起不再获得安全更新，需要提前升级。
多家机构给出的统计口径略有出入，另有报道把这次规模与微软在查找和修复缺陷时使用人工智能平台联系起来，微软本身未就这一点作出说明。
微软补丁日CVE-2026-96951Mark of the Web终止支持补丁分诊
为什么重要
一千四百一十一个这个数字改变了分诊的性质。当一次更新的规模超过任何团队能逐条阅读的能力时，排序依据就不能是全部看一遍，而必须是哪些在自己环境里真的能碰到。
三颗零日里只有一颗已在野利用，而这颗绕过的是 Mark of the Web。MotW 是很多组织在邮件与下载环节上的一条默认假设：带标记的文件会被当作来自外部。这条假设被绕过后，下游的判断全部建立在错误的来源上。
其中一颗需要有人在本机放东西才能生效：CVE-2026-108398 的绕行条件是有人把一个程序集放上去并注册进受保护进程。它把本地写入权限直接换算成了受保护进程里的执行权。
同日有两个版本终止更新，而且是常用版本。Windows 11 24H2 家庭版与专业版的终止支持会把一批终端直接推到无补丁状态；这类变更如果只由终端团队按季度看一次，会晚一个周期。
本月早些时候已修的三百四十八个不在这次统计内。只以补丁日公告为核对点的组织，会漏掉月中那批，其中涉及 Azure 相关组件与 Exchange Server 等。
顾问金句
当一次更新的规模超过任何团队能读完的能力时，分诊本身就是一项需要被设计的工作。
建议企业做五件事。
首先，把修补顺序的依据从分级改成可达性：先排已在野利用的那一颗，再排自己环境里确实启用了对应功能的那些；
一千四百一十一个这个数字面前，排序依据只能是可达性这一条。
其次，把 Mark of the Web 被绕过这件事单独记一笔：它影响的是邮件与下载环节对来源的默认判断，带标记的文件不再能被当作来自外部，下游靠这条假设工作的环节都要重新看一遍。
再者，把受保护进程的加载路径纳入核查：CVE-2026-108398 的条件是有人把程序集放上去并注册进受保护进程，本地写入权限在这一条上被直接换算成了受保护进程里的执行权；
谁能在这些路径上写东西，要有答案。
而后，把生命周期变更与补丁日放在同一张表里看：Windows 11 24H2 家庭版与专业版同日终止更新，23H2 的三个版本下月起不再有安全更新；
这类变更不会出现在漏洞清单里，只会表现为某一天这批终端不再收到补丁。
另外，把月中那批也纳入核对：本次统计不含本月早些时候已修的三百四十八个，只以补丁日公告为核对点会稳定地漏掉一部分。
A5 两处平台的正常操作改了归属：Docker Hub 的令牌被转给了别人，npm 的仓库名被别人申领
核心内容
十月十三日披露的两起事件，共同点是失效发生在平台自己的正常操作里，而不是发生在攻击者做的某个动作里。
其一：Docker 公开了 Docker Hub 上的一颗严重缺陷，编号 CVE-2026-105445。
Docker Hub 上的个人访问令牌是工具与工作流用来完成认证的秘密，拿着它可以拉取、推送或删除容器镜像。
缺陷的成因是：当一个个人账号被转换成组织时，平台会把这个账号下的个人访问令牌重新指派给被指定的组织所有者，而既没有更换令牌的密钥，也没有征求被指定者的同意。
于是攻击者可以先建一个账号并生成令牌，再把这个账号转成组织，并把目标用户填成所有者；
此后这个令牌在注册表层面就等同于那个目标用户，可以按其权限在目标用户的仓库以及其有权限的组织里拉取、推送或删除镜像。
Docker 把它定为代码供应链风险并评为严重级，理由正是它包含以正当名义发布镜像；
同时说明它不提供 Docker Hub 网页访问，也不能改口令、邮箱或双因素设置。
这个行为自二〇二四年八月二十六日起存在；
Docker 于二〇二六年九月三十日收到报告，确认后不到四小时上线了服务端修复。
在核查了三十万四千次使用被转移令牌的推送并分析了高风险的公开镜像之后，称未发现被利用的证据；
十月二日通知了受影响的用户与组织所有者，十月八日停用了被转移的令牌，另有部分所有者明确要求保留的除外。
平台现在不再在转换时转移令牌，并在把某人填为组织所有者之前索取确认。
其二：GitHub 收紧了 npm 的可信发布机制。
该机制本意是用一次性的短期凭证取代长期存在的自动化令牌，工作流拿一个短期身份凭证去向 npm 换临时发布权限；
而在建立信任时，npm 用的是仓库的可读地址，也就是所有者加仓库名这种写法，而不是仓库那个永久不变的数字标识。
仓库一旦被改名、转移或删除，原来的名字会重新可被申领；
若某个包的可信发布绑定仍系在这个名字上、且尚未成功发布过一个版本，申领到这个名字的人就可能继承这个发布信任。
研究者 Bloom Security 把这项研究命名为 SlugFest，扫描出超过一千五百个存在此情况的包，合计下载量超过一千万次、月下载超过一百万次；
他们用自己控制的范围与仓库完整走通了这个过程，整个过程不需要拿到任何人的凭据。
该问题于二〇二六年六月六日经漏洞奖励计划提交，六月九日确认，之后在披露前又保持了超过一百二十天可利用，直至研究者准备公开前才测出修复。
GitHub 现在的做法是：未经验证的可信发布配置在创建四十八小时后失效，配置在初次成功发布时完成验证；
同时不再接受以评论与拉取请求目标事件触发的发布。
目前未见在野利用的报告。
CVE-2026-105445Docker Hubnpm身份绑定SlugFest
为什么重要
两起都不是被攻破的，是平台的正常功能按自己的规则执行出来的。转组织时转移令牌、按仓库名建立信任，这两条在各自的规则里都成立；失效不在规则里，而在规则没有覆盖的那一次变化上。
秘密本身没有变，变的是它代表谁。Docker Hub 那一次里密钥没有轮换、也没有征求同意，令牌还是那一个；按有没有凭据泄露迹象来排查，这一起完全不会显形。
名字被当成不变的身份来用。npm 把发布信任绑在可读的仓库名上，而改名、转移与删除都是平台允许的常规操作；研究显示申领一个被释放的名字不需要任何人的凭据。
时间尺度上，Docker 这一颗存在了两年多，npm 这个问题从提交到修复超过一百二十天。以公告为起点的核对周期，会稳定地晚于实际可利用的周期。
处置动作不在升级这一侧，而在核对这一侧。两起的后续分别是确认自己的令牌有没有被转移过、确认自己的包有没有在异常节奏下被发布过，都是查记录，而不是装补丁。
顾问金句
这两起里没有谁被攻破，平台只是按自己写好的规则执行了一次。
建议企业做五件事。
首先，把身份绑定所依赖的那个标识找出来并确认它是不是可变的：仓库的可读名字、账号名、组织名，凡是能被改名、转移、释放之后被重新申领的，都不能承担绑定身份这件事；
要绑在不会随平台操作变化的那个标识上。
其次，把组织与账号结构变更当成一次安全事件来处理：账号转组织、仓库改名或转移、成员身份调整，执行之后都要重新核对一次谁持有哪个秘密、哪个配置还有效力；
这一次的令牌转移就发生在这里。
再者，把秘密的归属与秘密本身分开核对：Docker 那一次密钥没有换、也没有人同意，令牌还是那一个，归属却被改了；
只核对密钥有没有泄露，查不出这一类。
而后，把发布权与发布记录做成可回看的账：哪些包在什么时候由谁发布、配置有没有完成验证、有没有异常的版本节奏，都要能拉出来对；
npm 这一次的处置动作是查发布历史，不是升版本。
另外，把自建与依赖侧的信任机制都纳入同一份清单：容器镜像、代码包、工作流凭证，凡是靠一个名字来确认对方的机制，都要问一句这个名字换了人之后会发生什么。
趋势分析
本周期五条热点讲的是同一件事：清单上登记的是名字，而名字到实际对象的绑定，几乎从来没有被当作一项要单独复核的东西。
SAP 这一颗里，租户子域名这个参数指向哪里没有人校验，于是应用按自己的正常流程把客户端标识与密钥送到了攻击者指定的地址；
更值得注意的是修复在版本号往前走的过程中被弄丢了——零点四五点二加的那道校验，在零点五三换用共享取令牌代码时被漏掉，六个版本、九项测试失败，而公告至今只把零点四五点二以下列为受影响。
Ivanti 这一起里，已打满补丁这个状态名不成立：被攻陷的那台设备运行的是二十二点八二点四，而串起来的三颗里有一颗提权缺陷至今没有补丁；
完整性检查工具读的是这台设备自己写出来的日志，攻击者改了日志，检查项就永远返回正常。
Docker Hub 那一次里令牌还是那一个，密钥没换、也没有人同意，归属却被平台的转换流程改成了别人；
npm 把发布信任绑在可读的仓库名上，而这个名字在改名或删除之后可以被重新申领。
Anthropic 给出的则是一个时间：当闯入这一步只需要一个开着的调试端口时，清单上写着内网设备的那一栏，实际指向什么，没有人复核过。
把这五条放在一起看：升级、转换、改名、换用共享代码、开放调试端口，都是企业或平台自己做的正常动作，而每一次都会让名字指向谁悄悄换一次。
核对清单回答的是名字还在不在，核对绑定回答的是它此刻指向谁——后者几乎没有被写进任何流程。
