n0n Maritime Extortion Claims: 38 Firms and a Suspected Vendor Link

On 12 October 2026 the extortion group n0n listed 38 port, shipping and logistics organisations in 18 countries on its leak site. Researchers assess that the data likely came from one maritime software vendor's support archive, not 38 intrusions. No listed organisation has confirmed a breach. If you are named, verify the source before you respond.

This post sets out what the group claims, what researchers have assessed, what the vendor has and has not said, and what every maritime operator can check this week, whether or not its name is on the list. The vendor link is an assessment by researchers, not an established fact. We do not name the 38 listed organisations; we describe them by sector and country, because their names come from a criminal leak site and none of them has confirmed anything.

What happened

n0n is a data theft extortion group that, according to a public leak site tracker, first appeared on 18 September 2026. Like several newer groups, it steals data, posts a victim to its leak site with a countdown, and demands payment in Bitcoin to keep the data unpublished.

On 12 October the group posted 38 maritime organisations in a single batch. A security vendor's report counted terminal and port operators, shipping lines, port IT and EDI system providers, agencies, depots and logistics firms, plus three companies in adjacent industries. Most listings shared one publication deadline, 19 October 2026 at 13:27 UTC, which researchers read as a sign the batch was processed together.

Two days later, a maritime security firm published an analysis assessing that the listed data likely traces back to a single support and project archive linked to CyberLogitec, a Seoul based maritime and logistics software company. The firm found that at least 21 of the 38 listed organisations are publicly documented CyberLogitec customers, and that seven of the 85 sample file names published by the group reference the vendor or its products. The firm describes this as an interim assessment and says it is unconfirmed.

CyberLogitec has not confirmed an incident. Speaking to the Korean trade outlet Daily Log on 13 October, a company official confirmed that the named Korean firms are its customers and said the company was still working to establish the facts. Daily Log reported that the vendor sent customers a notice urging caution against possible further damage, and that the named Korean companies were operating normally.

Timeline

What is still unknown

• Whether any intrusion happened at CyberLogitec or anywhere else. The vendor has not confirmed one and no listed organisation has confirmed a breach.
• How the data was obtained. Researchers have offered hypotheses; nobody has published evidence of an access vector for this batch.
• Whether n0n stole the data itself or bought it. The maritime security firm says it does not know.
• Whether the samples are authentic. The same firm says it found no signs of fake data but cannot validate the files.
• What was actually published after 19 October. Risky Bulletin reports leaks; we did not visit the leak site and have not verified the contents.

Who is listed

The table below groups the 38 listings the way a security vendor's report did on 13 October. It counts claims made by an extortion group, not confirmed victims.

The security vendor counted Hong Kong separately from China to arrive at 18. Safety4Sea quoted the maritime security firm as referring to 37 organisations on 14 October; the 38 figure is the one most sources use.

Several things about the list matter more than the names:

• Concentration. About a third of the listings are in one country, and many of those are terminals at a single port complex. That pattern is what prompted researchers to look for a shared supplier.
• Port IT providers are on it. Five listings are themselves providers of port IT, EDI or terminal systems. If the data came from a supplier, some of the listed organisations may sit between the supplier and other operators.
• Being listed does not mean being breached. The maritime security firm found that one listing reuses a sample file from another listing. That suggests at least some organisations were named on the strength of data about them held elsewhere.

What the group demanded

n0n posted a fixed USD amount per listing, payable in Bitcoin to a unique address for each victim. According to both research reports, each listing also offered a one time option to pay 10% of the demand to open a private negotiation room.

The figures conflict, and the reason is worth understanding before you quote any of them. The USD 2.4 million to 14 million range comes from listings one security vendor reviewed on 13 October, early in the posting window. The USD 1.22 billion total and the USD 400 million ceiling come from the maritime security firm's later capture across all 38 listings. On top of that, some Korean press figures appear to be the 10% negotiation fee, not the full demand: Boan News reported USD 10 million for the steelmaker, while the maritime security firm lists that firm's full demand at USD 100 million.

Demand size says little about the data. The security vendor noted that demands did not scale with volume: one listing asked USD 14 million for about 60 MB, another USD 2.4 million for about 2.4 GB. The maritime security firm makes the same point and adds that ransom amounts do not indicate how much data was exposed at each company.

The suspected vendor link

What the evidence is

The maritime security firm's case rests on three observations, all of which it describes as consistent with, not proof of, a single source:

1. Customer overlap. At least 21 of the 38 listed organisations, spanning 9 countries, are publicly documented CyberLogitec customers. Two more listings have file names that refer to the vendor or its products.
2. Product names in file names. Seven of the 85 sample file names include the vendor's name or a product name. The products referenced are OPUS Terminal (including OPUS Terminal M), ALLEGRO, OPUS Bulk, CARA and OPUS D&D.
3. The shape of the files. The samples look like support material: ticket keys, release notes, deployment lists, functional specifications, database patch scripts and EDI support requests. Many file names end in a five digit sequence, which the firm says is consistent with an export from a ticketing or mail system.

Independently, a security vendor reached a similar view by a different route. It found small, narrowly scoped data sets with the same EDI and configuration categories repeating across unrelated organisations, and it found no infostealer credential matches for many of the listed maritime organisations. It concluded that one shared application or data source was more likely than 38 separate intrusions, and compared the pattern to past mass exploitation campaigns against managed file transfer products. It also said it had found no evidence linking n0n to those earlier campaigns.

What CyberLogitec is

CyberLogitec's website lists software for container lines, bulk operators, terminals and logistics firms. The products named in the sample files map to these descriptions on the vendor's site:

Smart Maritime Network describes the company as serving more than 150 customers worldwide. When we loaded the vendor's site on 24 October, it showed a notice that the website was temporarily unavailable for a scheduled system upgrade, with sales contacts. It carried no security or incident notice. Risky Bulletin reported on 23 October that the site had been down for weeks; we do not draw any conclusion from a maintenance page.

What CyberLogitec has said

According to Daily Log:

• A company official confirmed that the named Korean companies are its customers.
• The official said the company was still establishing the exact situation and facts.
• The company sent customers a notice urging caution about possible further damage and leaks.
• It did not confirm an infection, a leak, or that its systems were the cause.

A Korean port industry official told Daily Log the notice was precautionary, since it was unclear whether any damage had occurred. Another named Korean group told the outlet it was still checking whether a leak happened and whether the vendor was involved, and that it was not aware of a ransom demand.

Why this matters even if you are not a customer

If the assessment holds, this is a fourth party exposure: the data of many operators, and some data about their trading partners, held in one supplier's support environment. That pattern is not specific to this vendor. Terminal operating systems, liner systems, port community systems and EDI hubs all sit between many organisations, and their support teams routinely receive logs, configuration, database extracts and sample messages to diagnose problems. The rest of this post treats the vendor link as a working hypothesis and focuses on what that hypothesis means for anyone in a similar position.

Technical details

This incident has no CVE, no vendor advisory and no published indicators of compromise for the intrusion itself. Neither research report lists IP addresses, domains, file hashes, malware names or user agents. We checked both research reports, the vendor's site, the Korean coverage and the trade press listed in Sources. What follows is every concrete, defender useful detail we could verify, with where it came from.

Data categories described in the samples

All of this is alleged. The maritime security firm says it cannot validate authenticity or confirm scope.

Two details stand out for defenders. First, credential lists from 2018 to 2022 are only harmless if every one of those passwords has since been changed; support and integration accounts are the ones most likely to have been left alone. Second, implementation material such as interface specifications and patch scripts tells an attacker which versions and table structures you run, which is useful reconnaissance whether or not any password still works.

Claimed sample sizes

A security vendor listed these volumes for six listings. We give the country and sector instead of the name.

The group published 85 sample file names across the 38 listings, two or three per listing, according to the maritime security firm.

The EDI messages involved

Ports and carriers exchange operational data as UN/EDIFACT messages, with implementation guides for the container trade maintained by SMDG, an association of carriers and terminals. The research reports mention these message types:

The security vendor pointed out that the interchange headers in any published EDI file (the UNB segment, which names sender and recipient identifiers and a timestamp) could help identify the source system. That is also the fastest way to tell whether a file published under your name actually came from your environment.

Leak site mechanics

We have chosen not to reproduce the leak site address or any Bitcoin addresses. They do not help you detect an intrusion, and the address leads to allegedly stolen data.

Techniques attributed to n0n

A public leak site tracker maps n0n to the following MITRE ATT&CK techniques. These describe the group's activity in general, not this maritime batch, for which no access vector has been published.

Researchers cited by the maritime security firm say n0n's usual entry point is credentials stolen by infostealer malware. The security vendor that examined the maritime batch found no stealer log matches for many listed organisations, which is part of why it suspects a shared source this time.

Attribution

There is none that we can confirm. The security vendor's group profile lists n0n as likely Russia based. The maritime security firm says it has not seen evidence for that and does not attribute the group to any country. Treat attribution as unknown; it does not change any of the defensive steps below.

If your organisation is named

The most useful advice in both research reports is the simplest: being named is not the same as being breached. A listing under your name may contain data you sent to a supplier, data a partner holds about you, or nothing of yours at all.

1. Do not pay or engage before you know the source. The maritime security firm recommends establishing where the data came from before responding to any demand. Bring in counsel and your insurer first; most policies have conditions on how you engage.
2. Get the sample file names and look at them closely. Do they reference your systems, your vendor's ticket numbers, or another company's? A five digit suffix pattern points towards a ticketing export.
3. Check EDI headers. If any EDI sample is published, the UNB segment names the sender and recipient. Compare those identifiers with your own partner IDs.
4. Search your own logs for the period researchers flagged. The maritime security firm recommends reviewing vendor account activity from July 2026 onward.
5. Ask your suppliers in writing. Ask every software and service provider that holds support data from you whether they are investigating an incident, and what of yours they hold.
6. Prepare communications. Customers, carriers and regulators may hear about the listing before you have answers. A short holding statement that says you are investigating, and that being listed does not by itself mean your systems were accessed, is accurate and defensible.
7. Assess notification duties on the facts, not the listing. Data protection and sector reporting rules usually turn on whether you know or reasonably suspect a breach of data you control. Your counsel should decide.

What every maritime operator should do this week

Both research reports recommend checks that apply whether or not you are named. Here they are as a working checklist with commands. Adjust names and paths to your environment.

1. Inventory every vendor account

List every account a supplier uses to reach your systems: VPN users, RDP accounts, jump host logins, service desk portal accounts, SFTP and AS2 partners, and integration service accounts inside your terminal or liner system.

On Windows domains, find accounts that look like vendor or service accounts and when their passwords last changed:

Get-ADUser -Filter * -Properties PasswordLastSet, LastLogonDate, Description |
  Where-Object { $_.SamAccountName -match 'vendor|svc|support|clt|ext' -or $_.Description -match 'vendor|support' } |
  Select-Object SamAccountName, Enabled, PasswordLastSet, LastLogonDate, Description |
  Sort-Object PasswordLastSet

Find enabled accounts whose passwords have not changed in two years:

$cutoff = (Get-Date).AddYears(-2)
Get-ADUser -Filter {Enabled -eq $true} -Properties PasswordLastSet |
  Where-Object { $_.PasswordLastSet -lt $cutoff } |
  Select-Object SamAccountName, PasswordLastSet

On Linux hosts that vendors reach over SSH or SFTP:

# Accounts with a login shell
awk -F: '$7 !~ /(nologin|false)$/ {print $1, $6, $7}' /etc/passwd
# Last password change per account
for u in $(awk -F: '$7 !~ /(nologin|false)$/ {print $1}' /etc/passwd); do
  echo "$u: $(chage -l "$u" | grep 'Last password change')"
done
# Authorized SSH keys, which outlive password rotations
find / -name authorized_keys -path '*/.ssh/*' 2>/dev/null -exec ls -l {} \;

Inside your terminal operating system or liner system, export the application user list and flag every account used by the vendor's support or implementation team. Application accounts are easy to forget because they are not in the directory.

2. Rotate shared and long lived credentials first

The maritime security firm specifically calls out shared service desk logins and credentials unchanged for years. Rotate in this order: shared vendor accounts, integration and service accounts that hold write access to operational data, SFTP, AS2 and VAN credentials, then individual vendor accounts. Where an integration cannot tolerate a password change without downtime, schedule it, and in the meantime restrict where the account can log in from.

3. Review remote access since July 2026

On Windows servers, list successful remote interactive logons:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime='2026-07-01'} |
  Where-Object { $_.Properties[8].Value -eq 10 } |
  Select-Object TimeCreated,
    @{n='User';e={$_.Properties[5].Value}},
    @{n='SourceIP';e={$_.Properties[18].Value}}

Remote Desktop authentication events are also recorded in the RemoteConnectionManager log:

Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational' |
  Where-Object { $_.Id -eq 1149 -and $_.TimeCreated -gt [datetime]'2026-07-01' } |
  Select-Object TimeCreated, Message

On Linux, review SSH and SFTP logins for vendor accounts:

# Debian and Ubuntu
grep -E 'Accepted (password|publickey)' /var/log/auth.log* | grep -Ei 'vendor|support|svc'
# RHEL family
journalctl -u sshd --since 2026-07-01 | grep 'Accepted'
# Logins per account, most recent first
last -F | head -50

Look for logons at unusual hours, from new source addresses, or from accounts that should be dormant.

4. Look for bulk downloads from file transfer and EDI systems

The security vendor recommends checking internet facing EDI, file transfer and terminal components for unexpected bulk downloads. For an OpenSSH based SFTP server with logging enabled (Subsystem sftp internal-sftp -l INFO), count file reads per user:

# Which account each sftp process belonged to
grep 'session opened for local user' /var/log/auth.log*
# File reads per sftp process ID, busiest first
grep 'flags READ' /var/log/auth.log* | grep -o 'internal-sftp\[[0-9]*\]' | sort | uniq -c | sort -rn | head -20

On web based EDI portals and support portals, pull access logs and count large responses per account and per day. A sudden spike of downloads by one account is the signal to chase.

5. Audit what you have sent to vendors

This is the step most teams skip. Search your outgoing mail and ticket history for attachments sent to software suppliers' support desks: database exports, configuration files, network diagrams, credential lists, EDI samples and log bundles. Ask each supplier to delete what it no longer needs, and to tell you what it keeps and for how long. If you find credentials in old tickets, rotate them now.

If you use Microsoft 365, a content search scoped to mail sent to a supplier's domain with attachments is a quick start. Many ticketing systems also allow export of all tickets raised with a given supplier.

6. Warn staff about targeted phishing

The maritime security firm warns that real ticket numbers, engineer names, EDI samples and invoice templates make convincing lures, even for organisations not on the list. Brief operations, IT and finance staff now. Specific red flags: a "support engineer" asking for remote access or a password reset; an invoice with changed bank details that cites a real charter party or disbursement account; an EDI partner asking to change endpoints.

7. Enforce MFA on every vendor path

Require MFA on vendor portals, VPN, RDP gateways and service desk access. Remove RDP exposed to the internet. Where a vendor tool cannot do MFA, put it behind a gateway that can.

8. Watch IT and OT for misuse of leaked configuration

If configuration, interface specifications or credentials for your terminal system are in the leaked data, assume they have been read. Monitor for logons that use known integration accounts from new sources, and for configuration changes outside change windows. Network monitoring on the boundary between business IT and operational technology is worth more this month than usual.

How this differs from a single company breach

What changed since the first reports

• Victim count overall. Boan News counted 52 n0n victims on 13 October. Risky Bulletin said more than 140 on 23 October. The public tracker showed 151 on 24 October, with the 38 maritime listings the largest single day.
• From anonymous to named. On 13 October n0n replaced several anonymous listings with real names, according to the maritime security firm.
• From many intrusions to one source. Early coverage asked whether 38 separate intrusions had happened. By 15 October two research teams had independently argued for a shared source, and one named a likely vendor.
• Demand figures grew. Early coverage quoted USD 2.4 million to 14 million; later analysis across all listings put the total at about USD 1.22 billion.
• After the deadline. Risky Bulletin reports that most listed organisations refused to pay and their data was published. We have not verified what was published.
• What has not changed. No listed organisation has confirmed a breach, and CyberLogitec has not confirmed an incident.

Open questions

• Did an intrusion happen at the vendor, at one of its support systems, at a hosted service it uses, or somewhere else entirely?
• Is the data current enough to matter operationally, or mostly historical?
• Which credentials in the alleged account lists are still valid?
• How much of the EDI data names carriers and shippers that are not on the list?
• Will regulators in the most affected countries publish guidance? Boan News reported that Korea's KISA was notifying affected Korean firms; we did not find a public KISA statement.
• Will the vendor publish findings, and will they include indicators that customers can search for?

What would have helped

None of this is a judgement about CyberLogitec or any listed organisation. The facts are not established, and several things in the response so far, such as a vendor notifying customers early and operators checking their own systems, are exactly what should happen. What follows is what any operator that relies on specialised operational software can put in place so a supplier side exposure is smaller and easier to scope.

Practices any team can use

• Keep a register of what each supplier holds. Not just who your suppliers are, but which accounts they have, what data you have sent them, and where it lives. You cannot answer "what of ours is in that archive" without it.
• Minimise what goes into support tickets. Mask passwords, strip personal data and use synthetic EDI samples where you can. Ask suppliers to purge attachments after a ticket closes.
• Separate vendor access per person. Shared service desk logins make it impossible to tell who did what, and they rarely get rotated. Named accounts with MFA are the baseline.
• Time box vendor access. Enable remote access accounts for a specific job and disable them afterwards.
• Rotate integration credentials on a schedule. SFTP, AS2, VAN and API credentials age quietly. Put a rotation date on each one.
• Write breach notification into contracts. The maritime security firm recommends it. Specify how fast the supplier must tell you, what it must tell you, and that it must tell you about suspected incidents, not only confirmed ones.
• Know which supplier software runs where. An inventory of the components inside your operational systems, including their versions and who supports them, turns "are we affected" from a week into an hour.
• Map to the rules you already have. In the US, the Coast Guard's maritime cybersecurity rule requires reporting incidents to the National Response Center; IMO's Resolution MSC.428(98) expects cyber risks in safety management systems. Supplier access is part of both. See our posts on the Coast Guard maritime cyber rule and vessel OT cybersecurity under the ISM Code.

Zero-Day Discovery and Gold

Two Safeguard capabilities touch the component side of this problem, with clear limits.

Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. It runs in two modes, an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. It does not test proprietary terminal or liner software, a supplier's support environment or anyone's credentials, and no software flaw has been linked to this incident.

Gold Open Source at gold.safeguard.sh is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh is a paid service with hardened drop in components and container images held to zero exploitable critical or high CVEs, built to SLSA L3 or higher, Sigstore signed, with evidence pages; an artifact loses its badge if it regresses. There is no CVE for this incident to look up in Gold.

The habit both support still applies: pull patched, signed open source components from a curated source, and rebuild quickly when a fix lands. If the hypothesis of a shared exposed application turns out to be right, the speed at which every customer of that application can find and patch it is what decides how bad the next one gets.

Where Safeguard fits

Safeguard helps with the supplier and component side of this kind of incident:

• Third-Party Risk Manager lets you onboard vendors, request SBOMs, projects or products from them, score and continuously monitor supplier risk, and apply policies and gates. The compliance suite's Vendors, Risks and Questionnaires tabs hold the supplier register and the evidence. This is where "which suppliers hold what" belongs.
• SBOM and dependency scanning of repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image <name>, safeguard scan --sbom <file>, with JSON results under ./output), plus a platform view of which projects contain a given component and version. If a supplier gives you an SBOM for the software it runs in your terminal, you can see the open source inside it and match it against vulnerability databases.
• Reachability analysis, policies and gates to rank findings and stop known vulnerable components from shipping, and autonomous remediation that opens fix pull requests (off by default).
• The Safeguard CLI's assistant, which edits code and runs commands with your approval under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict; safeguard exec runs it in CI. Desktop and phone apps can send work to a computer running the CLI and approve each command.

Where it does not help: Safeguard does not detect an intrusion at a supplier, monitor leak sites, scan for exposed credentials, rotate passwords, enforce MFA on a vendor's VPN or tell you what a supplier holds in its ticketing system. It cannot patch proprietary vendor software; that fix has to come from the vendor. Because the cause of this incident is unknown, we do not claim Safeguard would have prevented it.

Common mistakes and troubleshooting

• Treating a listing as a confirmed breach. Write "listed by n0n" or "named on the leak site", never "breached", until the organisation or a regulator confirms.
• Treating the vendor link as fact. It is an assessment by researchers, based on customer overlap and file names. The vendor has not confirmed an incident.
• Quoting the wrong demand figure. Check whether a number is the full demand or the 10% negotiation fee, and which date the capture is from.
• Rotating only individual passwords. Shared vendor logins, integration accounts, SSH keys and SFTP credentials are where old secrets survive.
• Checking only the directory. Terminal and liner systems keep their own application user tables. Export and review them separately.
• Ignoring the partners in your EDI. If your EDI traffic is in the data, so are your trading partners' identifiers and bookings. Tell them before they read about it.
• Waiting for the vendor before doing anything. Credential rotation, log review and staff warnings do not depend on the vendor's findings.
• Visiting the leak site. It exposes your staff to allegedly stolen data and possibly to legal issues. Use your counsel or an incident response provider if you need to see what was posted.

FAQ

What is n0n?

A data theft extortion group that first appeared in mid September 2026, according to a public leak site tracker. It posts victims on a leak site and demands Bitcoin to keep data unpublished. One security vendor describes it as focused on data theft rather than encryption, though its technique profile includes encryption and recovery inhibition.

How many maritime organisations were listed, and where?

38 organisations in 18 countries and territories on 12 October 2026: 12 in South Korea, 4 each in Brazil and Indonesia, 2 each in Singapore, China and Japan, and 1 each in 12 others. They include terminals and port operators, shipping lines, port IT providers, logistics firms and three adjacent industry companies.

Were these companies breached?

None has confirmed a breach. A Korean steelmaker on the list called it the group's one-sided claim. Researchers stress that a listing may contain data held by a supplier or partner, not taken from the organisation's own network.

Is CyberLogitec the source?

That is an assessment by a maritime security firm, not an established fact. It is based on at least 21 of 38 listed organisations being documented customers and seven sample file names referencing the vendor or its products. CyberLogitec has confirmed the Korean firms are customers and said it is still establishing the facts.

What data is involved?

Allegedly user account lists with passwords and staff contact details (examples from 2018 to 2022), EDI messages such as stowage plans and gate moves, system documentation and patch scripts, and commercial records such as tariffs and invoices. File dates span 2009 to August 2026. None of it has been independently verified.

How much did n0n demand?

About USD 1.22 billion in total across the 38 listings, from USD 400,000 to USD 400 million each, per the maritime security firm. Earlier figures of USD 2.4 million to 14 million came from listings reviewed on 13 October, and some press figures are the 10% negotiation fee.

Were there any indicators of compromise?

No intrusion indicators have been published by any source we found. Attribution is also unconfirmed.

We use maritime software from a vendor that was not mentioned. Should we act?

Yes. The checks in this post apply to any supplier that holds your support data or has remote access: inventory accounts, rotate shared credentials, review access logs, audit what you have sent and warn staff about phishing.

Does this trigger US Coast Guard reporting?

The Coast Guard rule requires reporting incidents to the National Response Center. Whether a listing on a leak site, without evidence of access to your systems, is reportable is a question for your counsel and your Coast Guard contact. See our Coast Guard rule post.

Would Safeguard have prevented this?

We do not claim that. The cause is unknown, and Safeguard does not detect intrusions at suppliers or monitor leak sites. It helps you keep a supplier register, request SBOMs from vendors and find known vulnerable components in software you build or receive.

Fix it without waiting for upstream

If the shared application hypothesis proves right, the fix for the vendor's own code has to come from the vendor. What you control is everything open source in the software you build and run around it, from integration services to EDI gateways.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows n0n, CyberLogitec or any maritime system. Each is a real Safeguard session, and each intro says how the same flow applies to an operator scoping its supplier exposure.

This demo sets up the Safeguard runner on your own machine, approves it with a device code and then scans from the terminal. For a port or terminal operator, that means you could run scans inside a segmented operations network, for example against the integration services and EDI gateway images that sit beside your terminal system, without sending source code out of that network.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, a security lead could ask in plain language which projects contain a given component and version, or list the vulnerabilities in the software a supplier gave you an SBOM for, while keeping Claude limited to read only tools.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. For an operator, you would pick the repository of an in house EDI integration service, ask for its vulnerable dependencies to be upgraded, and approve each command yourself before anything changes.

Click through it at your own pace, or open it full screen.

To try it on your own services, download Safeguard and follow the CLI docs. For a broader view of supplier side incidents, read the IDCF Cloud ransomware and third party risk lessons, finding affected products fast with SBOMs and October 2026 security incidents and what would have helped.

Quick check

Sources

• Maritime security firm: n0n cyber extortion incident involving 38 maritime companies likely traces back to a single vendor (15 Oct 2026)
• Security vendor report: n0n group global ports and shipping leak (13 Oct 2026)
• Daily Log: CyberLogitec response (13 Oct 2026, edited 22 Oct, Korean)
• Boan News: n0n lists Korean port and shipping firms (13 Oct 2026, Korean)
• NGET News: Korean steelmaker says no damage confirmed (13 Oct 2026, Korean)
• Public leak site tracker: n0n group profile (accessed 24 Oct 2026)
• CyberLogitec website (accessed 24 Oct 2026)
• Risky Bulletin (23 Oct 2026)
• Smart Maritime Network: cyber group lists 38 maritime organisations with USD 1.22bn in ransom demands (20 Oct 2026)
• Waterways Journal: cyber extortion group targets 38 maritime organizations (23 Oct 2026)
• Safety4Sea: cyber extortion group targets 38 maritime organizations (14 Oct 2026)
• Maritime Executive: massive cyber attack threatens release of data from 38 maritime companies (14 Oct 2026)
• The Loadstar: cyber crime group hits 38 shipping and port groups with data leak threat (14 Oct 2026)
• SMDG: EDIFACT message implementation guides and recommendations
• IMO: Maritime cyber risk management

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.