事件概述
CISA 已在 2026 年 7 月 16 日把两个 Fortinet FortiSandbox 相关漏洞加入 Known Exploited Vulnerabilities（KEV）目录：CVE-2026-25089 与 CVE-2026-39808。两者都属于 OS Command Injection（操作系统命令注入）风险，核心危险点在于攻击者可能通过特制 HTTP 请求，在受影响的 FortiSandbox 组件上执行未授权命令。
这类漏洞值得被优先关注，并不只是因为它出现在安全设备上，更因为 FortiSandbox 通常被部署在邮件、Web 下载、文件检测、威胁分析等安全链路中。一旦安全分析设备本身被攻击者拿下，后续风险可能从单点漏洞扩展为凭据窃取、横向移动、日志破坏、检测绕过，甚至影响企业对恶意样本的处置判断。
根据 CISA KEV 目录信息，CVE-2026-25089 涉及 FortiSandbox、FortiSandbox Cloud 与 FortiSandbox PaaS；CVE-2026-39808 涉及 FortiSandbox。CISA 的 KEV 条目说明这些漏洞已经存在在野利用迹象，要求相关组织按照厂商指引采取缓解或升级措施。
影响范围
从 Fortinet PSIRT 公告和 NVD 信息看，CVE-2026-25089 的受影响版本包括 FortiSandbox 5.0.0 至 5.0.5、FortiSandbox 4.4.0 至 4.4.8、FortiSandbox 4.2 全版本，以及 FortiSandbox Cloud 5.0.4 至 5.0.5、FortiSandbox PaaS 5.0.4 至 5.0.5。Fortinet 给出的修复方向是将 FortiSandbox 5.0 升级到 5.0.6 或更高版本，将 4.4 升级到 4.4.9 或更高版本；FortiSandbox Cloud 与 PaaS 对应 5.0 分支也建议升级到 5.0.6 或更高版本。
CVE-2026-39808 的厂商公告显示，FortiSandbox 4.4.0 至 4.4.8 受影响，建议升级到 4.4.9 或更高版本；FortiSandbox 5.0 在该公告中标记为不受影响。两个漏洞虽然编号不同、公告时间不同，但都指向命令注入这一类高危问题，并且都已出现在 CISA KEV 中。
对中小企业和站点运维来说，判断风险时不要只看“我有没有公网管理后台”。FortiSandbox 往往与邮件网关、文件传输、终端样本提交、Web 安全设备或内网分析流程打通，若 Web UI 或相关接口被不当暴露，或者上游设备可以把攻击者可控内容转发到沙箱，就可能扩大攻击面。
为什么安全设备漏洞更敏感
安全设备的特殊之处在于，它通常拥有较高的网络可见性和较多的信任关系。沙箱设备可能能接收来自邮件网关、防火墙、终端代理、Web 网关的文件和 URL，也可能保存样本、检测报告、内部主机名、用户名、邮件主题、下载来源等上下文信息。攻击者若能在这类设备上执行命令，获得的不只是单台服务器权限，还可能拿到企业安全运营链路上的关键线索。
另一个容易被忽略的问题是“检测系统被攻击后，告警可信度会下降”。如果攻击者可以篡改配置、清理日志、调整检测策略，企业可能会误以为外部威胁已经被拦截，实际却在丢失关键证据。因此，对 FortiSandbox 这类安全基础设施的修复优先级，应高于普通内网辅助系统。
如果企业安全链路部署在云上或托管环境中，也要同时确认服务模式。Fortinet 公告中对 FortiSandbox Cloud、FortiSandbox PaaS 的影响范围给出了不同分支说明，用户需要根据自身订阅、版本和厂商托管状态确认是否已经由服务商完成升级，不能简单假设“云服务一定已经自动修好”。
攻击风险与利用前提
公开资料没有必要也不应该展开具体利用细节，但从漏洞类型可以判断，命令注入通常意味着应用在处理外部输入时，把未经充分过滤的内容拼接进系统命令或脚本执行流程。若漏洞入口无需认证，攻击者只要能访问相应 HTTP 接口，就可能尝试远程触发。
实际风险取决于几个条件：设备版本是否处于受影响范围、相关 Web UI 或服务接口是否可达、是否存在公网暴露或跨网段访问路径、上游网关是否能转发攻击者构造的请求、设备本身权限边界是否足够严格。已经加入 KEV 的漏洞，说明不能再按“理论漏洞”处理，应按真实攻击风险纳入紧急修复队列。
对于使用 速维云云服务器 承载安全管理平台、日志平台或跳板管理服务的团队，可以借这个事件重新梳理安全设备所在网段：管理口不应直接暴露公网，安全设备与业务服务器之间也应通过最小访问控制限制互通范围。云主机侧安全组、系统防火墙、反向代理访问控制要一起检查，不能只依赖设备自身账号密码。
排查思路
第一步是资产确认。运维应列出所有 FortiSandbox、FortiSandbox Cloud、FortiSandbox PaaS 实例，记录版本、部署位置、管理入口、接入的邮件网关或防火墙、是否存在公网访问、是否由第三方托管。很多企业安全设备部署时间较早，资产台账里只写“沙箱”或“样本分析平台”，没有写清具体版本，这会拖慢响应速度。
第二步是版本核对。将当前版本与 Fortinet PSIRT 公告中的受影响版本逐项比对：CVE-2026-25089 重点关注 FortiSandbox 5.0.0-5.0.5、4.4.0-4.4.8、4.2 全版本，以及 Cloud/PaaS 5.0.4-5.0.5；CVE-2026-39808 重点关注 FortiSandbox 4.4.0-4.4.8。若版本处于受影响范围，应尽快按厂商建议升级。
第三步是暴露面检查。确认管理后台、API、Web UI 是否对互联网开放；如果必须远程管理，应优先放在 VPN、零信任访问、堡垒机或固定办公 IP 白名单之后，不建议直接把管理端口裸露在公网。对内网环境，也要检查是否存在从办公网、访客网、开发测试网直接访问安全设备管理面的路径。
第四步是日志与异常行为回溯。重点查看漏洞披露前后是否有异常 HTTP 请求、未知管理登录、配置变化、异常进程、计划任务变化、可疑外联、日志缺口、样本处理失败激增等现象。若安全设备与日志平台对接，应同时在集中日志中检索设备相关告警，避免只看本机日志导致证据不完整。
修复与临时缓解建议
最可靠的修复方式是按照 Fortinet 官方 PSIRT 公告升级到不受影响版本。对 CVE-2026-25089，Fortinet 建议 FortiSandbox 5.0 升级至 5.0.6 或更高版本，4.4 升级至 4.4.9 或更高版本，受影响的 Cloud/PaaS 5.0 分支也升级至 5.0.6 或更高版本。对 CVE-2026-39808，FortiSandbox 4.4 分支建议升级至 4.4.9 或更高版本。具体升级路径、兼容性和授权状态应以 Fortinet 官方文档与设备后台提示为准。
升级前建议先完成配置备份，确认当前 HA 状态、日志转发、邮件网关联动、样本提交策略和告警通知配置。生产环境不要在业务高峰直接操作，最好先评估升级是否需要重启、是否会影响邮件附件检测或文件下载检测链路。若有主备设备，应按厂商建议规划滚动升级，避免安全检测链路长时间中断。
如果短时间内无法升级，应采取保守缓解措施：限制管理 Web UI 和相关接口访问来源，仅允许可信管理网段访问；关闭不必要的远程入口；强化管理员账号 MFA 和密码策略；检查是否存在临时账号、弱口令或过期账号；提高日志保留周期；将可疑访问记录同步到独立日志平台；对设备所在网段实施更严格的出站访问控制。
需要强调的是，临时限制暴露面不能替代补丁。命令注入类漏洞一旦被武器化，攻击者往往会快速扫描互联网暴露目标，并尝试批量植入后门或窃取配置。已经在 KEV 中出现的漏洞，应尽量按“紧急窗口”处理，而不是等到下一次例行维护。
中小企业应补上的安全习惯
这次事件再次提醒企业：安全设备也需要纳入漏洞管理，而不是买完就长期不动。很多入侵事件并不是从业务系统开始，而是从 VPN、防火墙、邮件网关、沙箱、备份系统、监控平台这类“高信任基础设施”突破。它们常常权限高、网络通、日志多，一旦失守，攻击者能更快理解内部网络。
建议把安全设备单独列入资产清单，至少记录设备型号、系统版本、管理地址、责任人、维保状态、升级窗口、外部暴露面和日志接入状态。对每个设备设置月度版本检查和高危漏洞紧急响应流程：看到 CISA KEV、厂商 PSIRT、CERT 通告或主流安全厂商分析后，先判断是否使用，再判断是否受影响，最后决定升级、隔离或监控。
同时要避免把安全产品当成唯一防线。即使部署了沙箱、WAF 或防火墙，也应继续做好最小权限、补丁管理、备份恢复、账号 MFA、日志集中化和入侵演练。安全设备能降低风险，但不能替代基础运维纪律。
后续观察
后续需要重点关注 Fortinet 是否更新补充公告、是否披露更多受影响分支、是否提供进一步 IoC 或排查建议；也要关注 CISA KEV 条目的处置要求和安全社区对攻击活动的跟踪。如果企业发现设备存在异常进程、未知外联或日志被清理，不应只做版本升级，还应按入侵事件处理，保留证据并评估是否需要重置凭据、重建设备或扩大排查范围。
对站长、云服务器用户和中小企业运维而言，这类事件的实用结论很明确：任何暴露在网络边界、承载管理能力或连接多个系统的组件，都要优先纳入补丁和暴露面治理。安全设备不是“不会被打”的设备，它往往正是攻击者最想拿到的入口。
