The advisory, published September 15, names CVE-2026-78225 and CVE-2026-81855 and assigns the affected product a vendor CVSS v3 score of 9.1. CISA says it has received no reports of public exploitation aimed specifically at these flaws. That is useful, but it should not be read as evidence that exposed systems are safe: the stated impact includes compromise of the software-update trust chain, not merely a local application crash or data leak.
The report was credited to Cydome Security Ltd. CISA’s public summary identifies use of a hard-coded cryptographic key, but it does not publicly separate the technical behavior, attack prerequisites, or mitigation for each CVE. That omission limits an operator’s ability to decide whether one issue can be neutralized through configuration while the other requires a software update. Until Wärtsilä publishes a fixed release and clear upgrade instructions, treating both identifiers as one urgent product-security incident is the prudent course.
The update path is the most consequential risk
Unauthorized-update capability deserves particular attention in marine operations. A successful attack on an update mechanism can turn a signed or trusted-looking maintenance workflow into a delivery channel for attacker-controlled code, potentially bypassing the operational skepticism that would normally greet an unfamiliar executable on a vessel network.
CISA also says an attacker could execute code and extract credentials that enable impersonation of a privileged client. Those outcomes can reinforce each other: stolen credentials may provide access to management services, while code execution could be used to collect additional secrets or alter a system before operators recognize that an update was not legitimate.
The advisory does not say whether exploitation requires network access, prior authentication, a man-in-the-middle position, physical access, or user interaction. It also does not identify the service, port, certificate store, key material, or administrative workflow involved. Administrators should therefore avoid narrowing their response to a single assumed exposure path such as public internet access. A system may be unreachable from the internet yet still be vulnerable through a remote-support connection, shore-side operations network, vendor-maintenance tunnel, or another vessel-connected segment.
Inventory the exact FOS-Onboard build before changing anything
The known affected version is unusually specific: FOS-Onboard 5.07.0923.01. That makes version discovery more valuable than broad, disruptive changes made without confirming which ships or endpoints actually run the vulnerable build.
Start with fleet and vessel-side inventories, including systems that may not appear in a conventional Windows asset-management platform. Check installed-application records, product administration consoles, image baselines, maintenance documentation, remote-support inventories, backup images, and any local software directories used by the onboard installation. Preserve the resulting evidence with vessel name, device role, IP address or host name, installed version, network segment, last maintenance date, and the party responsible for administration.
Do not assume that a newer-looking system is unaffected. CISA named an affected build, but its summary does not identify a first fixed version, a patch package, or a version range that has been tested safe. “Different from 5.07.0923.01” is not a substitute for a vendor-confirmed remediation state.
Where a vessel uses standardized images, investigate whether 5.07.0923.01 was included in a deployment package or carried forward during a hardware replacement. The most difficult systems to account for will be offline spares, training systems, lab machines, disaster-recovery images, and shore-side replicas used to troubleshoot or stage configuration changes.
Isolate management access, not vessel operations blindly
CISA’s standing guidance recommends minimizing network exposure for control systems, placing industrial networks behind firewalls, separating them from business networks, and using updated VPNs where remote access is required. Those measures are especially relevant here because the advisory’s stated impacts center on privileges and updates.
For a confirmed or suspected installation, organizations should immediately review who can reach the FOS-Onboard management and update functions. Remove unused remote accounts, disable dormant support connections, verify that vendor and contractor access is individually authorized, and require strong authentication where the product’s architecture supports it. Restrict access to known administrative workstations and approved maintenance networks rather than leaving services broadly reachable from shipboard user networks or corporate segments.
Operators should also place extra scrutiny on update-related activity. Retain logs that show attempted updates, service restarts, administrative logons, certificate or key changes, newly created accounts, and unexpected outbound connections from FOS-Onboard hosts. If the product or its surrounding infrastructure produces package hashes, update manifests, or audit records, preserve them before routine log rotation removes the evidence.
This response needs operational change control. CISA explicitly advises organizations to perform impact analysis and risk assessment before deploying defensive measures to industrial systems. A sudden firewall rule or remote-access shutdown can disrupt data exchange or support workflows that crews depend on, particularly at sea. The answer is a controlled restriction of administrative exposure, with a documented rollback path—not an untested network change made during a voyage.
Wärtsilä’s public material leaves the patch question unanswered
The public CISA advisory identifies the affected release but does not state a fixed FOS-Onboard version, an update availability date, a workaround specific to either CVE, or whether Wärtsilä has notified customers directly. It also does not say whether the issues affect only a particular deployment architecture, hardware platform, or module configuration.
Wärtsilä’s public FOS downloads page contains a separate warning that vessels connected through Wärtsilä Cloud Manager Service 1.0 need firewall-rule changes before September 30, 2026 to avoid losing ECDIS and FOS connectivity. That notice is operationally important, but it is not presented as a fix for CVE-2026-78225 or CVE-2026-81855. Administrators should not treat the upcoming Cloud Manager transition as evidence that the FOS-Onboard vulnerabilities have been remediated.
The vendor’s broader cybersecurity page says Wärtsilä accepts product vulnerability reports and directs customers to their regular support channel for product incidents. Given the missing public fix information, affected operators should use that channel to request a written answer covering the fixed version, update package provenance, supported upgrade path, affected components, required downtime, and whether any compensating configuration is approved for systems that cannot be patched immediately.
What Windows and fleet IT teams should do now
For Windows administrators supporting vessel operations, this is an asset-and-trust problem first. The advisory does not establish that Microsoft Windows itself is vulnerable, and it does not identify an operating-system dependency. But Windows-based management endpoints, virtual machines, jump hosts, file shares, and remote-access systems may form the route through which privileged FOS-Onboard administration occurs.
The priority sequence is straightforward:
- Identify every instance of FOS-Onboard 5.07.0923.01, including spares, test systems, and images.
- Limit update and administrative access to approved networks and named personnel.
- Review privileged-client credentials and remove accounts or access paths that are no longer necessary.
- Preserve update and authentication logs, then investigate anomalous activity before making broad cleanup changes.
- Obtain vendor-confirmed remediation guidance before upgrading or assuming that a connectivity-related firewall change resolves the CVEs.
CISA’s September 15 advisory establishes a serious issue in one named FOS-Onboard build, but the public record still lacks the details operators need to close it confidently. Until Wärtsilä publishes a fixed release and deployment instructions, the defensible position is to contain access to the affected software, protect its administrative credentials, and treat every update workflow touching that build as a high-value security boundary.