The thread: in each story the effect is visible from outside and the cause is not. Most of what you should do this week does not need to wait for the cause.

On 12 October, in 23 minutes between 13:53 and 14:16 UTC, the extortion group n0n added 38 shipping and port organisations to its leak site, according to the ransomware.live tracker. The list reads like a slice of the container trade. It has terminals in Brazil, Spain, Morocco, Türkiye, India, Vietnam, Saudi Arabia and South Korea, lines including Ocean Network Express, T.S. Lines and CULines, port IT and EDI providers, ship agents and depots, and three companies outside shipping: the crane maker ZPMC, Apical Group and Dongkuk Steel. What the group says it holds is narrow and repetitive: EDI message archives (BAPLIE stowage plans, CODECO gate moves, COPARN bookings), terminal operating system deployment and configuration records, release documentation and invoices. Every entry carried the same countdown: files publish on 19 October at 13:27 UTC.

The deadline passed on Monday afternoon. At 15:20 UTC, almost two hours later, all 38 entries on the tracker read exactly as they had a week earlier, and the tracker's last visit to the group's own site, at 14:48 UTC, recorded it as unavailable. That tells you less than it seems. A tracker does not necessarily relabel an entry when files appear, and we do not visit leak sites to check. What we can say is narrower. No entry carries a domain, so even the identity of each victim rests on a name the attacker typed. And by Monday evening we had found no listed organisation confirming an incident. The on-record words we found are Korean. Dongkuk Steel called the posting "only the hacking group's unilateral claim, and actual damage has not been confirmed" (NGetNews, our translation), and Korea's internet security agency KISA has been notifying the Korean companies named, according to BoanNews.

The most developed explanation so far comes from Cydome, and we disclose first that Cydome is a commercial partner of our parent company in Poland. In an analysis published on 16 October, Cydome concludes that the data is "likely linked to data from CyberLogitec", a Seoul-based maritime software company. Its evidence: at least 21 of the 38 are documented CyberLogitec customers, seven of the 85 sample file names published by the group carry the vendor's or a product's name, and the dated files run from 2009 to August 2026. Its interim reading is "a support and project archive that originated at, or is linked to, CyberLogitec and relates to its customers", split by the group into separate victims. "This is not confirmed," Cydome writes. CyberLogitec told the Korean logistics outlet Daily Log on 13 October that "the companies mentioned are indeed our customers" and that it was establishing the facts (our translation). It has said nothing more that we could find. SOCRadar, which first reported the listings, reached a similar shape without naming a vendor: the volumes look like "the footprint of a single application's data store rather than a compromised corporate network".

Why this matters for maritime: if the hypothesis holds, the breach is not in 38 networks but in one place where their working material piled up over seventeen years: support tickets, release notes, sample EDI files, configuration exports. Whether your bookings are in a file like that does not depend on your own security. It depends on what your partners sent their software vendor.

What to do: Check which of the 38 you exchange EDI messages with, and ask each of them in writing whether they have assessed the claim and what of yours would be in scope. Search your own email and ticket history with software suppliers for credentials, network diagrams, database exports and configuration files, and rotate anything you find. Then ask every critical supplier where your support files live, for how long, and who can read them. And brief whoever handles payment instructions and booking changes, because manifests and booking messages are good raw material for fraud against shippers and consignees.

Test your response: Your container line appears on a leak site with a countdown and three file names you recognise from a support ticket. Your software vendor says your systems are fine. Customers have read the headline. What do you tell them before the deadline, and what after it? CMA CGM: Ransomware in the Container Kingdom →

On the evening of Tuesday 13 October, the IT systems of TNMSC failed. TNMSC is one of the container terminals at Port 2000 in Le Havre, France's largest container port; in 2022 the port authority described MSC's terminal arm, TiL, as its sole shareholder. On 15 October the regional news site Tendance Ouest reported that containers due to pass through the Terminaux de Normandie were stuck, that transhipment had stopped for imports and exports alike, and that the company's phone line appeared to be down.

HAROPA Port, the port authority, confirmed that it had been "informed of disruptions affecting the IT systems of a company located on the Le Havre port estate", without naming it, and said that "these difficulties are likely to have repercussions on port operations" (our translation). According to Cyberattaque.org, which relays the local paper Le Courrier Cauchois and a notice to partners, the terminal's management acknowledged a disruption of its information systems and a temporary suspension of cargo handling. Service to ships, receipt and delivery of goods, and data exchange with partners were all affected. Guarding and the monitoring of refrigerated containers continued. On 16 October Kuehne+Nagel told its customers that "an ongoing major technical incident at the Terminaux de Normandie is affecting container operations" and that pick-ups and drop-offs were disrupted. We found no public word of a restart by Monday evening.

Nobody has said what happened. Tendance Ouest wrote that some port workers spoke of a cyberattack, and the operator has neither confirmed nor ruled one out. The same week brought a separate signal. On 14 October M-CERT, the French maritime CERT run by France Cyber Maritime, warned ports and shipowners that the pro-Russian group NoName057(16) was targeting the French maritime and port sector. Its DDoS attacks, the alert said, were "under way or likely to be launched imminently" (our translation, from a copy of the alert published by the French site Bourse Inside). The group named the ports of Marseille and La Rochelle and three maritime companies. No source links that campaign to Le Havre, and a flood of traffic against a public website would not on its own explain a terminal's internal systems going down.

Why this matters for maritime: in the first days, the most precise public description of what had stopped at a terminal in France's largest container port came from a freight forwarder's customer notice and a regional news site. The operator spoke only of a "perturbation" of its systems. Shippers had to plan around the effect long before anyone named the cause, and they may never hear it.

What to do: If you run a terminal, write your day-one notice now, before you need it: what has stopped, what still works, how customers can transact in the meantime, and when the next update comes. The line about refrigerated containers in this notice is the kind of detail customers look for first, and none of it requires knowing the cause. If your cargo moves through a single terminal, know who decides on diverting it and how release works when that terminal's systems are down. And if a hacktivist campaign hits your sector in the same week as an outage, say clearly in your own updates whether it is your website that is down or your operations.

Test your response: Your terminal's systems go dark on a Tuesday night. By Thursday the regional press has the story, workers are talking about a cyberattack, and you still do not know what happened. What goes into the first notice to lines and forwarders? Port of San Diego: When Ransomware Meets the Harbor →

Last week we wrote that a satellite image of empty sea proves a ship's broadcast position was false but not why, and that from orbit, deception and interference can look the same. On 16 October Kpler, the trade and shipping data company, published a whitepaper on that problem, "False Positions at Sea: Distinguishing AIS Spoofing from GNSS Interference". Its summary is direct: "GNSS interference now affects whole regions, while deliberate AIS spoofing is a vessel-level act, and the two can produce near-identical tracks. Treating them alike risks turning a regional disruption into a compliance accusation, or missing genuine concealment."

The paper draws on Kpler's sanctions data on 910 vessels from 2025 and 2026. Its first takeaway is "Attribution comes first": respond "to the evidence of cause, not the abnormal track". The second is one a bridge team will recognise: "Onboard systems often share one bad input." If a single receiver feeds the AIS transponder and the ECDIS, a spoofed signal makes both agree on the wrong position, and agreement between them proves nothing. The third concerns what spoofing is worth as evidence. It "preceded designation in 36.3% of sanctioned vessels in Kpler's sample", which Kpler calls "an early signal, not proof". We have read the summary. The full paper sits behind a registration form, so we cannot tell you how Kpler separates the two causes in practice.

Why this matters for maritime: Kpler writes for traders, charterers and compliance teams, and its advice to them is to look for the cause before making the accusation. When the question reaches a ship operator, the evidence of cause is on the bridge, and it exists only if somebody recorded it at the time.

What to do: Check which bridge systems take their position from the same GNSS receiver, because those will be wrong together. Make sure the deck log records every episode of interference: the time, an independent position from radar or a visual fix, what the GNSS showed, and when it recovered. And give your compliance team the vocabulary before a charterer does: interference is something done to the ship, deliberate spoofing is something done by it, and the same track can come from either.

Test your response: Your tanker's AIS and ECDIS agree on a position two miles inland. An hour later the charterer's screening tool flags a spoofing event and asks for an explanation. Who on board knows what to record, and who ashore answers? HORMUZ HAZE: The Tanker That Couldn't See, Couldn't Stop, Couldn't Call →

Full calendar, with cyber tracks flagged: https://mc3.maritime-ogmios.tech

Unconfirmed signals from open-source and regional channels we monitor. Confidence is flagged on each item. Treat these as early warning, not fact, until confirmed.

Patriot Maritime (single source: the attackers' listing), listed by Storm on 19 October. The listing carries no domain. Its name and its address in Concord, California match the US-flag operator that Marine Log described in June 2024 as managing seven Ready Reserve Force ships for the US Maritime Administration and eight Watson-class roll-on/roll-off ships for Military Sealift Command. The listing says nothing about what was taken.

Codar (single source: the attackers' listing), listed by Orova on 13 October. The domain on the listing, codar[.]com[.]sg, belongs to a Singapore supplier of marine radio communications and navigation equipment. The group claims 161,7 GB. Like Story 1, it is a reminder that a supplier can hold a good deal about the ships it serves.

Everything else about both is the attackers' claim: no statement from either company.

MGN 719 (M+F), "Operating in GNSS denied and degraded environments" (Maritime and Coastguard Agency, GOV.UK, published 1 October 2026)

The document behind our first correction. It is guidance, not a requirement, addressed to shipowners, masters, harbour authorities, port operators and VTS providers. Two things in it are easy to miss. It treats timing as a dependency in its own right, including networks synchronised by NTP or PTP. And the government estimate it quotes for a seven-day GNSS outage puts about £1309 million of the £1,5 billion maritime loss on port operations, against £183 million for shipping.

MGN 719 on GOV.UK →

Maritime Cyber Intelligence Brief covers what the weekly cannot: full incident timelines, regulatory analysis, GNSS threat data, and OT advisory breakdowns. The latest issue is a free preview.

Read the Intelligence Brief →

"Zero Trust and Third-Party Risk: Reduce the Blast Radius", by Gregory C. Rasner, 2023.

A practical book, built around a fictional company, on applying zero trust to the access and data you give suppliers.

Relevant this week because Story 1 may turn out to be about what 38 companies had given one vendor.

Browse maritime cyber book recommendations →