The thread through all three: how do you know that the thing telling you something is what it says it is?

On 25 September I am running a cyber incident exercise at the Universidad Marítima Internacional de Panamá, with MTCC Latin America, as part of World Maritime Day. Up to sixty people, five teams, one incident, six decision turns. Saying it here rather than only in the calendar at the bottom, because it is three weeks away and because you should know when the person writing your newsletter has a commercial interest in something on that calendar.

The reason it is worth a paragraph rather than a line: the exercise is built on the problem this issue is about. Five teams get five different views of the same morning, none of them complete, and the machine-generated picture in front of them is not reliable. Nobody is told that. They have to work out that the screens and the physical world have parted company, and then they have to get up and cross the room to find the person holding the other half.

Attendance is through UMIP and registration is opening on their side now. If you are in the region and this is your work, it is worth asking them. And whatever happens in that room, I will write up what it taught us, including the parts that do not flatter us.

CISA advisory ICSA-26-237-07, 25 August 2026. JVNVU#95422936, the same day.

AIS is the layer of the maritime picture that nobody thinks about, because it works. A transponder announces who a vessel is, where she is and where she is heading, and everything downstream believes it: the traffic picture in the control room, the collision-avoidance display on the bridge next door, the port's arrival board, the sanctions screening tool at the bank.

A week ago today, CISA published an advisory on the Furuno FA-50, a Class B AIS transponder. Two findings. Hard-coded credentials, CVE-2026-59769, scored 9.1 critical. Missing authentication for a configuration function, CVE-2026-67578, scored 7.5. Both apply to every version of the product ever shipped.

The CISA page describes the effect in general terms, as advisories usually do: an attacker with access to the in-vessel network may alter the settings of the device. The source description, written by JPCERT and carried by NVD, is more specific, and it is the sentence worth reading twice:

Furuno's own notice says the same thing in its own words: an attacker on the vessel's internal network may manipulate the settings screen and tamper with its identification number and other information.

That is not a configuration problem. The identification number is the answer to the only question AIS exists to answer, and I have spent a week failing to think of a reading under which this is a medium-severity finding.

Now the part that decides what you can do about it. Furuno ended production of the FA-50 in October 2020 and states that software updates will no longer be provided. There is no patch. There will not be one. The vendor's remaining advice is to keep the device off the internet, to lock and manage the vessel it is installed on, and to consider the successor model, the FA-70, which is not affected.

Why this matters for maritime: Class B is not the SOLAS fleet. Class A is the carriage requirement for large commercial tonnage; Class B is the lighter, cheaper unit that sits on fishing vessels, workboats, tenders, pilot craft and small commercial hulls. So the exposed population is precisely the part of the fleet that has no security programme, no asset inventory, no patch cycle and often no shore IT function at all. And the harm does not land on the owner of the device. A transponder reporting the wrong identity is a problem for everyone reading the picture, which is the VTS operator, the terminal planning a berth, the bridge team taking avoiding action, and the compliance system deciding whether a hull is one it is allowed to serve.

There is one more thing in the advisory that is easy to skim past. Both vulnerabilities require access to the vessel's internal network. That sounds like a constraint, and on a well-run ship it is one. On a small vessel where the AIS unit, the plotter, the radar and somebody's laptop share a single unmanaged switch, and the router has been carrying a phone hotspot since 2019, it is not a constraint. It is a description of the network.

What to do: Find out whether you own any FA-50s, including on vessels you charter, tender or manage but do not own. If the answer takes more than a day, that is the more useful finding. Where they exist, treat replacement as the mitigation, because it is the only one that ends the problem, and price it now rather than at the next survey. Everywhere else, ask the question the advisory implies rather than states: which of your equipment is out of production, still installed, and therefore already past the point where a fix is possible? That list is not the same as your unpatched list, and almost nobody maintains it.

Test your response: if the position picture starts disagreeing with itself, which instrument do you believe, and how long does the argument take? Ghost Ships of the Black Sea — When GPS Lies →

Two listings, two days apart, both in our sector.

On 26 August a group calling itself The Gentlemen named TEC Container, a Spanish manufacturer of spreaders and container-handling frames, the equipment that lifts boxes on and off ships. On 27 August the Qilin group named a company it listed as Globalport Terminals.

Neither company has confirmed anything. Neither has denied anything. There is no coverage in Lloyd's List, TradeWinds, Splash247, gCaptain, Riviera or Port Technology, none in the Spanish trade press, and no statement from any regulator. Six and five days on, the listings are the whole of the public record.

That is ordinary. Most listings end that way, as the two we flagged last week did. What happens next is the part that put this in a story rather than a line in Scuttlebutt.

Because the companies said nothing, the description of the victim that entered circulation is the one written by the group claiming the attack. For TEC Container that description says the company is based in Algete, near Madrid, that it has been trading since 1988, and that it sells under the brands TECSPREADER and TECGENSET. Threat-intelligence blogs picked it up. Breach aggregators picked it up. It reached our own monitoring corpus, which is how I came to be reading it.

Then we checked it against the company's own website.

TEC Container says it was founded on 16 June 1976, by a naval engineer named Leonardo Moragón. Its plant is in Mejorada del Campo, not Algete. Independent business registries agree with the company, not with the listing. Twelve years and a town, wrong, in a description that has now been republished across the security industry without anyone stopping to open the company's About page.

The second listing is worse, and more instructive. We could not establish with confidence which company Globalport Terminals even is. There is a plausible name match to a port operator in the Philippines, and nothing whatsoever connecting the listing to it. So we are not going to print that company's name, because doing so would be the same failure this story is about, committed by us, one paragraph later.

Why this matters for maritime: I know several maritime security teams who now watch leak sites as a supply chain early-warning feed, and it is a reasonable thing to do. TEC Container is a genuine supplier of terminal equipment to ports in dozens of countries. If your terminal depends on that equipment, a claim against that supplier is worth knowing about. But the feed you are watching is authored by the attacker, including the part that says who the victim is and what they do. It is the one source in your intelligence picture with a direct interest in how the entry reads, and it is the one source nobody fact-checks, because checking it feels like doing the criminals' admin for them.

What to do: Keep watching the leak sites. Then add one step before anything based on a listing reaches a decision, a customer email or a board slide: open the named company's own website and confirm that the company described is the company you think it is. It takes two minutes and this week it would have caught a wrong founding year, a wrong town, and one victim who cannot be identified at all. And if the listing names a supplier of yours, treat contacting that supplier directly as the primary move, not the secondary one. They may not have replied to the criminals. They will usually reply to a customer.

Test your response: a claim lands against something your terminal depends on, and nobody will confirm anything for days. What do you move first? Port of San Diego — When Ransomware Meets the Harbor →

Yuancheng Liu is Head of Technology at Singapore's National Cybersecurity R&D Laboratories, and before that he spent five years building uncrewed surface vessel systems. On 23 August he published a write-up of two challenges he had submitted to the Critical Infrastructure Security Showdown, the operational technology capture-the-flag run by SUTD's iTrust centre. The qualifying round was a forty-eight hour online competition that closed in July.

His challenge is a maritime one, and not by decoration. It runs on a simulated ship: electronic chart plotter, NMEA 0183 compass, attitude gyro, rudder control and stabiliser control, wired together the way they would be wired together. Competitors have to work through the interconnections to reach the flags.

Buried in the write-up is a paragraph about something else entirely, and it is the reason this is in the newsletter rather than in my reading list. Liu describes what he built into the challenge to defeat automated AI solvers:

Read the list again as a design brief. False guidance that only a machine will find, because a person never sees it. Deliberate poison written for a reader that consumes text without judgement. A check on whether a key was physically pressed and a button physically clicked. Hints placed in an image and in an audio file, where a text-shaped reader will not look.

And when the platform decides it is dealing with an agent, it does not block it. It hands back a flag that reads: "Please update too the most advance LLM module for your AI agent", followed by a random string. The agent reports success. The team behind it finds out later.

The line Liu put in the story page, addressed to the competitor, is the one I keep coming back to:

Why this matters for maritime: strip away the pirate framing and this is a document about a problem that has arrived in our sector without being announced. Somebody designing a maritime OT exercise in 2026 had to assume that some of his readers would not be human, and had to build the artefact so that a machine reading it would get a different answer than a person reading it. That technique is not exotic. It is the same technique as text hidden in a document, and it is available to whoever gets there first. The optimistic version is a CTF author protecting the integrity of a competition. The pessimistic version is a supplier's specification, a tender response or a survey report carrying instructions written for the model that will summarise it, and not for you.

What to do: Ask who or what actually reads the documents your decisions rest on. If any part of your intake is automated, whether that is summarising vendor documentation, triaging incident reports or screening tenders, then assume the document can be written for that reader. Test it once: put a line of white-on-white text into a PDF and push it through your own pipeline to see whether it comes out the other end. Ours does, on three of four extraction paths we measured, including the one most people default to. Then decide what the human is still required to look at with their own eyes.

Test your response: there is no scenario in our library about documents written for machine readers, because until recently nobody needed one. There is a library about the rest of it, free and playable in an hour. Tabletop exercises →

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.

No new signals this week that clear the bar. There is plenty of leak-site traffic, as there is every week, and almost none of it has a maritime or OT nexus that would survive being written down here. Saying so is more useful than filling the section.

Now settling the two we flagged last week. Both vanish.

So both come off the board. Neither was wrong to flag, and neither turned into anything we can stand behind, which is the outcome for most things at this stage. We tell you when that happens for the same reason we flagged them in the first place: a signal you never hear the end of is worse than no signal at all.

JVNVU#95422936, the Japanese advisory for this week's first story (JPCERT/CC and IPA, 25 August 2026)

Worth knowing about as a habit rather than for this one entry. A great deal of maritime equipment is Japanese, and when a vulnerability is coordinated through JPCERT the Japanese advisory often carries detail that the English-language version summarises away. This week is a clean example: CISA says the settings can be altered, JVN says the identification number can be altered. If your fleet runs Japanese bridge equipment, and most fleets do, jvn.jp is worth a bookmark next to the CISA feed.

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 →

"The Outlaw Ocean" by Ian Urbina — several years of reporting from the parts of the sea where identity is negotiable: vessels that change names between ports, flags bought by email, and ships that simply stop appearing on the picture when it suits them. It is a journalism book rather than a security book, and it will teach you more about why a transponder that can be told to misreport its identity matters than any advisory will.

Browse maritime cyber book recommendations →