【热点安全风险】10月29日｜Adobe Commerce 上传缺陷遭在野利用，攻击者接管账号（CVE-2026-48356）

华顺信安威胁情报中心

2026年10月29日 07:30
湖南

去阅读

PART.01

风险汇总‍‍‍

风险一：Adobe Commerce 任意文件上传漏洞已遭在野利用，攻击者可取得账号控制权（CVE-2026-48356）

Adobe Commerce 是面向零售与 B2B 的电商建站平台，Magento Open Source 是其开源版本，自建商城与跨境独立站大量部署这套系统。7 月 14 日的安全公告 APSB26-73 修复了一批漏洞，其中 CVE-2026-48356 属于上传文件时未限制危险类型，评分在 3.1 版为 9.6，公告当时写明未见在野利用。10 月 27 日该漏洞被列入美国 CISA 的已知被利用目录，要求 11 月 10 日前完成处置。受影响版本为 2.4.9 及 2.4.8-p5、2.4.7-p10、2.4.6-p15、2.4.5-p17、2.4.4-p18 及更早分支，B2B 与 Magento Open Source 对应分支同样在列，修复版本是各分支的 2026-jul 版本。攻击者上传特制文件后可在当前用户上下文执行代码，进而提升权限、接管账号或会话。电商站点的订单、支付与会员数据都集中在同一套系统里，页面被改、结算被劫持往往在数周后才被发现。补丁发布三个多月才确认遭利用，说明未升级的实例仍大量存在。

建议排查

1. 核对商城版本是否落在受影响区间，重点看 2.4.4 至 2.4.8 老分支。
2. 检查 media 与 pub 目录下的可执行脚本文件及新增时间。
3. 复核管理员账号、结算页脚本与订单导出记录有无异常。

加固建议

1. 升级至对应分支的 2026-jul 版本，升级后重新核对插件兼容性。
2. 上传目录禁止执行脚本，静态资源与代码目录分离部署。
3. 对后台与管理接口启用多因素认证，收敛互联网暴露面。

参考来源

https://helpx.adobe.com/security/products/magento/apsb26-73.html

风险二：GMO 互联网集团（GMO Internet）拒付约 80 亿日元赎金，攻击者已公开自称客户信息

GMO 互联网集团（GMO Internet）是日本互联网服务商，旗下お名前.com 的桌面云（Desktop Cloud）以虚拟机形态向客户交付可长期在线的远程桌面，其中面向外汇保证金交易的专供套餐把交易终端放在云上。该平台 10 月 20 日确认客户服务器环境被第三方植入恶意程序，厂商 10 月 21 日 4:00 起停服，同日收到索要约 80 亿日元的威胁邮件。10 月 27 日 12:30，厂商确认疑似攻击者已公开自称属于公司及客户的信息，内容仍在核实、可能含有与事实不符的部分。厂商表示永久拒绝攻击者的要求，理由是按其要求付款不能保证信息被删除或免于滥用，反而间接为犯罪提供资金，并已向警方等机关咨询、对恶意扩散者准备民事披露申请与刑事控告。对确认信息被公开的客户，厂商按信息类别发放特别慰问金，单次公开上限 300 万日元，另设总额上限 100 万美元、约 1.5 亿日元的悬赏征集破案线索。事件已从数据外泄转入公开施压与追责阶段，被窃取的交易账号与口令仍是后续盗用与钓鱼的直接入口。

建议排查

1. 核对是否有交易或业务终端托管在该平台，确认替代环境安排。
2. 检查外汇交易账号、邮箱口令是否与该平台共用同一套口令。
3. 复核异常登录、未授权交易与冒充厂商的钓鱼信息。

加固建议

1. 立即轮换交易与邮箱口令，结束全部活跃登录会话。
2. 托管在第三方云的业务须预设凭据轮换与停服应急方案。
3. 收到数据公开威胁时先做证据保全，不访问攻击者站点。

参考来源

https://internet.gmo/en/news/article/258

风险三：证书机构 eMudhra 八个中间 CA 私钥泄露，攻击者可冒充任意网站（CVE-2026-108014/108015）

eMudhra 是一家证书颁发机构，签发的证书被广泛用于网站与邮件服务的身份证明，其八个中间 CA 证书的私钥已被确认泄露。这些中间证书向上链接到 Mozilla、微软、苹果与 Chrome 根证书程序所信任的根，也就意味着持有私钥者可以为任意域名签发能被浏览器接受的证书。报告者用每个中间 CA 的私钥对同一段文本签名并提交，作为私钥失控的凭证。Firefox 与 Chrome 自 10 月 17 日起阻断这些证书，10 月 19 日完成向下游信任库的负责任披露，该机构已吊销涉事中间证书。HCL 为此给旗下 Domino 服务器与 Notes 客户端分别分配 CVE-2026-108014 与 CVE-2026-108015，评分在 4.0 版均为 9.1，两处受影响点都在对外发起网络请求时的证书校验环节。浏览器依靠吊销信息分发可以较快止血，但嵌入式设备、老旧操作系统与自研 TLS 实现往往不消费吊销列表，必须靠软件更新才能剔除这条信任链。

建议排查

1. 核对本单位对内服务与邮件网关是否仍信任这批中间证书。
2. 检查嵌入式设备、工控网关与自研客户端的信任库来源与更新机制。
3. 复核 10 月 17 日以来与外部服务通信的证书链异常告警。

加固建议

1. 更新操作系统、浏览器与运行时信任库，剔除已吊销的中间证书。
2. 对关键业务启用证书固定与透明度校验，降低单点 CA 失守的影响。
3. 收紧内部系统对公共 CA 的信任范围，优先使用自建私有信任链。

参考来源

https://support.hcl-software.com/csm?id=kb\_article&sysparm\_article=KB0134742

风险四：英伟达（NVIDIA）NeMo 智能体工具包缺失认证，未认证攻击者可执行任意代码（CVE-2026-65145）

NeMo Agent Toolkit 是英伟达（NVIDIA）开源的一套智能体开发工具包，供开发者把大模型与工具链拼装成可调用的智能体服务。10 月 27 日的安全公告给出两枚漏洞：CVE-2026-65145 属于关键功能缺失认证，攻击者无需任何凭据即可触达受影响的接口，评分在 3.1 版为 10.0，影响 1.0 至 1.8.0 版本，修复版本为 1.9.0；同批的 CVE-2026-65151 是 SQL 注入，评分 8.4，影响 1.4 至 1.6，修复版本为 1.7.0。官方说明两枚漏洞均由外部研究人员发现。缺失认证的后果不是单点越权，而是代码执行、权限提升、数据篡改、拒绝服务与信息泄露可以同时发生，因为智能体服务本身就被赋予了调用工具、读写文件与访问内部接口的能力。这类服务常被部署在共享内网供业务系统调用，边界一旦敞开，攻击者连模型本身都不必接触，就能借它的权限在内部横向移动。工具包里挂载的工具调用通常直连数据库、文件系统与内部接口，一个未认证的入口，等于把这些能力整体对内网敞开。

建议排查

1. 盘点在用的 NeMo Agent Toolkit 版本，确认是否低于 1.9.0。
2. 检查智能体服务的监听地址，确认是否存在对非授信网段开放。
3. 复核服务日志中无身份信息的工具调用与异常请求。

加固建议

1. 升级至 1.9.0 及以上版本，并同步核对工具链依赖。
2. 为智能体服务前置统一认证网关，禁止匿名调用。
3. 限制智能体可调用的工具与可访问的目录范围，按最小权限运行。

参考来源

https://github.com/NVIDIA/product-security/tree/main/2026/5912

风险五：Electrum 钱包不校验未确认交易签名，恶意服务器可劫持用户转账（CVE-2026-117601）

Electrum 是轻量级比特币钱包，用户不下载完整区块链，而是连接公共或自建服务器查询余额与广播交易，这个设计让服务器的诚实性成为安全前提。4.8.3 之前的版本在处理尚未确认的交易时，没有校验钱包自有输入的签名，恶意服务器可以据此把用户刚广播的交易替换成另一笔冲突交易，把钱转走，同时在界面上显示一份无效的零费副本，让用户以为转账仍在路上。同批修复的 CVE-2026-117603 涉及钱包内置的 Nostr Wallet Connect 插件，日限额检查不是原子操作，叠加毫秒与聪的换算截断，攻击者并发提交付款请求即可突破每日上限，该问题在 4.7.2 修复。两枚漏洞评分在 4.0 版均为 9.3。轻钱包的便利建立在信任服务器之上，一旦服务器被控制或本身作恶，用户看到的余额与交易状态都可能是伪造的。多数用户直接沿用钱包内置的公共服务器列表，无从判断对端由谁运行；发起交易时，钱包与服务端的往返又没有独立校验环节，服务器返回的状态就是界面显示的状态。这类攻击不必接触用户设备，也不必破解任何加密算法，成本低且事后极难察觉。

建议排查

1. 核对钱包版本，确认是否已升级到 4.8.3 及以上。
2. 检查是否启用了 Nostr Wallet Connect 插件及其日限额配置。
3. 复核转账记录与实际链上交易是否一一对应。

加固建议

1. 升级至 4.8.3 及以上版本，重新核对已配置的服务器列表。
2. 优先连接自建节点，避免使用来源不明的公共服务器。
3. 大额转账改用硬件钱包或多签，转账后以区块浏览器为准核对。

参考来源

https://github.com/spesmilo/electrum/security/advisories/GHSA-6jp4-8v48-cc5v

风险六：EagleCloud Aquila 的多因素认证服务可注入脚本，已认证用户可取得容器最高权限（CVE-2026-104383）

EagleCloud 的 Aquila 是本地部署的身份与访问管理平台，Pigeon MFA 是其中的多因素认证服务，负责在登录环节核验第二因素并下发票据。2.6.7.2 及之前的版本里，该服务的接口没有正确限制调用方提交的内容，攻击者可以向其中持续写入动态 Lua 脚本，这些脚本随后由缺少沙箱约束的后端引擎执行，且运行身份是容器内的 root。问题编号为 CVE-2026-104383，评分在 4.0 版为 9.4，修复版本为 2.6.7.3。利用门槛并不高：需要一个已认证的低权限账号，不必与受害者交互，就能从公网暴露的接口或经过边缘代理直接触发。得手后可取得容器最高权限、绕过零信任隧道的授权控制访问内部资产，并读取部署密钥，等于把认证体系本身变成了进入内网的入口。多因素认证服务处在所有业务登录的必经路径上，它被控制后，第二因素不再是一道门槛。身份平台往往集中存放全网用户的认证策略与目录信息，容器权限一旦外泄，攻击者可以改写认证规则、留下持久化入口，后续即使打上补丁也难以一次清净。

建议排查

1. 核对 Aquila 本地部署版本，确认是否低于 2.6.7.3。
2. 检查 MFA 服务是否可从公网直接访问，或仅由边缘代理转发。
3. 复核该服务日志中的异常脚本提交与后端执行记录。

加固建议

1. 升级至 2.6.7.3 及以上版本，升级后轮换部署密钥。
2. 认证服务仅允许可信代理访问，禁止公网直连管理接口。
3. 容器以非 root 运行并限制可写目录，脚本执行加沙箱隔离。

参考来源

https://github.com/mandiant/Vulnerability-Disclosures/blob/master/2026/MNDT-2026-0039.md

PART.02

总体处置建议‍‍‍

总结

这一批风险最值得注意的不是单条评分，而是修复与利用之间的时间差被反复拉开。电商平台的文件上传缺陷在七月就已给出补丁，直到十月底才被确认在野利用，中间这三个月正是未升级实例最脆弱的窗口。另一条线是勒索的筹码从加密数据转向公开曝光：当受害方判断付款换不来删除承诺，博弈就变成了信息扩散的速度与范围，真正的损失落在早已流出的凭据上，而不是被加密的文件。还有一条主线是信任关系被当成攻击面：证书机构的中间证书私钥一旦失守，攻击者不必攻破任何一台服务器，就能冒充任意站点；多因素认证服务、智能体工具包、轻钱包服务器则各自把身份判断委托给了默认可信的组件，一处缺失认证或一处脚本注入，就足以让整条链路的校验失去意义。从影响面看，这批漏洞横跨零售结算、办公通信、AI 应用与个人资产，共同点是都站在业务必经路径上，一旦被利用，损失不体现在设备数量，而体现在交易、凭据与资金的直接暴露。处置时应先看谁在默认信任外部输入，再看补丁能否真正落到运行实例。

整体风险处置建议

1. 把已入已知被利用目录的条目单独列出，按处置截止时间倒排优先级。
2. 对电商、认证平台与托管服务，先核对版本与暴露面，再确认官方通报渠道。
3. 上传目录、脚本执行点与接口参数统一做白名单与目录隔离。
4. 梳理对外通信所依赖的证书信任链，剔除已吊销的中间证书。
5. 为认证与智能体服务前置统一鉴权，禁止匿名调用与公网直连。

合规说明

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