Back to the blog

Maritime cybersecurity

AI Is Finding Software Vulnerabilities Faster. What Does That Mean for Maritime Companies?

A customer portal can go blank on the same afternoon a ship alongside keeps working. On 21 October 2026 that split was on the news: faults in ordinary web software, and port processes that were reported as still running.

6 min read
A commercial container ship and terminal at dusk, wrapped in a faint blue mesh that suggests a cybersecurity layer over the port.

Picture a chartering desk in Rotterdam. Someone refreshes a customer portal and the page stays blank. A fixture recap sits half-written. The counterparty is waiting on a figure stored elsewhere.

That afternoon the picture met the news. NU.nl reported that the Port of Rotterdam website was temporarily unreachable. A spokesperson told the ANP there was no operational impact on port services or port processes. The port was mapping where PHP was used, and speaking with other harbour organisations through FERM Zeehavens, the cybersecurity organisation for the Dutch seaports.

A ship can still be alongside. The cargo plan does not leave the bridge because a public website has been switched off.

What was actually published on 21 October

PHP is a programming language for websites and web applications. It does the quiet work behind logins, forms and customer portals. On 21 October 2026 the PHP project published fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. On a server that still handles web requests with an affected version, either flaw can let someone who is not logged in run code. PHP rates both 9.2 on CVSS v4.0. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Updating is the safe choice. PHP says there is no complete substitute. PHP 8.1 and older no longer receive fixes from the PHP project itself, though some operating-system vendors still ship backports. An older installation then depends on that vendor, or on a move to a supported version.

Wiz Research says AI tools helped it find flaws that had sat in the code for more than ten years. NU.nl reported a further claim from Wiz: one researcher finished in about a week work that a strong team might previously have needed months to do. That speed is Wiz's account, not an independent measurement. NU.nl also reported that details circulated ahead of plan, and that organisations took sites offline while they updated. PHP had said on 20 October that the 21 October release might come sooner if details became public. The Dutch NCSC, as quoted by NU.nl, called it a fault in the language, not an attack already under way.

A website and a ship are different systems

PHP's advisory covers installations that serve web requests: portals, publishing systems and other server-side applications. That is the layer in which a port can switch off its public site for an afternoon while the quay continues.

The published record does not show these flaws in the control systems of a vessel, a crane or a lock. Engine control, dynamic positioning and similar operational technology are built and looked after as another class of system. The advisories describe a risk for web software. They do not describe a risk for the ship.

The industry already has names for the split. Information technology is the software of offices, records and portals. Operational technology is the equipment that moves steel, cargo and water. They have drawn closer: a planning screen near a machine, a dashboard reading a sensor. Our article on the port as software follows that in Rotterdam. This week still showed the limit. A website went down, and port processes were reported as unaffected.

A shore office and its screen, separated by dark water from a ship's bridge. A thin line of light stops before the vessel.
Business software can reach the quay. The bridge is another system, and a flaw in a web language does not cross that gap by itself.

Where maritime work actually depends on ordinary software

For a shipping company, a charterer, a broker or a port, the exposure worth naming is rarely the bridge. It is the administrative layer around the work.

Vessel-management software holds certificates, crew changes and the specification treated as current. Chartering runs through a portal, an inbox, a recap and a spreadsheet. A broker's operational database may be the only record of which ship was offered, and on what terms. A port website is the visible edge of planning tools and supplier logins.

PHP is one dependency among others. Wiz says it sits behind about 70 percent of websites. That figure is theirs. A charterer comparing three North Sea vessels already lives in the pattern: crane figures in three PDFs, a comparison in a sheet, confirmation in a portal the charterer does not run. Close that portal for a patch and the numbers are not wrong. They are unreachable, and people paste them into mail. We described that return to manual work in When should a maritime spreadsheet become software?.

Faster discovery helps, and it shortens the clock

There is a real gain. Flaws that had lasted for years were found and patched, with AI as part of the work. A software provider, or the firm hosting a chartering portal, can use that speed on the libraries it actually ships. Code can sit for a decade and become urgent in a day.

The same speed is available to anyone looking for systems that are still unpatched. A public fix also describes the gap, and PHP says updating is what closes it. A large host may do that within an hour. A vessel-management product on an old version, with a supplier who has no upgrade path, may not. Taking the service down means phones, mail and the last trusted spreadsheet. Leaving it up means living with the gap. For a database of vessel certificates, or the screen that confirms a ship is fixed, that choice is the operation.

Questions worth answering before the next one

A useful review starts from the workflow. This week's identifiers are only the occasion.

  • Which systems would stop a fixture, a crew change, a port call or an invoice if they were offline for a day?
  • Which of those are web applications, and which sit closer to the equipment?
  • Who is allowed to patch them, and how fast has that happened before?
  • Which versions already sit outside the maker's support window?
  • Where else does the same operational data live, so a portal outage does not erase the only copy?

A liner operation and a two-person broking desk will answer differently. They do not share a security department. They can share the habit of naming the systems. Smaller firms often cannot, because the software arrived one login at a time.

Providers face the same questions from the other side. The Vessel Comparison Tool on this site is a demonstration with fictional vessel data. It is a small chartering screen, not a client system and not a security product. The stack under a screen like it is easy to forget, and someone still has to patch it. That is also true of the maritime software we build.

Sources

Research speed and the share of websites running PHP are Wiz's claims. The Port of Rotterdam statement is NU.nl's report of comments to the ANP. Where the liveblog and the vendor notice describe the timing differently, both are linked.

The page failed. The ship did not.

The next flaw of this kind may turn up over a weekend, after a decade of sitting still. The company in a good position is the one that can say, without a meeting, which screens would stop, which equipment would not, and which supplier is supposed to update the difference.

A ship and a website can share a harbour. The software between them is where a maritime company spends its week, and where news like this arrives first.