【热点安全风险】11月7日｜GPUStack 把本机来源当作管理员，未认证攻击者伪造请求头即可接管平台（CVE-2026-102895）

华顺信安威胁情报中心

2026年11月7日 07:30
湖南

去阅读

PART.01

风险汇总‍‍‍

风险一：GPUStack 把本机来源当作管理员，未认证攻击者伪造请求头即可接管平台，缺陷已遭在野利用（CVE-2026-102895）

GPUStack 是开源的 GPU 集群管理平台，用于自建算力环境下的模型推理部署与 GPU 实例调度，并集中保管工作节点与云厂商的接入凭据。项目公告显示，2.2.0 之前版本的鉴权函数在 force\_auth\_localhost 默认取 false 时，会把来源被判为本机环回的请求直接当作内置管理员，而判断来源的函数存在两处可控点：平台置于同主机反向代理之后时，远程请求抵达时对端地址都是 127.0.0.1，环回提权分支随之触发；请求中客户端自带的 X-GPUStack-Real-IP 头也会被直接采信。未认证攻击者借此取得完整管理员权限：清点并修改用户、模型、节点与配置，签发权限覆盖全部资源、此后从任意地址可用的长期管理员 API 密钥，读取节点凭据与云服务商密钥，再通过后端 YAML 导入接口在工作节点上执行代码，即取得该主机控制权。评分 9.8（CVSS 3.1），影响 2.2.0 之前全部版本。公告称该缺陷已在 2.1.1 部署上被实际利用，攻击者创建自定义后端运行反弹 shell；2.2.0 已移除环回自动提权逻辑，未修复前可关闭环回免认证并在入口剥离该请求头。

建议排查

1. 清点 GPUStack 实例版本与是否部署在同主机反向代理之后
2. 检索访问日志中的 X-GPUStack-Real-IP 头与异常管理员操作
3. 核对管理员 API 密钥清单，核查来历不明或长期有效的条目

加固建议

1. 升级至 2.2.0，并吊销全部既有管理员 API 密钥
2. 将 force\_auth\_localhost 设为 true，禁用环回免认证
3. 在入口统一剥离客户端自带的 X-GPUStack-Real-IP 头

参考来源

https://github.com/gpustack/gpustack/security/advisories/GHSA-gj9m-f8ph-pmhr

风险二：韩国 37 家金融公司报告 40 起入侵事件，约 47.3 万条个人信息外泄

韩国金融委员会（Financial Services Commission，简称 FSC）11月5日召开会议通报金融业入侵情况。9月30日至11月3日，韩国金融业共有 37 家金融公司报告 40 起黑客入侵事件，涉及 4 家银行、5 家金融投资公司、3 家保险公司、5 家储蓄银行、1 家互助金融机构、2 家专业信贷金融公司、4 家线上 P2P 借贷服务商、10 家电子金融服务商和 3 家虚拟资产服务商。外泄信息约 47.3 万条，主要是员工信息以及客户的姓名、居民登记号码和账号；官方表示尚未接到客户账户密码被盗的报告。虚拟资产、电子金融服务和线上 P2P 借贷领域的中小机构报告资金损失合计约 10 亿韩元，被盗资金多来自其自有管理账户，个人用户暂未发现损失。监管机构已要求受影响机构落实消费者保护、加强可疑交易监测，并对约 580 家机构的对外接口与内部控制体系开展检查，已登记 IT 资产的对外接口检查在 11 月底前完成；大型机构的第三方安全评估由每年一次提高到每年两次，虚拟资产服务商此后发生入侵须直接向金融监管机构报告。

建议排查

1. 核对本单位及合作机构是否在 580 家受检范围内，梳理对外接口清单
2. 排查客户姓名、居民登记号、账号等字段的批量导出与异常访问记录
3. 复核与 P2P、电子金融服务商对接的接口权限与可见数据范围

加固建议

1. 把对外接口、开发测试系统纳入资产台账并逐季复核
2. 对敏感字段启用最小权限、导出审计与页面脱敏
3. 建立跨机构威胁信息共享与限时通报流程

参考来源

https://www.fsc.go.kr/eng/pr010101/88092

风险三：阿帕奇（Apache）OFBiz 一个版本修复 46 个漏洞，未认证攻击者可凭截获的会话参数接管账户（CVE-2026-82907）

阿帕奇软件基金会的开源企业资源与业务流程平台 OFBiz 在 24.09.08 版本中修复 46 个漏洞，该分支自 2024 年 9 月起功能冻结、只接收缺陷修复，官方清单显示这些缺陷影响 24.09.08 之前的全部版本。其中 CVE-2026-82907 评分 9.8（CVSS 3.1），属认证绕过中的捕获重放问题，出在 ExternalLoginKeysManager 组件：负责校验 externalLoginKey 参数的函数作为全局前置处理器运行，位置在跨站请求伪造校验与身份认证校验之前，且把该参数当作不绑定客户端、不设过期时间、使用后也不失效的持有型凭据；框架本身还会把有效参数附加到它渲染的每个跨应用链接上。远程未认证攻击者只要截获一个有效的 externalLoginKey 值，就能以签发该值的用户身份获得无需 cookie、可重复使用的会话，覆盖该用户可达的所有应用，包括其后台上能做的全部操作。同批修复的 CVE-2026-83542 为代码注入，评分同为 9.8。

建议排查

1. 确认 OFBiz 版本，凡低于 24.09.08 的一律纳入升级
2. 检索访问日志中 externalLoginKey 参数被重复提交或跨来源使用
3. 核对同一会话参数是否出现多地、多客户端并发的记录

加固建议

1. 升级至 24.09.08 并强制所有既有会话失效重建
2. 关闭未使用的应用与组件，收敛对外暴露路径
3. 对跨应用跳转关闭凭据自动附带，改为重新认证

参考来源

https://ofbiz.apache.org/security.html

风险四：Kubernetes 策略引擎 Kyverno 缺少命名空间校验，租户可越界改写其他租户的资源并自提权限（CVE-2026-122313）

Kyverno 是 Kubernetes 原生的策略引擎，以准入控制的方式校验并变更集群内的资源，其后台控制器持有集群级权限。1.17.0 至 1.19.2 之前的版本存在一处越权缺陷：命名空间级的变更策略在计算输出结果时，没有校验输出目标所属的命名空间。命名空间范围内的租户可以在策略表达式中输出一个指向其他租户角色绑定的字面量目标，这段变更随后由持有集群权限的后台控制器代为执行，等于借控制器之手把代表攻击者的主体追加进他人的角色绑定，或直接改写角色、网络策略与配置字典。整个过程不需要集群管理员身份，也不需要接触对方命名空间。危险之处在于权限借用：控制器合法，操作也由控制器发起，事后审计看到的是一次正常生效的策略变更，而非跨命名空间的越权动作。评分 9.9（CVSS 3.1），影响范围为 1.17.0 起至 1.19.2 之前，修复版本 1.19.2。多租户共享集群中，一个租户借此取得他人的角色绑定后，可进一步读取或改动对方业务数据。变更策略是 Kyverno 的常规用法，多数多租户集群默认启用，缺陷面并不局限于少见配置。

建议排查

1. 确认 Kyverno 版本，1.17.0 至 1.19.2 之前的需安排升级
2. 审计命名空间级变更策略，检查输出目标是否指向其他命名空间
3. 比对角色绑定与网络策略的变更记录，核查有无非本租户发起的改动

加固建议

1. 升级至 1.19.2，并复核集群级后台控制器的授权边界
2. 限制租户创建变更策略与生成规则的权限，收敛可写的资源类型
3. 对策略变更开启审计告警与人工复核，重点关注跨命名空间的操作

参考来源

https://github.com/kyverno/kyverno/security/advisories/GHSA-f96w-622v-rqpq

风险五：Keycloak 身份自动关联只按邮箱匹配，未验证邮箱可被用于接管既有账户（CVE-2026-97175）

Keycloak 是开源身份与访问管理平台，为应用提供单点登录、身份联合与令牌签发，常被放在业务系统之前充当统一入口。缺陷出在负责身份自动关联的认证器：它把外部身份提供方传入的身份绑定到既有本地账户时，只按邮箱地址做匹配，不校验该提供方是否已确认过这个邮箱。攻击者只要在任一受信任的身份提供方用一个未经验证的邮箱注册，就能接管与该邮箱对应的本地账户，取得该账户在全部接入应用中的权限。评分 8.8（CVSS 3.1），红帽在 11月5日的公告中确认受影响组件为 keycloak-services，涉及 Red Hat Build of Keycloak 与 Red Hat Single Sign-On 7，修复版本以厂商发布为准。这类接管的危险在于不留痕迹：登录走的是正常的联合认证流程，日志里看到的是一次来自合法身份提供方的成功认证，仅凭单条记录难以与本人登录区分。该平台承载全部接入应用的身份校验，一个账户被接管即等于其可访问的业务系统一并失守；若被接管的是运维或管理员账户，攻击者还可沿用原有权限横向进入其他系统。

建议排查

1. 清点已启用的身份提供方与身份自动关联配置
2. 审计自动关联记录，核对所关联的邮箱是否已完成验证
3. 核查异地登录与权限变更记录，排查异常账户活动

加固建议

1. 升级至厂商修复版本，并复核自动关联策略
2. 对自动关联账户强制要求邮箱已完成验证
3. 关闭未使用的身份提供方，收敛可写入的账户字段

参考来源

https://access.redhat.com/security/cve/CVE-2026-97175

风险六：巴西存款保障基金 FGC 保障金支付流程环境被未授权访问，姓名与税号等个人信息受影响

巴西存款保障基金（Fundo Garantidor de Créditos，简称 FGC，为巴西银行存款及部分金融产品提供保障的行业机构，在机构被清算时向债权人支付保障金）11月5日更新事件公告，确认在与其保障金支付流程相关的内部环境中发现对个人信息的未授权访问，怀疑出现的时点为 10月26日。受影响数据包括姓名、个人税号、电子邮箱、出生日期，以及与保障金支付相关的数据，即支付中扣缴税款的信息和被清算机构中该笔受保障投资的分销渠道记录。官方表示，目前未发现数据被公开或不当使用的证据，也未发现由此产生的资金损失，调查仍在专业机构协助下进行，调查范围包括是否发生过数据被复制或带出。已采取的措施包括限制相关环境访问、封禁非授权账户、留存取证证据、复核权限与安全控制；已按现行法规向巴西国家数据保护局通报，并已通知受影响个人。公告同时提示，姓名与税号等信息组合可能被用于冒充该机构或其关联机构实施诈骗，接到涉及个人信息或保障金流程的接触时应先通过官方渠道核实。

建议排查

1. 核对与代偿、理赔类资金支付相关的对外通知渠道
2. 排查以保障机构名义索取密码、验证码或要求转账的接触
3. 复核曾提交至外部保障机构的姓名、证件号等信息范围

加固建议

1. 对来自保障机构的通知一律通过其官网独立核验
2. 在客服与理赔流程中增加身份二次验证
3. 将合作机构的泄露事件纳入供应链风险台账

参考来源

https://www.fgc.org.br/comunicado

PART.02

总体处置建议‍‍‍

总结

这批风险共同指向一处：失守点几乎都不在加密算法或边界防护上，而在「前提假设」被打破。GPUStack 假定来自本机地址的请求一定是运维人员，OFBiz 假定会话参数只有签发者本人能拿到，Kyverno 假定准入策略的输出不会指向别人的资源，Keycloak 假定第三方提供方传来的邮箱已经过核验，两起监管通报则显示机构在对外接口与第三方对接上的可见性长期不足。这些假设单看都合理，一旦被绕过，攻击者获得的是「以合法身份或合法凭据操作」的能力，日志里留下的都是正常登录与正常调用。

从成本看，这一类几乎没有需要复杂利用工程的门槛：伪造一个来源地址、截获一个参数、写一段策略表达式，都是普通工具即可完成的操作，其中 GPUStack 的缺陷已在真实部署上被利用。从影响面看，GPU 管理平台与企业业务平台是算力与流程的前置入口，策略引擎与单点登录则直接持有权限与账号数据，一处被绕过往往等于整条业务链失守。

修复节奏上，四个项目均在公告中给出明确修复版本，OFBiz 以版本形式集中清理历史欠账，说明这类「前提假设」问题正在被批量偿还，但企业侧的升级与配置变更通常滞后，实际风险窗口取决于自查完成的时点。

整体风险处置建议

1. 把「已禁用、已关闭、不可用」这类配置状态当作可被绕过的假设，逐项验证实际行为
2. 对以来源地址判定身份的服务逐项验证信任边界，剥离客户端可控的来源标识
3. 对集群级控制器与策略引擎，按最小权限重划租户边界并开启变更审计
4. 将对外接口、开发测试系统与第三方对接通道纳入统一资产台账，定期复核授权范围
5. 建立前提假设失效的专项监测，覆盖会话凭据的重复使用与合法账号的异地、并发操作

合规说明

以上内容基于公开信息整理，仅用于网络安全防护与管理决策参考，具体影响范围与修复方式请以厂商官方公告为准。