F5 CVE-2026-94127：认证之前，头字段已经越界

1 先找到真正处理请求的授权服务器

APM 可以在 OAuth 中承担不同角色。充当 Authorization Server 时，它向客户端签发令牌，提供令牌查询、撤销和用户信息等服务；充当 Client 或 Resource Server 时，它使用另一台授权服务器提供的身份信息。F5 当前公告把 CVE-2026-94127 限定在前一种角色：虚拟服务器上配置了 APM 访问策略和相应 OAuth profile。严格只承担客户端或资源服务器角色、没有授权服务器 profile 的部署不受这项漏洞影响。

因此，资产清单上的“使用 OAuth”还不能完成判断。应沿着实际接收流量的 virtual server，查看它绑定的 access profile，再查看其中关联的 OAuth profile。F5 配置文档给出的关联顺序正是 OAuth profile、access profile、virtual server。页面上能看到登录表单，也不代表用户已经通过认证才会进入所有 OAuth 请求处理代码。

默认 UserInfo 路径是 /f5-oauth2/v1/userinfo，它帮助客户端取得用户信息。OAuth profile 的命令参考允许修改 userinfo-url，因此日志搜索和临时规则还要采用本机真实配置的路径。该参考用于核对配置语义，不据此扩大受影响版本到 BIG-IP 14。JPCERT/CC 同时提醒关注其他 URL 路径上的利用可能；只封默认字符串会留下未经核对的入口。

F5 将问题归为数据平面漏洞。正常业务虚拟服务器处理的请求能够触及它，管理页面是否暴露是另一个配置问题。限制管理网有助于减少管理接口风险，修复这里仍须覆盖业务流量中的 OAuth 授权服务。Appliance mode 也在厂商列出的受影响范围内，不能凭设备运行模式排除。

这个范围应逐台核对，包括备用节点及准备重新上线的旧实例。F5 的 OAuth 概述说明同一设备可以承担两类角色，但需要不同的虚拟服务器和主机名。发现一个只做 Client 的入口之后，还要继续检查设备上的其他授权服务。产品名称相同，接收请求的配置可以完全不同。

2 固定缓冲区先接到了未经检查的长度

BIG-IP 的这段实现没有公开源码。以下机制依据 watchTowr 9 月 23 日的原始研究：研究者比较了 21.1.0、build 0.0.38 与 21.1.0.2、hotfix build 0.30.22 中的 tmm64.pgo_use。他们公开的反编译片段显示，程序分配 0x4100 字节的堆缓冲区，使用请求中取得的长度复制 Authorization 头字段，再检查 Bearer 格式。补丁在复制之前增加了 n > 0x4100 的拒绝分支。

0x4100 是十六进制的 16,640。假设分配得到的缓冲区起点为 p，它能够容纳的字节位置就是 p 到 p + 16639。复制 16,641 个字节时，最后一个字节会写到 p + 16640，已经超出这次分配的对象。真实设备上邻近的是什么对象、它什么时候被使用，会影响后果；“复制长度大于对象容量”这一错误本身已经确定。

Bearer 只是 HTTP 认证方案的名称。检查开头是否符合 Bearer 格式，是随后解释凭据的一步。它发生在复制之后时，即使程序最终拒绝了无效凭据，前面的越界写入也已经发生。这就解释了厂商公告中的“未经身份验证”：安全性取决于处理请求的先后顺序，登录策略中配置的身份检查无法替早先的复制操作补上长度判断。

简化后的处理顺序，省略与长度判断无关的实现细节

容量 C = 0x4100
取得 Authorization 字段及其长度 n

修复新增：如果 n > C，拒绝并退出
空字段走已有错误分支
将 n 个字节复制到容量为 C 的缓冲区
检查 Bearer 格式，再继续凭据处理

这里的 n 和 C 是本文为解释关系使用的符号。反编译器给函数和变量生成的名称，不是 F5 发布的源码接口；我们没有取得设备二进制，不能补出官方函数名、源文件行号或引入漏洞的提交。公开片段能够支持复制顺序及补丁判断，完整解析器处理所有头字段变体的行为仍需厂商或持有相应镜像的研究者验证。

左右滑动查看图中说明。

我们用一个不分配目标缓冲区、不发送网络请求的离线模型核对了这个判断。输入长度取 0、6、7、16,639、16,640 和 16,641；前五项没有超过容量，最后一项会在新增分支退出。等于容量的输入不会被这个“大于”判断拒绝，它是否有合法格式还要继续检查。下列代码可独立运行，输出只表示长度关系，不代表 BIG-IP 的真实响应或漏洞复现。

const capacity = 0x4100;
for (const n of [0, 6, 7, 16639, 16640, 16641]) {
  console.log({
    n,
    rejectBeforeCopy: n > capacity,
    bytesBeyondCapacity: Math.max(0, n - capacity)
  });
}

实际危害还取决于堆中被覆盖的数据。watchTowr 在实验中覆盖了相邻对象的回调指针，使后续处理沿被修改的指针转移控制流。其环境中的 SELinux 限制直接启动进程，研究者随后利用可写的 /etc/bigstart/scripts/tmm.finish 生命周期脚本，让进程收尾机制执行修改内容。我们没有复现这条利用路径，也没有测量不同平台或版本的成功率。对响应人员而言，这解释了为什么检查范围需要包括设备文件和启动流程：业务恢复正常后，仍可能留下需要调查的修改。

3 安装包必须核对到完整 EHF 构建

截至 9 月 28 日，F5 为本漏洞列出的修复如下。EHF 是 engineering hotfix，工程热修复。表中完整包号同时是当前公告给出的部署目标和历史首修依据；以后采用更新发行包时，应确认发行说明包含 Bug 2524777 或厂商明确声明包含本漏洞修复。

基础版本相同会掩盖差异。F5 当前 EHF 说明还保留了更早的 17.5.1.9.0.46.12-ENG 和 17.1.3.5.0.1.14-ENG，它们没有被列为 CVE-2026-94127 的修复包。一个仅存储“17.5.1.9”的资产字段，无法区分这些构建。核对时应保存运行版本、hotfix/build、安装镜像名称及对应公告，备用启动卷也要检查。

# 在自己管理的 BIG-IP 上读取运行版本与热修复信息
tmsh show sys version detail

这条只读命令用于查看版本信息。安装准备还需遵循 EHF 说明：将目标热修复及对应基础镜像放在 /shared/images，安装器需要时会处理基础镜像，无需为了这一步先把未修复基础版本启动为对外服务节点。已有专用 EHF 的设备还应比较原有 bug fixes 与目标包；缺少所需修复时，通过 F5 Support 确认组合包，避免修好此漏洞却丢掉先前的业务修补。

公开数据库也存在需要人工处理的差异。9 月 28 日读取的 NVD 把一条 CPE 范围的起点设为 17.0.0，F5 当前受影响表从 17.1.0 开始；F5 版本矩阵又把 17.0 列入 EOL。厂商明确未评估已结束技术支持的版本，因此较老设备需要单独确认或迁移，不能用“没列在表里”判安全，也不能把 CPE 起点当作已查明的漏洞引入版本。NVD 当前展示的 CVSS 3.1 9.8、CVSS 4.0 9.3 来自 F5，未见另一套 NIST 独立评分。

这里适合采取的上线策略，是在受控条件下先完成一个节点的镜像核对和业务验证，再按现有 HA 变更流程处理其余节点。若升级失败，需要回到旧卷恢复排障，受影响的授权服务应继续保持隔离或厂商认可的临时防护；重新开放流量的最低条件仍是确认包含 2524777 的运行构建。旧的未修复启动卷只能承担受控恢复用途。

4 临时拦截期间，把既有入侵查清

F5 当前建议向 Support 获取临时 iRule。公开公告没有提供规则正文，我们无法独立确认它如何处理重复头、不同 HTTP 版本或自定义路径。拿到规则后，应核对适用构建、挂载的 virtual server、真实 OAuth 路径，以及正常大令牌请求是否仍能工作；这些是部署前需要与厂商确认的事项。自己写一条只检查默认 URL 的规则，无法据此获得相同的覆盖保证。

暂时停用或限制授权服务会影响依赖它的应用：新登录、令牌更新或 UserInfo 查询可能失败，影响程度取决于客户端怎样缓存令牌、怎样获取用户资料。响应负责人需要选择可接受的降级方式，明确哪些调用仍要放行。临时规则用于减少新的触发机会；设备上已经出现的文件、账户或配置修改，需要另外调查与恢复。

CERT-EU 建议在修补前保存取证材料。实务上应把易丢失的日志、现有 core、运行配置和准确时间保存到受控位置，同时推进流量限制与升级，避免为追求完整取证长时间保留暴露。公开工单中应移除会话、密钥和用户资料等敏感内容。

厂商给出的起点是 /var/log/apm 中重复的 OAuth UserInfo 失败，事件号 01990004，包括 invalid_token。F5 将同一日志中出现 10 次或更多相关错误、尤其集中于一个来源 IP，列为中等置信度迹象。这个条件没有规定“每分钟”，正常应用的过期令牌或错误重试也会增加失败，因此应同时查看请求时间、来源和实际路径。

# 本机只读计数，用于与已有日志和时间范围对照
tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed

total_failed 的异常增长可帮助缩小调查时间，计数本身没有记录谁执行了什么。接下来对照 /var/log/audit 中的异常命令和管理活动，再检查该时段的 TMM 状态。F5 说明，TMM 陷入循环后，SOD 可能发送 SIGABRT 并产生 core；core 也可能来自其他故障，应结合前后的 OAuth 失败和命令记录判断。

JPCERT/CC 的 9 月 24 日通知进一步建议核对异常长的 Authorization 头，以及 /etc/bigstart/scripts/tmm.finish 的完整性。检查文件应使用适合该精确镜像或厂商支持的可信基线，保留差异及时间。发现可疑修改后，应扩大到文件、管理员账户、访问策略和令牌相关密钥；加拿大网络安全中心也明确要求审查管理员账户和访问策略。

这些材料各自回答不同问题。异常请求说明曾有人接触入口，异常文件或审计命令帮助判断接触之后发生了什么，运行构建说明当前是否装有修复。日志可能轮转，记录范围也受配置影响；没有找到上述迹象时，应写明检查了哪些节点、日志和时间段。公开信息目前不足以给出所有受害者、攻击者归属或各平台上的利用成功率。

5 恢复业务前，还要验证令牌和备用节点

修复完成的证据应来自运行中的节点。逐台记录完整 EHF 构建，确认切换后的备用节点不会重新带入旧处理代码，再用自己控制的正常账户和应用跑完登录、令牌获取、UserInfo 及刷新流程。使用无效或过期令牌检查预期拒绝，观察错误计数与日志是否对应。故意构造超长请求会进入内存安全测试范围，生产恢复验收无需通过这种方式证明补丁存在。

若调查发现设备遭到控制，恢复还涉及它曾保管的凭据。OAuth 授权服务器可能持有签名密钥、客户端秘密和令牌数据库。F5 文档说明 OAuth 数据库可随 HA 自动同步，UCS 备份也包含这份数据库；应检查备份和同步来源的可信度，再决定如何恢复。对可能泄露的签名密钥与客户端秘密安排轮换，并结合令牌有效期、验证方缓存和应用兼容性撤销旧信任。单次重启无法回答这些材料是否已经被读取。

临时 iRule 的退出也需要一次正常业务核对。所有承载该授权服务的节点完成修复、入侵调查得到处理结论之后，再按厂商指导移除临时规则，检查合法流量与监控是否恢复到预期状态。若仍有节点版本不清、异常文件未解释或必要日志缺失，就保留相应限制，并明确交给谁继续调查。

这次漏洞给认证服务的实现审查留下了一个具体问题：外部凭据在被确认有效之前，已经经过多少次解析、分配和复制？每一步都必须按不可信输入处理。对正在运行 APM 的团队，今天能够完成的工作同样明确：找对授权服务器，核准完整热修复构建，把补丁之前发生的事查到足以恢复服务的程度。