2026 年 7 月漏洞：先修什么，为什么

1 5.3 分的漏洞，为什么要先修

如果只修高分漏洞，Cisco Secure Firewall Management Center 的 CVE-2026-20316 很容易留到后面。它只有 5.3 分，却已经被用于攻击：系统中的低权限静态账号能让远程调用者访问敏感数据。Cisco 还指出，攻击者可以把它与其他 FMC 漏洞组合提权，因此将公告严重性定为 High。分数描述的是一组给定条件下的后果，管理系统在你的环境里能做什么、攻击者是否已经在用这条路，还得单独看。

七月这批漏洞，我建议先处理已经被利用、而且在本地实际可达的管理接口、构建服务和公开站点，并同步检查受侵情况。Cisco FMC 要限制管理面并安装本分支热修复；TeamCity 要更新服务器，同时查构建配置、凭据和产物；受影响的 WordPress 站点要更新核心并检查暴露期间的改动。浏览器、内核和业务依赖继续按各自的更新安排推进。分支版本、临时措施与恢复限制放在下面的修复资料，方便直接核对自己的产品。

这个顺序来自同一批记录的比较。七月共公开 9,808 条 CVE 记录，原快照中仍有效的有 9,763 条；其中进入 CISA 已知利用目录 KEV 的数量，从 8 月 4 日的 14 条增至本次读取的 9 月 11 日目录中的 21 条。下文把评分固定在 8 月 4 日，检查当时会漏掉谁；修复资料则复核到 9 月 13 日 01:27（UTC+8）。这样既能重看当初的排序，也不会拿旧版本指导今天的更新。

排好先后只是开始。Gitea 修复后，无权用户的请求仍应成功，只是不再返回私有仓库字段；WordPress 要让两种输入形式经过同一套整数转换；ANGLE 则要记住已经切走、但仍在使用缓冲区的对象。接下来先看评分遗漏，再沿这三个补丁解释：为什么“已更新”和“问题确实修好”之间，还差一次针对性的检查。

zgrep "package_info.*license" /var/log/messages*

2 两种评分分别漏掉了谁

先比较两种筛选方法。对同一批 9,763 条记录，分别取最高保留 CVSS 不低于 9，以及 EPSS 不低于 0.10，再看它们覆盖多少条同日 KEV。这里的阈值是本文选来比较的两个切点，不是给所有公司的默认策略。CVSS 使用各来源保留分数的最大值，包含不同版本的 CVSS；它能复现旧账本的排序，却不能统一署名为“NVD 评分”。EPSS 则采用 2026 年 8 月 4 日的分数。FIRST 的定义是未来 30 天在野利用的概率估计，每天更新。

CVSS ≥ 9 留下的四个空缺是 DD-WRT CVE-2021-27137、SonicWall CVE-2026-15410、Cisco FMC CVE-2026-20316、Microsoft CVE-2026-56155。把门槛降到 7，选集扩大到 5,741 条，Cisco 仍然在外面。EPSS ≥ 0.10 漏掉的是 Arista CVE-2026-16812、Cisco FMC CVE-2026-20316、Microsoft CVE-2026-56155 与 CVE-2026-58644，以及 Langflow CVE-2026-9198。即使降到 0.01，Arista 与 Cisco 依然未被选中。这意味着已知利用信息需要直接参与处置，不能再附加一个分数门槛才允许它进入紧急队列。

两个较高阈值的选集有 16 条交集，合并后为 1,453 条，覆盖历史 KEV 的 12 条，仍漏掉 Cisco FMC CVE-2026-20316 和 Microsoft CVE-2026-56155。多加一个评分选集，只比 CVSS 单独选集多出六条。附件还给出前 14、22、100、500、1,447 条的等数量排序。取前 100 条时，CVSS 覆盖三个历史 KEV，EPSS 覆盖十二个。CVSS 的前百切点是 9.9 分，共有 102 条并列，程序用编号字典序选择其中一部分；这些并列记录没有 KEV，更高分的 89 条包含三个 KEV，因此改变并列顺序会换掉部分入选者，却不会改变这里的三条覆盖数。没有资产与处理成本数据，不能把“同样一百个编号”叫作“相同预算”，更不能据此声称节约了多少工时。

这次比较的结果很明确。在这一天的队列里，两种分数单独使用都会排除已经有利用记录的对象，EPSS 能以较短选集覆盖其中较多项。它们没有测出下一月预测准确率。KEV 是已确认利用的目录，未收录记录的实际利用状态并不完整；同日 EPSS 又可能已经吸收了相关公开信号。要测预测，应先冻结分数，再观察此后的 30 天，并处理观测来源的覆盖偏差。本次新增的七条 KEV 是后续登记变化，也不等于七次攻击都发生在分数冻结之后。

WordPress 还说明了一个分数背后的条件问题。CVE-2026-60137 的 CNA 给出 CVSS 3.1 的 5.9，CISA ADP 给出 9.1，NVD 当前记录同时保留这两行来源。前者向量采用较高攻击复杂度和机密性影响，后者采用较低复杂度并包含完整性影响。真正影响站点处理顺序的，是本地是否有入口把外部参数交给查询，以及是否存在另一项 REST 路由组合条件。分数差异值得调查，不能通过挑较大或较小的一行把这些条件省掉。

3 Gitea 软件包响应里的仓库权限

设想一个普通的依赖安装过程。开发者有权读取团队发布的软件包，但没有权限访问制作这个包的私有仓库。Gitea 的 Composer 接口需要返回版本、下载地址等元数据；如果软件包关联了仓库，响应还可以带上 source.url、source.type、source.reference。漏洞就发生在增加这组字段时。读取软件包所需的权限已经满足，程序却没有继续核对关联仓库是否也应对这个请求者可见。这是两个资源之间的权限传递错误，实际可核对的后果是仓库地址、类型与版本引用暴露。

沿调用过程看，PackageMetadata 第 126–155 行从路径取得软件包名，查版本，再取得包含关联仓库的 descriptor，交给 createPackageMetadataResponse，最后通过 ctx.JSON 返回。修复前的api.go 第 118–130 行只检查 pd.Repository != nil，随后把仓库的 HTMLURL()、固定的 git 类型与软件包版本放进 Source。对象存在这一条件，只能说明程序找到了仓库，无法回答调用者是否有权看到它。

左右滑动查看图中说明。

修复提交 5d87a70把请求上下文传入响应构造函数，再调用 GetDoerRepoPermission(ctx, pd.Repository, ctx.Doer)。权限查询失败时记日志；只有 HasAnyUnitAccessOrPublicAccess() 为真才填入 Source。这个条件包括任一仓库单元的访问权，或符合公开访问条件；它没有把授权范围收窄到源码读取。其余软件包字段仍按原流程构造，因而客户端可以继续读取允许访问的包。

这也决定了验收不能只盯 HTTP 状态码。上游第 249–275 行回归测试把软件包关联到私有仓库，先用有权用户获取响应，检查 URL、类型和引用都保留；再换无权用户，仍预期 HTTP 200，但三个字段全部为空。把后一请求变成 403，也许阻止了信息暴露，却可能破坏原本允许的软件包读取。一个合格修复需要同时保住权限限制和正常依赖安装。

在实际 Gitea 部署中，先找出使用 Composer 仓库关联的包，按有权、无权两种账号复查这三项字段，再测试正常下载。需要临时缩小暴露时，可限制相应软件包接口的调用范围或暂时取消敏感仓库关联；这会改变消费者获得的信息，需与包维护者确认。本文从源码和上游断言确认了返回信息的变化，没有运行完整 Gitea 集成环境，也没有证明无权用户因此能够克隆私有代码。若元数据中包含内部地址或命名信息，应按实际暴露内容处理，而不直接宣告源码失窃。

这个案例还改变了“七月新漏洞”的理解。对应修复在 5 月合并，1.26.2 的安全公告在 6 月发布，CVE Program 到 7 月 3 日公开该记录。七月队列因此包含已经有补丁一段时间的问题。补丁检查应直接看运行版本与对应权限行为，不能从月报日期推算系统只暴露了一个月。

4 WordPress 字符串跳过了整数转换

WP_Query 是 WordPress 构造内容查询的核心类，author__not_in 用于排除指定作者。调用方要排除作者 3 和 7，可以把值作为数组 [3, 7] 或字符串 "3,7" 传入。正常值最后可能形成相同的 SQL，测试页面看起来也一样；它们经过的安全处理却不同。数组的每个成员会被转成非负整数，字符串则跳过这一分支，在末尾被强制转换成一个单元素数组，再拼进查询。

这个差别可以在修复前第 2399–2406 行直接看到。is_array 限定了 array_map('absint', ...) 的执行条件，后面的 implode 却接受强制转换后的所有值。字符串如果携带 SQL 语法，它仍以文本形式进入 NOT IN (...)。下面是原分支的简短节选，省略了排序与其他查询条件；它用于解释类型分叉，不是一段可独立运行的漏洞测试。

if ( is_array( $query_vars['author__not_in'] ) ) {
    // array_map( 'absint', ... )
}
$author__not_in = implode( ',', (array) $query_vars['author__not_in'] );

后果还要沿着字符串走到消费者。在同一类中，$where 加入完整 SELECT 的 WHERE 部分并写入 $this->request；查询分支再通过$wpdb->get_col 或 get_results执行。危险条件是可控制输入抵达了这个查询构造过程。仅仅安装了一个有缺陷的函数，尚不足以说明任意匿名 HTTP 请求都能调用它；插件、主题或其他核心路径怎样传参，需要继续查调用者。

左右滑动查看图中说明。

7.0 分支修复 74d37a3把入口收敛到 wp_parse_id_list。它先由wp_parse_list 拆分逗号或空白分隔的字符串，并筛掉数组中的非标量成员，然后统一对成员执行 absint 和去重。调用方确认列表非空后排序、拼接整数，同时把规范化结果写回查询变量。这次修复还维持了等价查询的稳定表示，有助于避免同一组 ID 因输入顺序或重复值形成不同的查询状态。

修复后的函数采用转换语义，不能把它描述成严格的“非数字全部拒绝”。例如负数会被取绝对值，数字前缀字符串的结果取决于 PHP 整数转换；上层业务若需要拒绝非法作者 ID，仍应在自己的接口检查。回归应同时覆盖数组、逗号字符串、空白分隔、重复项、空列表和混合成员，检查最终查询只包含预期整数，再确认合法查询返回相同内容。用一组攻击字符串得到错误页面，只能说明那一次请求失败；它可能根本没走到这个分支。

已知利用让这项核心更新进入前列，而两项漏洞的组合条件决定调查范围。另一个官方公告说明 REST 批处理路由解释冲突与查询缺陷可以组合成代码执行。这里深入追踪的是 SQL 构造补丁，未重新实现完整组合利用链。站点维护者应检查实际开放的 REST 路由与自定义查询入口；开发者则要检查所有接受 author__not_in 的封装，确保类型转换、权限与业务合法性各自有明确位置。

因此，恢复一个 WordPress 站点至少有两件独立的事。核心程序达到当前支持版本并通过相关业务查询回归；曾经暴露的实例完成文件、账号和发布记录检查。更新包可以修复查询构造，已经被改写的主题、植入的文件或盗取的凭据需要另行处置。7.0.2 只记录这次历史首修；随后 7.0.3、7.0.4 又发布安全更新，现在官方默认已经是 7.1，恢复介质也应跟上。

5 ANGLE 暂停后的缓冲区仍在使用

ANGLE 将图形 API 调用转换为不同平台的图形后端操作。这里涉及的 transform feedback 会把着色器产生的数据写入缓冲区。程序可以开始记录、暂停、切换当前对象，再恢复记录；暂停期间对象仍处于活动生命周期，绑定的输出缓冲区仍被它使用。旧检查过多依赖“当前选中对象”的绑定状态，导致另一个仍活动、但已不在当前上下文中的对象被遗漏。这属于对象状态管理问题，公开公告把其潜在影响列为沙箱逃逸。

补丁新增测试给出了具体顺序。TF1 进入活动状态，以 B 为输出缓冲区，随后暂停；程序选中 TF2，再把同一个 B 绑定到 GL_ARRAY_BUFFER。这个操作没有结束 TF1，B 与 TF1 的活动关系仍在。如果接下来的校验只看 TF2，便可能放行对 B 的重新分配、写入或映射。最关键的一步就是“当前对象换了，但旧对象的使用关系仍然存在”。检查 buffer 的长度或绑定目标都不足以恢复这项信息。

修复提交 ee21230同时链接公开记录中的 issue 492218546，并把活动计数放到 Buffer。TransformFeedback.cpp 第 139–207 行显示，begin 对所绑定的缓冲区增加活动计数，end 才减少；pause 仅改变暂停标志。Buffer.h 第 193–214 行把原有同时绑定冲突与活动计数检查合并。因此，即便 TF1 不再是当前对象，B 仍能回答自己是否被活动记录使用。

左右滑动查看图中说明。

新的状态要被实际入口消费才有作用。validationES2.cpp 第 3685–3709 行在取得待操作缓冲区后，对 WebGL 或 hardened context 调用 hasTFBBindingConflict()，冲突时返回 GL_INVALID_OPERATION。补丁同时修改了 BufferSubData、映射、复制和多个其他消费者，避免只有一种修改方式读取新状态。与之对照，父提交的校验仍依赖旧绑定冲突检查。修复把活动关系记在缓冲区上，再让各个修改入口读取这项状态。

上游新增 TransformFeedbackBufferModificationWhileNotCurrent，按 TF1 开始、暂停、绑定 TF2 的顺序，检查 glBufferData、glBufferSubData、glMapBufferRange 都得到预期错误。另一个ChangeBufferWhilePaused 测试保留了正常开始与绘制，拒绝暂停时修改，再确认恢复后的绘制能够继续。前者检查绕过当前对象的路径，后者保护合法生命周期，两者承担不同工作。

这是源码与上游回归断言的分析，本次没有运行完整 ANGLE 图形后端，也没有复现沙箱逃逸。Chrome 公告给出的受影响边界为 150.0.7871.46 以前，Chromium 严重性为 High；当前 CVE/NVD 数据中的 9.6 分来自 CISA ADP。企业客户端应该完成对应渠道的浏览器更新和重启，并检查仍在线的旧进程。若暂时停用 WebGL 来减小图形入口，需要验证策略确实作用于目标应用，并接受三维可视化等功能受损；这一措施不能覆盖该应用的所有本地图形使用方式。

这项 bug 对自研程序更直接的启发是，只在当前句柄或当前请求上保存限制，可能遗漏仍在后台存活的对象。检查异步任务、缓存、文件映射和图形资源时，应问活动关系由谁持有、在哪一步撤销、所有消费者是否读取同一状态。这里可以迁移的是审查问题与状态测试方法；不能因为另一个系统也有暂停或切换功能，就认定它存在相同漏洞。

6 记录怎样分组，会改变你看到的结论

按原始账本归类，三类问题占全部有效记录的 61.8%，分别是权限与对象绑定 2,449 条，内存与生命周期 1,817 条，解释器边界 1,770 条。这些数来自记录级归类，计算没有变；但据此建议组织优先投入哪一类工程改造，依据不足。只移除 Oracle 的 1,108 条记录，剩余 8,655 条的前三名就变成内存 1,817、解释器 1,761、权限 1,615。权限类从第一降到第三。一个发布方的样本组成已经足以改变排名，全年研发预算显然还需要本地代码、资产、缺陷与事故数据。

按记录里明确的厂商与产品组合复算，也能看到差异。Linux 837 条中，内存类 443 条、状态与时序 207 条；Chrome 487 条中，内存类 187 条、请求与网络信任 132 条。一个 CVE 可同时提及多个 Windows 版本，因此产品分组之间重叠，不能把每组数量相加后称为独立漏洞总数。附件保留确切产品标签和组内类别计数，没有把别名自动归一成我们无法验证的资产。它适合帮助读者选取与自身技术栈相关的部分，再去阅读具体原因。

补丁批次还需要更强的关联证据。WordPress 的两个编号共同进入 7.0.2 核心发布，这一组可以在该分支合并为一个更新动作，同时保留各自受影响条件。只做这项经过公告确认的归并，历史 KEV 从 14 个编号变成 13 个分组；CVSS ≥ 9 覆盖 9 组，EPSS ≥ 0.10 覆盖 8 组，原来遗漏的四项与五项保持不变。我们没有把其余 9,761 条强行配对，因而这个结果只检查一组可靠关系，无法估算全月实际变更单数量。

Oracle 的季度 CPU 则是更新计划入口。七月 21 日队列里有 1,097 条 Oracle 记录引用它，但涉及众多产品、组件、分支和安装包；同一份季度公告不足以证明它们只需要一次安装。当前七月 CPU 页面列出 1,448 个新安全补丁，旧稿曾记录 1,449，本次正文采用当前页面，v1 原始快照保持不动。读者应沿自己产品的风险矩阵和补丁可用性文档核对。两个 Coherence 编号即使描述相同，也只能说明公开文本相似，无法据此合并为同一个根因。

这一分组问题与早期实证研究中的困难相通。The Attack of the Clones区分共享代码、受影响版本和实际安装状态；Allodi 的漏洞交易研究也区分编号、利用条目和共享工具包。本文采用的是这种“先确认观测单位”的方法，没有借用这些历史样本的效果量。SOSEC 能测量公开记录及其关系，企业真正的修复负担还取决于一份更新要覆盖多少实例、停机代价、兼容性和回滚约束。

收录时钟同样影响数量。本文按 CVE Program 的 datePublished，取 UTC 2026 年 7 月 1 日零时至 8 月 1 日零时之前的记录，固定在提交 a373dbeddf97334f61e32d748cc24096303612ab。编号中的年份可以对应编号分配或公开的年份，不能直接当成记录里的预留日期；七月有效记录有 236 个编号早于 2026 年，按 CVE-2026-* 抓取会漏掉它们。NVD 同窗接收口径曾得到 9,919 条，多出 111 条，旧账本分析确认其 CVE Program 公开时间在七月之外。公开、接收、补丁发布、实际利用是不同事件，日历上的相近也不自动构成因果。

最后需要把“读过”说准确。v1 保存全部记录的字段复核和 9,763 条原因归类，其中 377 条另有一手公告、补丁或源码深查标记；只有 15 条被标为 SOURCE_TRACED，5,084 条为 SPECIFIC_RECORD，2,573 条为 DESCRIPTION_SPECIFIC，1,808 条为 BROAD_RECORD，283 条未确定。类别标签反映当时材料和审阅判断，不代表每项都完成了源码根因验证。本次新增三个详细源码案例、分组复算与当前状态复核，没有把旧标签整体升级。354 条缺少 CVSS 的记录也继续保留，缺值不按零分处理。

7 更新之后，检查什么

假如你同时维护公网 TeamCity、带自定义作者筛选的 WordPress，以及供内部开发者使用的 Gitea，三者都需要更新，但恢复工作的重点不同。TeamCity 要查构建权限和产物是否被改动；WordPress 要找出外部输入抵达查询的路径，并检查站点文件与账号；Gitea 要比较不同账号得到的 source 字段，同时确认依赖仍能正常安装。内部部署会改变可达范围，不会自动消除其中的权限错误。

对三项源码案例，最小验收分别是同一个包的有权与无权访问保留不同字段；同一组作者 ID 的不同输入形式经过统一整数规范化且业务结果正确；在 WebGL 或 hardened context 中，活动、暂停、切换对象后的缓冲区修改被拒绝，合法恢复继续工作。前两项适合应用维护者在授权测试环境执行，ANGLE 的源码回归适合浏览器或嵌入式图形组件维护者。普通客户端管理员以受支持渠道、包身份、重新启动后的实际版本及业务页面回归验收，不需要向公网发送漏洞请求。

这批记录里，Cisco 的 5.3 分最值得记住：只按高分筛选，连已经被利用的管理入口都可能漏掉。把已知利用和本地可达性放进修复顺序，再用具体机制决定验收内容，才能知道一次更新解决了什么。余下的兼容性、受侵范围和恢复路径，需要在自己的系统上查清；它们决定何时可以恢复业务，也决定哪些调查还不能结束。