Fire detection system been pwned? You’re not going to sea

TL;DR

• Hardcoded SSH and VNC credentials found on Consilium Salwico CS5000 panels
• SSH access allows OS-level interaction, and VNC access gives UI control
• It may be possible to disable the fire detection system
• Attempts to disclose vulnerability to Consilium multiple times since 2022
• Consilium confirmed no patch will be provided
• If your onboard systems predates IACS UR E27 (July 2024), it was likely not designed with security in mind

CVE-2025-46352 – Default Account
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8 Critical severity)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N (9.3 Critical severity)
https://www.cve.org/CVERecord?id=CVE-2025-46352

CVE-2025-41438 – Hardcoded VNC Credentials
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8 Critical severity)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N (9.3 Critical severity)
https://www.cve.org/CVERecord?id=CVE-2025-41438

Affected version: Consilium Safety CS5000 Fire Panel

No Fix available

The Consilium Safety CS5000 Fire Panel allows access through different mechanisms using default settings. A default account exists which allows high level permissions that could impact the device’s operation. These credentials can be altered by SSHing into the device.

A default password is set on the device’s VNC server which can be extracted from the VNC binary. The access granted through VNC allows remote access to all features of the panel. This password is static and cannot be changed.

Disclosure timeline
2020-12 – Vulnerability identified
2022-12 – Contacted Consilium using web and email
2023-04 – Contacted Consilium using web and email
2024-11 – Contacted Consilium using web and email
2025-01 – Reported to CERT/CC

Introduction

Fire remains one of the greatest risks aboard vessels, governed by strict regulations covering detection, suppression, emergency response, and crew training. Early detection is critical, and ships typically use robust fire detection systems – often with redundant panels.

On large cruise ships, the safety centre will often have a system called the Safety Management System (SMS) that allows monitoring and control of systems vital to safety, including the fire detection system, CCTV, ventilation, firefighting equipment, watertight doors, shell doors, public address system and so on. The SMS glues these different systems together, allowing them to be interacted with using a “single pane of glass” rather than discrete controls.

Systems interaction

To interact with these different systems, the SMS needs some form of connection to them. Whilst in the past this would have used discrete I/O or a serial bus like RS485, it is increasingly common to find Ethernet used, with a variety of different protocols used to transfer data. Modbus TCP/IP and proprietary UDP protocols are common, but sometimes more esoteric mechanisms are used.

Whilst the movie-plot scenario of remotely controlling a ship is often the first thing that people think of when hacking ships, there is always a human in the loop for vital control systems. They can nearly always take manual control and avert an incident.

The likely threat

A more likely threat, in our opinion, is causing significant impact to operations using denial-of-service to a vital system. If an attacker can stop the fire detection system or Voyage Data Recorder (VDR) working, the vessel is no longer compliant with regulations. This could lead to the vessel being detained by Port State Control, or having their certificate of class revoked. You may not be able to sail. This is not ideal when you have thousands of passengers onboard.

It’s for this reason that we often focus on compromising the SMS and then impacting connected systems such as the VDR and fire detection system. We decided to look at how communications were carried out with a common fire detection system panel – the Consilium Salwico CS5000. By visual inspection, we’d already seen that it had Ethernet connected. But as always, the devil is in the detail – what protocol was used to transfer data, and what protections are in place?

Investigation

After a bit of ferreting, we’d found a script file on one of the SMS servers. This used secure copy (SCP) to login to the fire panel and download a file containing the required data. The script contained the username and password used to login to the panel. Whenever we see an SCP login, our first thought is “does this also allow full SSH shell access?”. The answer to this question was yes – we could login over SSH and interact with the fire panel.

Although the account was not root, they had significant permissions over the filesystem. It would certainly be possible to temporarily impact operation of the panel, and highly likely that it could be rendered inoperable until a service engineer attended the vessel.

Using netstat, we could also see that the device was listening on port 5900 – normally used for VNC. Attempting to connect required a password. The binary running this service was not a traditional VNC server and appeared to be custom for the panel. Running the tool strings on the binary allowed us to quickly identify the password, at which point we could login over VNC and interact with the user interface of the fire panel.

As a result, with network access to the fire panel, we could render it inoperable. We were unable to confirm what actions could be carried out over VNC, but it is suspected that all normal actions could be carried out, including sounding the alarm.

It may be possible to change the SSH account password, but no documentation could be found to confirm if this was safe to do.

The VNC password was hardcoded in the binary and we could see no mechanism to alter the password.

Neither account appears to be openly documented.

Because the issue has not been fixed, we have decided not to openly disclose either password.

Disclosure

We first found this issue in 2020. It took some time for us to validate that this was not just on one vessel, but was consistent with all installs of the device across other vessels. We reached out to Consilium using email and web contact forms in December 2022, April 2023 and finally November 2024. Despite some replies, they were fixated on the IMO number and name of the vessel, seemingly ignoring that the issue impacts all CS5000 panels running the same firmware. There is still no clear way to report vulnerabilities in their products.

Eventually a helpful sales manager picked up the issues and forwarded it to the right people at Consilium.

“Consilium has taken notice of the found vulnerability and will consider this threat for future installations. It is important to understand that the vessel from where this vulnerability has been exposed did not have any cybersecurity clauses attached to it. Consilium were not committed to work with cybersecurity threats as it was not something that was prevalent or mandated by the industry, but rather the focus was on the reliability and safety of a fire detection system. If an error is found that would be considered erroneous by nature causing the system to malfunction or producing intermittent failures on the system, then we would correct that with a SW update, because we are committed to provide a Fire Detection System that shall operate safely and reliably. However, the same cannot be said for cybersecurity threats that are found for a system that was delivered long before IACS UR E26/E27 was mandated, i.e., 1st of July 2024. Threats are a category of its own and the FDS was not designed to be secure for malicious intents, therefore we will not patch the system delivered for this vessel to secure it from the vulnerability that was discovered. Rather, we would suggest that compensating countermeasures are introduced by the asset owner in terms of physical security and access control restrictions for vessel personnel.

For Contracts signed after 1st of July 2024 Consilium is committed to comply with IACS UR E27 as per the Plan approval process. For more information, please refer to statement attached in this mail.”

Unfortunately, Consilium’s response indicates that they will not fix the issue on older panels. None of our clients who use the system have been made aware of the vulnerabilities by Consilium.

As Consilium say, if the vulnerabilities are not being fixed, compensating countermeasures should be put in place. But how would one of their customers be aware that they need to do this if the vulnerabilities are not openly disclosed?

By virtue of Consilium accepting the risk of these vulnerabilities, they have transferred the risk to their customers.

What should you do?

For those of you with these panels onboard, what would we suggest?

Firstly, confirm if your panels are Ethernet connected. Most panels do not use Ethernet to connect to other systems. Discrete I/O and RS485 would not allow network access. On every cargo vessel we have seen the CS5000 on, it has not been Ethernet connected.

If the panel is Ethernet connected, what is the connection used for and what other systems are connected to it? There is a chance that the system is air-gapped from others, largely mitigating the risk.

If the CS5000 is connected to other systems, such as the SMS, then the protocol used to transfer data needs to be discovered. If this is not SCP, a firewall could be placed between the two systems to only allow the required protocol and block risky SSH and VNC. However, if SCP is used, it is very difficult to detect the difference between normal usage (copying files) and abuse (use of the shell).

At a simple level, they both look like conventional SSH sessions over port 22. In this case, it is recommended that the design and hardening of the SMS is checked to ensure it is as difficult as possible to access the fire detection system in the first place. It may be possible to rearchitect the system so that an intermediate device carries out the transfer of data, but this is a significant redesign and would likely need multiple vendors involved.

Finally, consider putting in place procedures to handle the eventuality that your fire detection system is rendered inoperable. What actions need to be taken? Who needs to be informed? How quickly can the system be restored to working condition?

Takeaways

• Disabling safety-critical systems, even temporarily, can prevent a vessel from sailing, causing major operational disruption.
• If your systems were installed before IACS UR E27, security may not have been considered during design.
• Vendors are unlikely to patch vulnerabilities unless contracts explicitly require security compliance.
• A solid asset inventory and network map can help identify high-risk systems and guide prioritisation.