Wärtsilä FOS-Onboard 面临关键更新信任失效

根据 9 月 15 日发布的一则网络安全公告，Wärtsilä FOS-Onboard 目前存在两个严重漏洞，其中之一可能破坏其用于交付可信软件更新的机制。受影响版本为 5.07.0923.01。成功利用这些漏洞可能导致未经授权的更新、代码执行、凭据提取，或冒充特权客户端。

这一披露令海事运营商面临令人不安的反转。FOS-Onboard 有助于连接船上运营与岸基规划、监控和支持系统。这种连接能够提升协同效率，但也使身份和更新控制成为重要的安全边界。

这两个漏洞都涉及嵌入产品组件中的加密密钥。硬编码密钥是直接存储在软件或固件中的秘密信息，因此可能在多个部署实例之间共享。一旦有人提取出该秘密，仅更换一艘船上的密码未必能消除更广泛的风险暴露。

Wärtsilä 表示，在按照建议方式安装产品时，这些漏洞无法被利用。该公司还开发了安全补丁，客户需联系该公司获取。这些限定条件很重要，但公开材料并未完整说明安全配置要求，也未列出已修复的产品版本。

这并不意味着攻击者已经入侵船舶或导航系统。公告称目前未发现已知的公开利用，也未描述任何运营事故。眼下更具体的问题是：运营商必须核实软件版本、确认网络架构，并重建对敏感信任链的信心。

Wärtsilä FOS-Onboard 运营商面临哪些变化

此次披露将原本常规的软件资产盘点问题，转变为对更新真实性和特权访问的紧急检验。

FOS-Onboard 公告指出，版本 5.07.0923.01 中存在两个漏洞。两者均归类为 CWE-321，即使用硬编码加密密钥。不过，它们影响不同组件，并形成不同的攻击路径。

CVE-2026-78225 影响 deployer-ng Update Controller。该组件包含硬编码的加密服务器密钥。该漏洞的 CVSS 3.1 评分为 9.0，CVSS 4.0 评分为 9.5。

其 CVSS 3.1 向量描述了一种高复杂度的网络攻击。攻击不需要权限或用户交互，影响范围可能发生变化；一旦攻击成功，可能对机密性、完整性和可用性造成高影响。

Update Controller 尤其敏感，因为它参与软件部署。更新系统决定哪些代码获准进入受保护环境。其加密控制应能区分真实软件包和获授权系统，与冒充者加以区别。

如果这种区分失效，攻击者可能使恶意软件看似获得授权。报告所述后果包括交付未经授权的更新和执行代码。这些结果可能在船员或岸基团队意识到更新路径遭滥用前就影响主机。

CVE-2026-81855 影响机器人测试框架组件。该组件包含硬编码的加密客户端认证密钥。该漏洞在 CVSS 3.1 下评分为 9.1，在 CVSS 4.0 下评分为 9.3。

客户端密钥记录描述了一种低复杂度的网络攻击。它不需要权限或用户交互。其列出的影响包括对机密性和完整性的高影响，但在 CVSS 3.1 评估中不影响可用性。

第二个漏洞造成的是另一种信任失效。它并非削弱更新流程背后的服务器身份，而是可能暴露用于识别可信客户端的凭据。提取这些凭据的攻击者可以冒充特权参与者。

受影响版本的表述异常具体。公告点名 FOS-Onboard 5.07.0923.01，而非列出一个较宽泛的受影响版本范围。运营商不应将这一具体性视为其他所有版本均安全的证据。

未被点名的版本仅是调查的起点。公开公告并未说明首个修复版本，也未说明相关构建版本是否包含相同的组件或密钥材料。

此次披露涉及交通运输系统行业及全球部署。Wärtsilä 总部位于芬兰，其产品则支持不同地区的海事运营。这种分布使协调修复工作比更新常规办公软件更为复杂。

船舶在航行中可能面临间歇性连接、严格的维护流程和有限的技术支持。其船载系统还可能与岸基办公室、远程支持服务和导航基础设施交换数据。每一项连接都会引入基本版本检查无法涵盖的背景因素。

Cydome Security 将这些漏洞报告给 Wärtsilä 和美国网络安全与基础设施安全局。公开记录未披露技术概念验证代码，也未确认涉及任一漏洞的活跃攻击。

这一缺失应避免引发危言耸听的结论，但不应拖延受控修复。加密信任中的严重弱点即使尚未被公开观察到遭利用，仍然十分重要。

为什么硬编码密钥威胁更新链

硬编码密钥改变了安全模型，因为一个被提取的秘密就可能削弱不止一个安装实例的信任。

正常的认证系统假定某个秘密属于明确的用户、设备或部署实例。发生暴露时，管理员可以轮换该秘密，也可以在不重建整个产品的情况下撤销它。

硬编码加密密钥往往表现不同。开发人员将其置于应用程序、脚本、镜像或固件包中。除非安装过程生成替代密钥，每个副本都会继承同一个秘密。

获取一个副本访问权限的攻击者可以检查其中嵌入的材料。具体提取方式取决于产品和封装方式。公告未说明两把 Wärtsilä 密钥中的任一把如何被恢复，因此防御者不应预设某种特定技术。

但架构风险依然明确。共享的服务器密钥可能削弱验证服务器真实性的能力；共享的客户端密钥可能削弱确定哪些客户端应获得特权访问的能力。

CVE-2026-78225 将这一问题置于 deployer-ng Update Controller 之中。软件更新基础设施具有非同寻常的权限，因为其设计目的就是安装新代码。通过可信渠道交付的恶意软件包，可能绕过原本会触发审查的预期控制。

该漏洞的高攻击复杂度需要放在背景中理解。这表示利用漏洞依赖于不仅仅是访问网络服务之外的条件。然而，公开公告并未说明这些条件，因此运营商不能安全地将该评分视作保护控制。

CVSS 在既定模型下衡量技术严重性。它并不衡量某艘特定船舶遭攻击的概率，也无法涵盖每一项防火墙、远程支持隧道、维护流程或网络分段决策。

CVE-2026-81855 的攻击复杂度较低。其客户端认证密钥位于机器人测试框架组件中。披露内容未说明该框架是否仍在每个生产部署中处于活动状态。

这种不确定性具有运营层面的重要性。即使船员并不直接使用，测试工具有时仍会进入生产镜像。除非安装过程禁用或移除它们，其凭据和服务仍可能扩大攻击面。

特权客户端身份可能使攻击者能够与信任嵌入凭据的服务交互。根据公告，利用漏洞可能暴露凭据并允许身份冒充，但未说明冒充后可执行哪些操作。

因此，运营商应避免臆测最坏情况的攻击链。已公布事实并未证明攻击者能够操纵船舶、修改电子海图或直接控制推进系统。公告中没有出现这些结果。

可信的担忧在于初始信任失效。未经授权的代码执行可能成为立足点，而被盗凭据可能扩大访问范围。之后的运营后果取决于产品权限、系统集成和网络架构。

这一区别在海事网络安全中尤为重要。船上使用的软件存在漏洞，并不自动意味着发生安全事故。不过，它可能为通向支持安全敏感决策的系统和数据创造路径。

公开的 CSAF 安全记录为安全工具提供了结构化漏洞数据。CSAF 即通用安全公告框架，使组织能够以机器可读格式处理产品、严重性和修复信息。

船队运营商可利用该记录改善资产清单匹配。他们可以将产品名称和版本与软件清单、管理数据库、船舶文档或部署镜像进行比对。对于缺乏集中可见性的船载资产，仍有必要进行人工检查。

关键问题并非 FOS-Onboard 是否直接连接公共互联网。攻击者可以通过遭入侵的岸基网络、支持渠道、维护设备或其他可信连接抵达海事系统。防御者必须梳理实际路径，而不是依赖互联网暴露扫描。

联网船队的优势如今带来安全压力

让船队软件发挥价值的船岸一体化，也提高了弱认证和不确定更新的代价。

Wärtsilä 将其 Fleet Optimisation Solution 描述为一个整合导航、运营和船舶技术数据的平台。它支持航次规划、性能监控、报告，以及船上与岸基团队之间的协调。

其船队平台概览将 FOS 定位为船舶与船队运营之间的桥梁。可用功能包括航线优化、效率监控、合规报告、通知和性能分析。

这些功能说明了漏洞为何重要，但并不意味着每个模块都受影响。支持船队协调的系统所处的位置，比孤立的生产力应用更为敏感。其连接可能跨越技术和组织边界。

一艘船舶可能与船队运营中心、云服务、供应商支持以及港口相关系统交换信息。船员、岸基团队和第三方维护人员可能承担不同职责。更新流程必须在所有这些角色之间保持信任。

Wärtsilä 已在拥有数十或数百艘船舶的船队中部署 FOS。2019 年，Anglo-Eastern 宣布计划在超过 600 艘船舶上推广该平台。UltraShip 后来则为 18 艘 LPG 运输船选择了该平台。

Carisbrooke Shipping 报告称，已在 31 艘船舶上使用该解决方案。该运营商表示，该平台支持监测船舶位置、航线、安全状况和性能。这些历史部署说明了 FOS 的应用规模，但并不能证明哪些客户正在使用受影响版本。

没有公开证据将任何具名客户与 FOS-Onboard 5.07.0923.01 联系起来。运营商和安全团队不应根据旧部署公告推断自身是否暴露于风险之中。每家机构都需要更新资产清单，并获得供应商确认。

该事件同时给船东和 Wärtsilä 带来压力。船东必须确定受影响版本是否存在于正在运行的船舶、备件、培训系统或岸基副本中。Wärtsilä 则必须提供足够的部署指引，使客户能够在不干扰运营的前提下完成修补。

海事维护存在现实限制。船舶并非总能立即接受对联网运营技术的变更。更新可能需要测试、审批、备份、船员协调或安排维护窗口。

这些限制并不能成为无限期延迟的理由。它们说明，缓解措施必须将打补丁与临时访问控制结合起来。在工程团队验证供应商修复方案期间，船队可以减少可被访问的路径。

因此，核心矛盾在于联网效率与受控信任之间。船舶与岸基团队能够快速共享数据时，船队平台的价值更高。安全控制必须防止这种连接性演变为未经授权的管理通道。

这种模式并不局限于单一供应商。现代海事平台日益整合航行支持、性能分析、合规工作流和远程服务。整合能够提升易用性，但也会集中权限和数据。

这种比较基于架构而非竞争关系。其他联网船队供应商同样面临这一要求：将运营数据交换与特权管理分离。它们同样需要唯一凭证、签名更新、密钥轮换以及可审计的支持访问。

安全团队应避免一种常见的捷径。未经影响分析就断开所有相关服务，可能中断工作流并失去有价值的可见性。CISA 建议组织在对工业系统实施防御性变更前评估运营后果。

更安全的应对始于梳理映射。团队应记录每台受影响主机、其软件版本、网络分段、连接服务及运营负责人。他们还应记录谁有权批准更新和远程维护。

这张映射图会暴露隐藏依赖。一艘船舶可能通过暂存服务器而非直接从 Wärtsilä 接收软件包。岸基团队可能使用跳板主机、文件共享或管理网关，而这些设施使用的是不同的凭证。

每一项依赖都可能限制或扩展攻击路径。正确实施的网络分段能够降低暴露面。拥有过多权限的受信任桥接组件则可能削弱这种保护。

该公告的全球范围又增加了一层复杂性。船队跨越不同司法辖区、时区和连接环境。同一家公司运营的船舶可能采用不同的网络基线和维护历史。

面向全船队的响应必须考虑这些差异。将一项紧急规则一刀切地应用到所有地点，可能造成缺口或中断。目标是实现一致的安全结果，并由船舶特定的实施计划予以支持。

补丁已经存在，但验证仍然重要

应用供应商补丁是必要的，但运营商还需要证据证明已暴露的密钥、凭证和更新路径不再受到信任。

Wärtsilä 表示已开发安全补丁。客户被指引联系该公司以获取并安装补丁。该公司的补丁部署页面提供了公告所引用的联系渠道。

公开通知并未说明补丁包名称、哈希值或修复后的 FOS-Onboard 版本。它没有说明安装补丁是否会轮换内嵌密钥，也没有解释管理员是否必须单独更换相关凭证。

受影响组织应以书面形式索取这些细节。修复软件包应具备可验证的来源、明确的前置条件、安装流程和回滚计划。运营商还需要一种确认安装成功的方法。

版本盘点应当优先进行。团队应识别船舶和岸基系统中正在运行的 5.07.0923.01 实例。他们还应搜索标准化镜像、备份介质、测试环境和离线备件。

旧镜像可能会在硬件更换后重新引入易受攻击的软件。培训系统也可能保留相同的硬编码秘密。这些资产往往不在主要船队管理数据库的覆盖范围内。

下一项任务是暴露面映射。管理员应识别哪些网络能够访问受影响组件。其中应包括远程支持路径、虚拟专用网络、卫星链路、服务笔记本电脑和岸基管理系统。

CISA 建议尽量减少控制系统设备的网络暴露，并防止直接互联网访问。它还建议将控制网络置于防火墙之后，并与业务网络隔离。远程访问应采用 VPN 等安全且更新的方式。

这些做法是有用的补偿性控制措施，但无法消除硬编码密钥。网络分段会减少攻击者可利用的路径数量，却无法让已经嵌入软件的秘密重新具备唯一性。

运营商应将更新和管理流量限制在获批准的系统之间。防火墙规则应明确指定来源、目标和服务。对宽泛“受信任网络”例外的审查应立即开展。

团队还应审查认证记录。有价值的证据包括特权登录、失败连接、意外的客户端身份以及维护窗口之外的访问。该公告未提供入侵指标，因此本地基线变得尤为重要。

更新日志需要单独关注。防御人员应保留软件包清单、签名、哈希、时间戳、服务重启记录和部署结果，并将这些记录与获批准的维护活动进行比对。

日志干净并不能证明从未发生利用。日志可能不完整，恶意代码也可能干扰记录。不过，保留遥测数据能为事件响应人员的调查提供更坚实的基础。

凭证处理同样需要审查。如果受影响的客户端密钥能够冒充特权用户或服务，团队必须确定哪些下游系统接受该身份。在供应商确认正确流程后，他们应撤销或轮换相关凭证。

未经协调的凭证变更可能破坏关键服务。海事运营商应在获批准的维护流程中测试这些变更。紧急访问必须保持可用，但不能继续保留易受攻击的信任路径。

安全团队应在进行变更前验证备份。可用备份应包含所需配置和支持数据，且不应悄然恢复易受攻击的二进制文件或已受损凭证。

在条件允许时，补丁应先进入具有代表性的测试环境。测试应覆盖核心 FOS 功能、通信、更新验证、认证和恢复，还应确认被禁用或替换的组件始终处于非活动状态。

对于分布式船队而言，安装证据十分重要。每艘船舶都应报告补丁标识符、完成时间、最终版本和验证结果。中央团队应将这些记录与资产清单进行核对。

任何例外情况都需要负责人和到期日期。等待维护窗口的船舶应实施记录在案的临时控制措施，包括更严格的网络限制、禁用未使用服务以及加强日志审查。

有关推荐安装方式的公开说法同样需要澄清。运营商应询问 Wärtsilä：究竟哪些具体设置能够防止利用。没有配置细节的表述不能作为可测试的安全控制措施。

防御人员需要知道，这一说法是否依赖网络分段、禁用组件、证书设置、端口限制或其他条件。他们还需要一种方法，验证每艘船舶是否满足该条件。

该公告并未证实的内容

这些漏洞属于严重级别，但公开证据并不支持有关正在遭受利用、船舶已被攻陷或可直接控制航行的说法。

CISA 的公告描述的是潜在利用后果，而非已经确认的攻击活动。公告称，目前未发现针对这些漏洞的已知公开利用。CVE-2026-78225 和 CVE-2026-81855 被作为产品安全发现发布。

这一差异十分重要，因为一些二手摘要以更激进的方式描述了该事件。高 CVSS 评分表明，在评分假设下可能造成严重技术后果，并不意味着攻击者正在积极利用该漏洞。

该公告也未指出面向互联网的服务或端口，未提供概念验证、利用序列或所需网络位置。对于 CVE-2026-78225，较高的攻击复杂度表明还存在额外条件。

根据其公开向量，CVE-2026-81855 的攻击复杂度较低。即便如此，攻击者仍需获得对相关组件的网络访问权限。公告没有说明该组件在真实部署中通常有多容易被访问。

Wärtsilä 关于推荐安装方式的声明带来了另一项不确定性。它暗示受支持的架构可以阻止利用。然而，若没有精确的配置基线，客户无法独立评估这一说法。

受影响部署的范围同样未知。全球范围标签意味着该产品在国际范围内使用，并不表示每位客户都在运行易受攻击版本。没有公开来源提供暴露船舶数量。

历史客户公告提供的是产品采用情况的背景，而非当前漏洞暴露情况。软件版本、网络设计和维护状态会随时间变化。未经确认就点名客户，会形成缺乏依据的关联。

对船舶安全的影响同样尚未得到证实。FOS 支持运营和航次相关工作流，但公告并未报告失去对转向、推进或导航的控制。其重点是更新、代码执行、凭证和特权冒充。

这些影响依然严重。代码执行可能让攻击者在受影响环境中运行未经授权的指令。凭证窃取则可能帮助攻击者跨越另一道安全边界。

不过，后续影响取决于权限和集成情况。应用主机遭攻陷并不自动意味着能够控制所有连接系统。网络分段、允许列表、认证和应用程序设计仍会影响最终结果。

两项发现对可用性的影响也不同。CVE-2026-78225 在其 CVSS 3.1 向量中具有高可用性影响。按照该版本评分系统，CVE-2026-81855 则未列出直接可用性影响。

运营商在向高管或船员进行简报时应保留这些区别。将每个漏洞都视作船舶控制紧急事件，可能导致错误决策和告警疲劳。低估更新链风险则会造成相反的问题。

审慎的简报应说明已知事实。一个已命名的 FOS-Onboard 版本包含两个硬编码密钥漏洞。利用可能破坏更新机制、执行代码，或暴露用于特权冒充的凭证。

随后应说明哪些信息仍然未知。公开来源未量化受影响船舶数量，未定义所有利用前提条件，也未确认固定修复版本。它们同样未报告已观察到的利用活动。

这一证据边界有助于团队理性确定优先级。团队可以迅速开展资产盘点、隔离控制和补丁协调，而不应将推测包装成事件情报。

它也帮助调查人员识别态势变化。如果 Wärtsilä 发布修复版本或配置指南，响应措施便可更加精确。如果 CISA 增加利用证据，组织则可升级监测和事件响应。

在此之前，最稳妥的立场既不是恐慌，也不是轻视，而是在已记录的假设、保全的证据和供应商直接确认的支持下，有序推进修复工作。

接下来需要关注的三个信号

下一阶段取决于可验证的修复版本、更清晰的部署指南，以及有关利用活动的可信证据。

第一个信号是明确列出的修复版本。客户需要的不只是确认补丁已经存在；他们还需要一个可供资产团队发现、合规团队验证的发布标识符。

公开的修复版本可为运营人员提供可衡量的目标，从而增强响应能力。它也能减少那些未运行 5.07.0923.01、但共享相关组件的系统所面临的不确定性。

发布指南应说明两个硬编码密钥是否都已被移除或替换。它应解释安装过程是否会为每次部署生成唯一凭据，并明确任何必要的轮换步骤。

第二个信号是详细的推荐配置基线。Wärtsilä 表示，正确安装的系统不可被利用，但公开报道并未描述这一安装状态。运营方需要能够审核的技术条件。

有用的指南应明确所需网络分区、防火墙规则、应禁用的服务、允许的管理来源以及远程支持控制措施。它还应区分永久性要求与临时缓解措施。

这些信息可能强化或削弱当前的风险评估。如果大多数部署已符合该基线，实际的即时暴露面可能比评分所显示的更窄。如果该基线要求不常见的设置，则可能有更多船队需要紧急隔离控制。

第三个信号是利用状态的任何变化。CISA 的工业控制系统指南支持网络分段、受保护的远程访问和影响分析。在利用尚未得到确认时，这些措施仍然适用。

若出现活跃滥用的证据，响应方式将发生变化。运营方需要超越补丁管理，转向覆盖全船队的威胁狩猎和事件调查。他们还需要与受影响服务及更新流程相关的指标。

未被列入已知遭利用清单，并不能证明安全。这只意味着公共机构尚未在该计划下确认利用活动。安全团队应继续审查本地证据。

运营方还应关注供应商面向客户的直接通知。这些消息可能包含不适合公开公告的细节，包括软件包标识符、服务端口、安装前提条件或检测指南。

每个船队都应将这些信号转化为决策节点。修复版本应触发部署跟踪；精确的配置基线应触发合规验证；利用证据应触发事件响应升级。

目前，实际可行的响应措施很明确：识别每一套 Wärtsilä FOS-Onboard 5.07.0923.01 安装，获取供应商补丁，限制特权访问路径，并保留相关日志。要求 Wärtsilä 书面确认修复版本及所需的密钥轮换措施。

打完补丁后，更棘手的问题随之而来：每个运营方能否证明，每艘船舶如今都使用唯一的信任材料，并且仅接受来自经身份验证来源的更新？决定这一更新信任缺陷是否真正得到关闭的，将是这种验证，而非安装完成的勾选框。