&ST HD Cyberattack: 2.5M Customer Records May Have Leaked

&ST HD, the apparel group formerly called Adastria, says outsiders logged in to several business servers on 22 October 2026 and pulled data out over about two and a half hours. By the company's own estimate, about 2.5 million customer records and about 10,000 business partner records may have leaked. Payment card data and customer passwords were not included.

&ST HD (アンドエスティHD) owns brands including GLOBAL WORK, according to Kyodo. This post walks through what the company has actually published, minute by minute, what data is in scope, and what any team running loyalty programs, partner portals or internal business servers can do this week. The access vector has not been disclosed, so we do not guess at it. Where the facts stop, we say so.

The short version

• When: From about 07:30 JST on Thursday 22 October 2026, an outside party carried out login attempts, intrusion and data extraction against multiple company servers "in sequence", according to the company notice.
• Detection: About 10:00 JST the same morning the company detected the unauthorised activity and isolated the affected servers.
• Containment: By 17:00 JST the company had blocked the intrusion route, stopped internal business systems and confirmed the route could no longer be used.
• Disclosure: On 23 October the company consulted police, reported to Japan's Personal Information Protection Commission (PPC) and posted a notice on its site and on TDnet at 17:00 JST.
• Data that may have leaked: about 2.5 million customer records (name, date of birth, gender, address, phone, email, member ID) and about 10,000 partner records (company name, ordering and return addresses, contact name, phone, email). Employee data scope is still being checked.
• Not included, per the company: payment information such as card data, and passwords customers set themselves.
• Customer impact: stores and the web store stay open, but member points cannot be used in stores or online.
• Misuse: none confirmed so far, according to Kyodo's report of the announcement.

Every count in this post is the company's "may have leaked" (流出した可能性) estimate as of 23 October. It is not a confirmed exfiltration count and it is not a count of unique people.

What happened

The company's notice, titled in Japanese as an apology and notice about unauthorised access to business servers and the possible leak of personal information, is short and specific. It went up on the corporate news page and was filed as a timely disclosure on TDnet, the Tokyo Stock Exchange disclosure system, under securities code 2685.

In our own words, the notice says this. Early on the morning of Thursday 22 October, someone from outside made login attempts against several of the company's servers one after another, got in, and extracted data. Around 10:00 the company spotted the unauthorised operations and pulled those servers off the network. To stop the damage spreading, it then cut the access route and shut down internal business systems by 17:00, and checked afterwards that the route could no longer be used. The next day it went to the police and reported to the PPC.

The notice also says the company has finished its emergency measures and has identified and dealt with the means of access. It does not say what that means was. It will contact affected customers and partners in turn and set up an enquiry desk.

Minute-level timeline

All times are Japan Standard Time (UTC+9).

Two windows stand out. From first activity to detection was about two and a half hours. From detection to a confirmed block of the route was about seven hours. During the second window the company was isolating servers, so it would be wrong to read seven hours as seven hours of open access. The notice does not say how much data left during each window.

What the company has not said

The notice leaves several things open, and none of the reporting we read fills them in:

• How the attacker got in. The company says it has identified the method. It has not published it. "Login attempts" tells you that authentication was part of the sequence. It does not tell you whether the first foothold was a stolen credential, a guessed password, a remote access device, a vulnerable application or something else.
• Which servers. The notice says "business servers" (業務サーバー) and "multiple servers". It does not name systems, operating systems, or whether they were on premises or in a cloud.
• Whether ransomware was involved. The notice describes login, intrusion and extraction. It does not mention encryption or a ransom demand. No group has publicly claimed it in anything we read.
• Why points are unavailable. The company says the web store was not affected by the intrusion, yet points cannot be used in stores or online. The likely link is the shutdown of internal business systems, but the notice does not spell that out, so treat it as unexplained.
• Employee data. The scope is "being confirmed".

If you are writing internal guidance for your own organisation off the back of this, keep these as open questions and do not fill them with assumptions.

Who is affected

A few notes on reading this table.

The company counts in 件, which means records or items. One person can appear more than once, and the customer and partner counts are different categories. A Japanese security news site that covered the notice makes the same point: the figures cannot be added together or read as a count of distinct people.

"May have leaked" is the company's language. The company has not said it confirmed the data in the hands of a third party, and Kyodo reports that no misuse has been confirmed.

The group's membership base is large. A March 2026 trade press article described the and ST membership as 21.2 million members, but that is a different and older figure, not the breach scope. We mention it only so readers do not confuse the two.

This is a separate event from 2023

&ST HD, then trading as Adastria, disclosed a different server intrusion in January 2023. Its filings at the time said that on the early morning of 18 January 2023 a third party accessed some internal business system servers, the company cut the network and stopped internal systems, and the web store was paused because the logistics system was stopped. The second report on 24 January 2023 put the customer records that might have leaked at 1,044,175. The follow-up report on 31 March 2023 listed further categories after a forensic investigation, including 221,272 older customer service records, 94,435 employee records, applicant records and 6,346 partner records, and said no leak had been confirmed.

The 2026 notice does not connect the two events, and we do not either. Different date, different investigation, no stated common cause. The only reason to mention 2023 is that it shows how this group's disclosures have tended to work: an initial notice, then follow-up reports as forensic work finishes. Expect the 2026 numbers to change.

How an intrusion like this works, in plain language

We do not know this attacker's method, so this section describes the general shape of what the company did disclose: login attempts, intrusion and extraction across multiple servers, one after another. That is a pattern defenders see often, and it maps cleanly onto public frameworks.

1. Getting a foothold. Someone gets a first set of working credentials or a first point of code execution. MITRE ATT&CK files the credential route under Valid Accounts (T1078) and Brute Force (T1110), which includes password guessing, password spraying and credential stuffing as sub-techniques.
2. Moving sideways. With one account working, the intruder tries it, or credentials found on the first host, against other servers. ATT&CK calls this Remote Services (T1021). In logs this often looks like a burst of authentication attempts from one internal or external address against many hosts.
3. Finding the data. Business servers that feed loyalty programs, customer service and partner ordering tend to hold exactly the fields &ST HD listed: names, addresses, phone numbers, emails and member IDs.
4. Taking it out. ATT&CK's Exfiltration tactic (TA0010) covers the ways data is moved off a network. Large outbound transfers from servers that normally do not talk to the internet are the classic sign.

The word "sequentially" (順次) in the notice matters for defenders. It suggests that each server was a separate step, and each step was a chance to notice. That is good news for detection engineering: you do not need to catch the first login, you need to catch the second, third or fourth.

Why loyalty data is a high-value store

Loyalty and points systems sit in an awkward spot. They hold rich identity data (name, birth date, address, phone, email) for a very large share of a retailer's customers, and they connect to stores, the web store, apps and often partner point programs. According to a March 2026 Payment Navi article, the company's own and ST points have been joined by NTT Docomo's d Points (since 2018) and Rakuten Points (since September 2025), alongside a co-branded credit card and a bank branch. That makes the points platform a business system that many other things depend on. When it is taken offline as a precaution, customers notice immediately, as they did here.

The data also has value without card numbers. Name, birth date, address and phone are what a fraudster needs to sound convincing on the phone, to answer knowledge-based checks at other companies, or to write a believable "your points have been restored, click here" message.

Why partner data is a supply chain problem

The 10,000 partner records include company names, ordering and return addresses, contact names, phone numbers and emails. For a fashion group, partners include manufacturers, logistics providers and suppliers. That data is exactly what someone needs to impersonate the retailer to a supplier, or a supplier to the retailer: change of bank account requests, fake return instructions, invoices that look routine. If you are one of those partners, the risk to you is not your systems being breached. It is your accounts payable team receiving a convincing email.

Technical details

This incident has no CVE, no vendor advisory and no published indicators of compromise. The company has not released IP addresses, domains, file hashes, malware names or a description of the access method. We checked the corporate notice, the TDnet filing and the news coverage listed in Sources. What follows is every concrete, defender-useful detail we could verify, with where it came from.

Disclosure records

Attack sequence as disclosed

Data fields

Regulatory clock in Japan

The PPC's guidance on leak handling sets the timing this disclosure fits into. A business must report when a leak or possible leak involves more than 1,000 people, involves sensitive data, could cause financial harm, or may have been caused by someone acting with an unlawful purpose. The preliminary report (速報) is expected within about three to five days of discovery. The final report (確報) is due within 30 days, or 60 days where the leak may have been caused by an unlawful act. An external intrusion falls into the 60 day case. Discovery here was 22 October, so a final report to the PPC would be due by about 21 December 2026. That is a regulatory deadline, not a promise of a public update, but in 2023 this group published its third report shortly after filing its final report with the PPC.

What changed since first reports

Very little, which is itself informative. As of 24 October there is one company notice. Jiji and Kyodo both reported the same facts as the notice: about 2.5 million customer records, about 10,000 partner records, employee data under review, no payment data. Kyodo adds that misuse has not been confirmed. Neither outlet reported a claimed attacker, a ransom note or an access vector.

The one wording difference we noticed is on TDnet itself: the daily list titles the filing with 漏えい ("leak"), while the PDF and the corporate page use 流出 ("outflow"). Both are "possible" in context. It is not a change in substance.

We could not load the web store's own 22 October maintenance notice, which a Japanese security news site lists among its sources. If that page adds anything about points or member services, it is not reflected here.

What to do now

The steps below are for three audiences: the &ST HD customers and partners who received or will receive a notice, security teams at other retailers who want to check they are not one step behind, and anyone who runs servers that hold customer or supplier data.

If you are a customer or partner

1. Treat unexpected messages about points with suspicion. Points are temporarily unavailable, which is an easy hook for phishing. Do not click links in messages about "restoring" or "transferring" points. Go to the official site or app directly.
2. Do not give extra information. The company says passwords and card data were not included. Any message asking you to "re-enter" a card number or password to verify your membership should be treated as fraud.
3. Expect convincing phone calls. A caller who knows your name, address and birth date is not proof that they are the company.
4. Partners: lock down payment change requests. Any request to change bank details, return addresses or pickup arrangements should be confirmed through a phone number you already have on file, not the one in the email.
5. Use the official enquiry form. The notice points customers to the support form on the dot-st support site.

If you run Windows servers: look for sequential logons

Windows records failed logons as event 4625 and successful logons as event 4624. Microsoft's auditing documentation flags status 0xC000006A (bad password) for critical or service accounts and 0xC0000064 (unknown user name) as worth watching, especially several in a row. Logon type 3 is a network logon and type 10 is a remote interactive (RDP) logon.

Pull the last week of failures and see which source addresses hit more than a handful of hosts:

# Failed logons in the last 7 days, grouped by source IP and target account
$since = (Get-Date).AddDays(-7)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=$since} |
  ForEach-Object {
    $x = [xml]$_.ToXml()
    [pscustomobject]@{
      Time      = $_.TimeCreated
      Account   = ($x.Event.EventData.Data | Where-Object Name -eq 'TargetUserName').'#text'
      SourceIP  = ($x.Event.EventData.Data | Where-Object Name -eq 'IpAddress').'#text'
      LogonType = ($x.Event.EventData.Data | Where-Object Name -eq 'LogonType').'#text'
      Status    = ($x.Event.EventData.Data | Where-Object Name -eq 'Status').'#text'
    }
  } | Group-Object SourceIP, Account | Sort-Object Count -Descending | Select-Object -First 25

Then look for the pattern ATT&CK's brute force detection guidance describes: many failures followed by a success from the same address or for the same account.

# Successful network and RDP logons in the same window
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=$since} |
  ForEach-Object {
    $x = [xml]$_.ToXml()
    $lt = ($x.Event.EventData.Data | Where-Object Name -eq 'LogonType').'#text'
    if ($lt -in '3','10') {
      [pscustomobject]@{
        Time     = $_.TimeCreated
        Account  = ($x.Event.EventData.Data | Where-Object Name -eq 'TargetUserName').'#text'
        SourceIP = ($x.Event.EventData.Data | Where-Object Name -eq 'IpAddress').'#text'
        Type     = $lt
      }
    }
  } | Sort-Object Time

Run this on each server, or better, query the same events centrally if you forward Security logs. The question you are asking is simple: did one account or one address log in to several servers in a short window, at an hour when nobody normally does?

If you run Linux servers: the same question over SSH

# Failed SSH logins, last 7 days, counted by source address
journalctl -u ssh -u sshd --since "7 days ago" --no-pager \
  | grep -E "Failed password|Invalid user" \
  | grep -oE "from [0-9a-fA-F:.]+" | sort | uniq -c | sort -rn | head -25

# Successful logins with full timestamps and source
last -F -i | head -50

# Failed attempts recorded in btmp (needs root)
sudo lastb -F -i | head -50

# Accepted logins, to line up against the failures above
journalctl -u ssh -u sshd --since "7 days ago" --no-pager | grep "Accepted"

On distributions that log to files rather than the journal, the same lines live in /var/log/auth.log (Debian and Ubuntu) or /var/log/secure (RHEL family).

Check for one account touching many hosts

Whatever your log platform, build one query: for each account, count distinct destination hosts it authenticated to per hour. Service accounts that normally touch two hosts and suddenly touch twelve are the signal. If you only have raw exports, a quick pass works:

# Input: CSV of time,account,src_ip,dest_host exported from your log store
awk -F, '{ split($1,t,":"); key=t[1]","$2; hosts[key][$4]=1 }
END { for (k in hosts) { n=0; for (h in hosts[k]) n++; if (n>=5) print n, k } }' logons.csv | sort -rn | head

(The script needs GNU awk for arrays of arrays.)

Look for data leaving servers that should be quiet

Exfiltration often shows up as outbound volume from hosts that normally only talk inside the network. If you have flow logs, sort servers by bytes sent to external addresses over the last week and read the top of that list by hand. On a single Linux host you can at least see what is connected right now:

# Established outbound TCP connections with owning process
sudo ss -tnp state established | awk 'NR==1 || $4 !~ /^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.)/'

And on Windows:

Get-NetTCPConnection -State Established |
  Where-Object { $_.RemoteAddress -notmatch '^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.|127\.|::1)' } |
  Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess |
  Sort-Object RemoteAddress

These are point-in-time checks, not a replacement for flow logging. If you find you cannot answer "how much data did this server send to the internet yesterday", that gap is the finding.

Harden the paths the notice points at

1. Inventory every way into your business servers. Remote desktop gateways, VPNs, SSH bastions, management consoles, file transfer services. You cannot protect logins you do not know exist.
2. Put phishing-resistant MFA in front of remote access and admin accounts. NIST SP 800-63B rev 4 requires that verifiers offer at least one phishing-resistant option at AAL2 and requires it at AAL3. It also notes that one-time codes and push approvals are not phishing-resistant. CISA's fact sheet on phishing-resistant MFA covers FIDO2 and PKI options.
3. Rate limit and lock out. SP 800-63B sets 100 consecutive failed attempts as an upper bound before an authenticator is disabled and allows lower limits. For server and admin logins, much lower is sensible.
4. Separate service accounts. An account used by a batch job should not be able to log in interactively, and should not exist on hosts it does not need.
5. Rotate credentials after any suspected intrusion. In its 2023 report, this group listed resetting accounts, reviewing account management policy and strengthening internal network communication among its fixes. Those are sensible defaults for anyone.
6. Write down your isolation playbook. The company isolated servers about two and a half hours after first activity and stopped business systems by 17:00. Decide in advance which systems you will cut, who can make the call, and what customer-facing features (such as points) will go down as a result.
7. Prepare the PPC report template now. If you operate in Japan, the three to five day preliminary report window is short. Have the four reporting triggers, the data inventory and the contact list ready before you need them.

What would have helped

This section is about any organisation that runs similar systems. It is not a judgement on &ST HD, whose notice describes detection, isolation and containment on the same day.

Practices that shrink the window

Know where identity data lives. Before you can protect 2.5 million customer records, you need a list of every system that holds them: the points platform, CRM, customer service tools, data warehouse, marketing exports, test copies. Data that exists in five places has five chances to leak. A data inventory also makes the PPC report and customer notices much faster.

Treat partner data as sensitive data. Supplier contact and address data rarely gets the same protection as customer data. It should, because it drives payment and logistics fraud.

Alert on the second login, not just the first. A sequential intrusion gives you several chances. Correlate authentication events across servers so that one account authenticating to many hosts, or many failures followed by a success, raises an alert. This is the detection ATT&CK lists for brute force: failed logons followed by a success, and attempts across a user pool in short intervals.

Make the quiet servers loud. Internal business servers that hold customer data should rarely, if ever, send large volumes to the internet. Default deny egress for those hosts, with explicit allow lists, turns exfiltration from a quiet copy into a blocked connection and an alert.

Strong authentication on every remote path. Phishing-resistant MFA on remote access, admin consoles and jump hosts. No shared admin accounts. Service accounts that cannot log in interactively.

Patch the edge, and know what is on it. We do not know whether a vulnerable internet-facing system was involved here. In general, though, remote access appliances and internet-facing applications are where many sequential intrusions start, so keeping an accurate list of what you expose and what versions it runs is basic hygiene. Our October edge device zero-days roundup covers several examples from this month.

Plan for collateral outages. Stopping internal business systems is the right call in many intrusions, but it can take customer features with it. Knowing in advance which features depend on which back-end systems lets you tell customers clearly what is down and why.

Rehearse the disclosure. A clear, specific first notice, like the one here with times and data fields, helps customers protect themselves. Rehearse writing one.

Where Safeguard fits

Safeguard is a software supply chain security platform. Be clear about what that does and does not cover for an intrusion like this.

What Safeguard does not do here. It does not watch logins, correlate authentication events across servers, block lateral movement, or detect data leaving your network. It is not a SIEM, an EDR or a data loss prevention tool. If the access method in this case turns out to be a stolen or guessed credential, Safeguard would not have seen it. We also do not know the access method, so we cannot say Safeguard would have prevented anything.

What Safeguard does do that is relevant. Many sequential intrusions start with, or are helped by, known vulnerable software on servers and in the applications teams build: an outdated web framework, an unpatched library in a customer portal, an old base image behind a partner ordering system. That part is in scope.

• Know what you run. safeguard scan --dir . scans a repository, safeguard scan --image <name> scans a container image and safeguard scan --sbom <file> reads an existing SBOM. Results land as JSON under ./output. In the platform, you can see which projects contain a given component and version, which is the question you need answered fast when a new advisory lands.
• Match against vulnerability data, then rank by reachability. Findings are matched against vulnerability databases, and reachability analysis shows which vulnerable code paths your application actually calls, so the internet-facing services that hold customer data get fixed first.
• Stop vulnerable versions shipping. Policies and gates are evaluated in the platform and in CI with safeguard exec, so a portal or API that touches loyalty data cannot deploy with a known exploited vulnerability.
• Fix with approval. Autonomous remediation opens fix pull requests and ships switched off by default. The Safeguard CLI's assistant can edit code and run commands with your approval, with /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. Desktop and phone apps can send work to a computer running the CLI and approve each command.

None of this replaces MFA, log correlation or egress control. It covers the software you build and ship, so that a missing patch is one fewer thing an intruder can use.

Zero-Day Discovery and Gold

Two Safeguard capabilities are aimed at the time before and just after a vulnerability becomes public. They are relevant to the general habit this post argues for, which is shortening the time between "a fix exists" and "the fix is running". Nothing below is about this incident's access method, which is undisclosed.

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in two modes: an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. It does not cover operating systems, appliances or commercial business software, so it would not apply to a closed vendor product running on a business server.
• Gold Open Source at gold.safeguard.sh is free and needs no login. It gives 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 paid. It provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages. An artifact loses its badge if it regresses.

The point is the habit: pull patched, signed components from a curated source and rebuild fast, so the applications in front of your customer data are not the easy step.

Common mistakes after a breach like this

Treating "no card data" as "low risk". Name, birth date, address, phone and email are what most phishing and phone fraud needs. Plan customer communications accordingly.

Adding up the numbers. The 2.5 million customer records and 10,000 partner records are different categories, counted as records, and labelled "may have leaked". Do not report "2.51 million people affected".

Assuming the access vector. It has not been disclosed. Linking this to a particular vulnerability or campaign without evidence spreads misinformation and sends defenders to the wrong logs.

Only checking the first server. In a sequential intrusion, the server where you first notice something may not be where it started. Review authentication across all hosts reachable from the first one.

Resetting passwords before collecting logs. Rotation is essential, but capture authentication and network logs first. Resetting accounts can overwrite the evidence you need to scope the intrusion.

Forgetting test and analytics copies. Customer data copied into a reporting database or a test environment often has weaker controls than production.

Open questions

• What was the initial access method, and when did the attacker first obtain it?
• Which servers were involved, and did any hold data beyond the listed fields?
• How much data was actually extracted, as opposed to "may have leaked"?
• What is the scope of employee data?
• When will member points return?
• Will a follow-up report, like the 2023 third report, describe the forensic findings and recurrence measures?

We will update this post if the company publishes a second report.

FAQ

What happened at &ST HD?

On 22 October 2026, starting about 07:30 JST, an outside party carried out login attempts, intrusion and data extraction against several of the company's business servers in sequence. The company detected it about 10:00, isolated the servers and blocked the access route by 17:00. It disclosed the incident on 23 October.

How many people are affected?

The company says about 2.5 million customer records and about 10,000 partner records may have leaked. These are record counts and "possible leak" estimates as of 23 October, not confirmed exfiltration or unique people. Employee data scope is still being checked.

Were credit card numbers or passwords exposed?

According to the company, no. Payment information such as credit card data, and passwords that customers set themselves, are not included.

Is the and ST web store safe to use?

The company says stores and the web store remain open and that the web store was not affected by this intrusion. Member points cannot currently be used in stores or online.

How did the attackers get in?

The company says it has identified the method and dealt with it, but has not disclosed what it was. Any specific claim about the access vector is speculation until the company says more.

Is this connected to the 2023 Adastria breach?

The company has not connected them. The 2023 intrusion happened on 18 January 2023 and was investigated and reported separately. Treat them as two events.

Has anyone claimed responsibility?

We found no public claim in the sources we reviewed. The notice does not mention ransomware or a ransom demand.

I am a supplier to &ST HD. What should I do?

Expect a notice from the company. Meanwhile, tell your finance and logistics teams to verify any change of bank details, delivery or return addresses by calling a number already on file. Partner contact data is useful for invoice and payment diversion fraud.

Does Japanese law require the company to report this?

Yes. The PPC requires a report when a leak may involve more than 1,000 people or may have been caused by an unlawful act. A preliminary report is expected within about three to five days of discovery and a final report within 60 days for unlawful-act cases. The company says it reported to the PPC on 23 October.

Could Safeguard have prevented this?

We cannot say that, and we do not claim it. The access method is unknown, and Safeguard does not monitor logins or network traffic. What Safeguard does is help teams find and fix known vulnerable components in the software and container images they build and ship, which narrows one common route into servers.

Related reading

• Japan breach wave, October 2026: Yamato, Nikkei, FANCL and ARTEX
• Capcom ID breach: what is confirmed
• Burger King Japan data breach: what to know
• October 2026 security incidents: what would have helped
• SBOM incident response: finding affected products fast

Fix it without waiting for upstream

This incident's access method is undisclosed and may not involve open source at all. Where internet-facing applications and images in front of customer data do carry known vulnerable components, these are the ways to close the gap quickly.

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

These are real product sessions on other examples. None of them shows this incident, &ST HD's systems, or a login-based intrusion.

The CLI demo shows the assistant fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For a retailer, you would run the same scan against the repository behind a member portal or partner ordering service and ask the assistant to move a vulnerable dependency to its fixed version. It asks before each command.

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

The desktop app demo shows a CLI session in the conversation list, a request for work on the computer, a folder choice, and Approve or Deny on each command and file edit, ending with the upgrade done and tests passing. During an incident, when several teams are patching at once, that per-step approval keeps a human in charge of every change to a system that touches customer data.

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

The mobile demo is a real Android session: it sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. The incident here started at 07:30, before most office hours. The same flow lets an on-call engineer approve an upgrade or a rebuild from a phone without opening a laptop.

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

To try it on your own code, download Safeguard and follow the CLI docs.

Quick check

Sources

• &ST HD: Notice of unauthorised access to business servers and possible leak of personal information (23 Oct 2026) (primary)
• TDnet filing, &ST HD, 23 Oct 2026, 17:00 JST (primary)
• TDnet daily disclosure list, 23 Oct 2026 (primary)
• Adastria TDnet filing, second report, 24 Jan 2023 (primary, earlier separate incident)
• Adastria TDnet filing, investigation results, 31 Mar 2023 (primary, earlier separate incident)
• Personal Information Protection Commission: Handling leaks and reporting (primary)
• NIST SP 800-63B rev 4: Authentication and Authenticator Management (primary)
• CISA: Implementing Phishing-Resistant MFA fact sheet (primary)
• MITRE ATT&CK T1110: Brute Force
• MITRE ATT&CK T1078: Valid Accounts
• MITRE ATT&CK T1021: Remote Services
• MITRE ATT&CK TA0010: Exfiltration
• Microsoft Learn: Event 4625, an account failed to log on
• Microsoft Learn: Event 4624, an account was successfully logged on
• Tokyo Shimbun (Kyodo): &ST HD information may have leaked, 2.5 million records
• d menu news (Kyodo): &ST HD 2.5 million records
• Yahoo! News Japan (Jiji Press): &ST HD customer data, 2.5 million records may have leaked
• livedoor News: &ST HD customer data may have leaked
• Business+IT: &ST HD announces possible leak of about 2.5 million customer records
• Security news report on the &ST HD incident
• Payment Navi: and ST builds a fashion platform on a 21.2 million member base (10 Mar 2026)

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