I did not plan another Special Edition this soon. SE02 went out yesterday. But on Tuesday, a security researcher published a 732-byte Python script that gives any unprivileged user root access on Linux systems shipped since 2017, provided a specific kernel module is loaded.

The vulnerability is called Copy Fail (CVE-2026-31431). It sits in a kernel cryptographic module that ships enabled by default. The exploit is deterministic — no race condition, no timing tricks, no per-system tuning. The same script works on Ubuntu, RHEL, SUSE, Amazon Linux, and Debian. It bypasses read-only filesystems, secure boot, and container isolation.

That last part matters. Because a large and growing share of the systems that run your ship, your port terminal, and your offshore installation run Linux.

I spent the past few hours mapping which maritime systems are exposed. Here is what I found.

Linux runs across every layer of the maritime technology stack. Not just servers in the back office — embedded Linux sits inside bridge equipment, VSAT terminals, voyage data recorders, engine room gateways, tank gauging systems, port cranes, and industrial network switches.

Ogmios Maritime has identified 22 Linux-based maritime systems across 9 categories, from vendors including Moxa, Cobham, Danelec, Honeywell, ZPMC, Navis, Westermo, KVH, MAN Energy Solutions, and Intellian. Eight of those 22 have documented SSH or shell access. The rest almost certainly have maintenance interfaces that provide equivalent access.

Key Figures

The industry chose Linux for good reasons: stability, no licensing cost, resistance to Windows malware, long-term support. The irony is that this migration created a uniform attack surface. When one kernel vulnerability hits, it hits everything at once.

Why this matters: If you operate a vessel or port, you almost certainly have Linux-based systems in your environment. Most operators I speak with do not know which ones.

One thing to do: Ask your integrator or OEM for a list of every Linux-based system onboard or in your terminal. If they cannot produce it, that is the first problem.

Not all 22 systems are equally exploitable. Copy Fail needs three conditions: a kernel built after August 2017, the algif_aead cryptographic module loaded, and a way to run code locally (SSH, serial console, USB, or a chained remote exploit).

Three systems meet all conditions with minimal effort:

Cobham SAILOR 900 VSAT — The antenna control unit runs embedded Linux with SSH on port 22 and Telnet on port 23. The default credentials (admin / 1234) are documented in the installation manual and, based on penetration testing reports, frequently left unchanged. Legacy web vulnerabilities (CVE-2022-22707, CVE-2019-11072) provide alternative entry. Once an attacker has a low-privilege shell, Copy Fail gives root on the vessel's primary internet gateway. Tens of thousands of these units are deployed globally. They are OEM-locked — operators cannot patch independently.

Moxa Industrial Linux (Debian 9/11) — Moxa edge computers and switches are the backbone of many vessel and port OT networks. They run Debian-based Linux with SSH access on documented default credentials. The good news: Moxa uses standard Debian packaging (SecureApt), so operators can apply kernel patches independently. The bad news: the original Python exploit requires Python 3.10+, which Debian 11 does not ship — but a C port of the exploit already exists on GitHub and bypasses that limitation.

Navis N4 Terminal Operating System — The dominant container terminal OS, running on enterprise Linux servers at over 250 ports. CISA recently flagged a separate critical vulnerability (CVE-2025-2566, CVSS 9.8) — a Java deserialization flaw allowing unauthenticated remote code execution. Chain that with Copy Fail and an attacker can go from zero credentials to root on the TOS backend without ever needing local access. If the server runs RHEL 9.x, the standard mitigation (disabling the algif_aead module) does not work because it is compiled into the kernel as a built-in.

Why this matters: These three systems represent the vessel's internet gateway, its OT network backbone, and the port's operational brain. Compromising any one of them gives an attacker a pivot point into everything else.

One thing to do: Check whether your SAILOR VSAT still uses default credentials. If SSH is open on port 22 with admin/1234, you have an immediate problem that predates Copy Fail.

Copy Fail was patched in the Linux kernel mainline on April 1. Ubuntu, RHEL, and SUSE have already pushed updates. For a corporate laptop, this is a routine Tuesday patch.

For maritime OT, it is months of waiting.

The problem is type approval. Navigation systems, VDRs, and engine controls must hold certification from classification societies (DNV, Lloyd's, Bureau Veritas, ClassNK). The operator is legally and technically prevented from modifying the operating system kernel. They must wait for the OEM to develop a firmware update, test it, submit it for recertification, and distribute it — a process that routinely takes 3 to 12 months.

During that window, every affected system is exposed.

There are three complications specific to Copy Fail:

Read-only filesystems do not help. Honeywell engineered the Enraf CIU 888 with a read-only OS partition specifically to prevent unauthorized modification. Copy Fail bypasses this entirely because it corrupts the in-memory page cache, not the disk. The file on storage remains untouched. Forensic tools that check file integrity on disk will see nothing wrong.

Secure boot does not help. Danelec VDRs use hardware secure boot to prevent unauthorized code from executing at startup. Copy Fail operates after boot, at runtime, by manipulating how the kernel handles cached memory pages. The boot chain is never violated.

Container isolation does not help. The page cache is shared across all processes on the same host, including containers. An attacker inside a restricted container can corrupt a setuid binary on the host and escape. A Kubernetes proof-of-concept for this already exists on GitHub. This matters for port TOS deployments running containerized microservices and edge IoT platforms on vessels.

Why this matters: The security assumptions built into maritime Linux systems — read-only partitions, secure boot, containerization — do not protect against this class of vulnerability. Copy Fail operates in a layer below all of them.

One thing to do: Where you have shell access (Moxa, KVH, Westermo, any IT-managed Linux server), check whether you can disable the algif_aead module: lsmod | grep algif_aead. If it is loaded, blacklist it: echo 'install algif_aead /bin/false' > /etc/modprobe.d/disable-algif.conf && rmmod algif_aead. This breaks the exploit chain without waiting for a kernel patch.
Warning: on RHEL/Rocky/Alma 9.x this does not work because the module is compiled in — only a kernel update helps.

Until today we have not seen any maritime OEM issue a Copy Fail advisory yet. Here is what we expect based on past kernel vulnerability response patterns:

Why this matters: The patch gap between IT-managed and OEM-locked systems will be measured in months. During that time, the exploit is public, the C port removes the Python version limitation, and every confirmed maritime Linux system is a potential target.

One thing to do: Segment your network. The single highest-impact action is ensuring that a compromise of a crew laptop or a phished admin credential cannot reach the SSH port of your VSAT terminal, VDR, or engine room gateway. If those systems are on the same flat network as crew Wi-Fi, Copy Fail is the least of your problems.