Japan Breach Wave, October 2026: Yamato, Nikkei, FANCL and ARTEX

On 16 October 2026, three Japanese companies published breach notices on the same day: Yamato Transport (about 5.31 million records from its Kuroneko pay later service), Nikkei (about 1.83 million records from a development cloud) and FANCL with Attenir (834,947 member records). No card data was involved. Customers should expect targeted phishing; engineering teams should review cloud credentials and bulk data access.

This post sets out what each company has confirmed in its own notice, what is still unknown, and the technical detail a defender can use. It also covers a separate finding published on 19 October by GMO Cybersecurity by Ierae, which says ARTEX, an AI penetration testing framework, was running on attack infrastructure aimed at about 20 Japanese companies. That finding is context for the month. It is not linked to Yamato, Nikkei or FANCL: GMO did not name any company, and none of the three companies has said anything about AI tooling or about who attacked them.

We do not speculate about how any of the three were breached. Where a company has not stated a cause, we say so and stop there.

The short version

Sources: the Yamato notice, the Nikkei notice and the FANCL and Attenir notice, all dated 16 October 2026.

Why these three are written up together

They are different companies, different systems and, as far as anyone has published, different incidents. They belong in one post for three practical reasons.

First, the timing. All three notices went out on 16 October, and Japanese outlets reported them side by side. NHK's page on the Nikkei story, published at 18:13 that day, listed the Yamato disclosure and a third, unrelated leak at another retailer alongside it. Customers of all three are now receiving notification emails in the same fortnight, which is exactly the setting phishing crews like.

Second, the shape. Each incident hit a back end that holds customer contact data at scale: a pay later ledger, a development cloud, and two e-commerce member databases. None of them involved payment card data. The data that did leak (names, addresses, phone numbers, email addresses, birth dates, and in Yamato's case product lines from real orders) is the raw material for convincing fraud.

Third, the backdrop. In the same week, a Japanese security firm said AI driven attack tooling had been aimed at about 20 Japanese companies, eight of which had already disclosed breaches. That finding does not tell us anything about these three companies. It does tell defenders in Japan, and anyone running a consumer back end, that broad and cheap reconnaissance is now normal, and that the gaps it finds are the ordinary ones: stale credentials, exposed admin functions and old application code.

Other Japanese disclosures from the same weeks, including Burger King Japan, Capcom and the Onamae Desktop Cloud service, are covered in separate posts and are not retold here.

Yamato Transport: the Kuroneko deferred payment service

What Yamato has said

Yamato Transport runs a deferred payment service for online shops: a shopper orders, the goods ship, and the shopper pays later using a payment slip. That means Yamato holds the buyer's contact details and the order lines for every transaction it underwrites.

According to Yamato's fourth report (第4報), published 16 October 2026 on the Yamato Holdings site:

• Yamato confirmed on Monday 28 September 2026 that a third party had gained unauthorised access to the service.
• It restricted external access promptly after confirming the intrusion, reported to Japan's Personal Information Protection Commission (PPC), and investigated with an external security specialist.
• Its investigation confirmed that some data was taken out of the system.
• Credit card information and passwords were not included.
• Billing amounts, receivable balances and Yamato staff names were not confirmed as taken. The second report, on 2 October, had flagged these as possibly affected.
• Data from other Yamato services, including Kuroneko Members and Yamato Business Members, was not confirmed as taken.
• As of the fourth report, Yamato had confirmed no secondary harm from misuse.
• Affected people will be contacted individually. For people who cannot be reached, for example because their registered details have changed, the notice itself serves as notification.

INTERNET Watch, reporting at 17:06 on 16 October, adds that the service restarted on 9 October, which matches the title of Yamato's third report.

The three categories of data

The notice splits the confirmed data into three groups. The figures are records, not people. Yamato's headline of about 5.31 million is the sum of the buyer and recipient groups, and several Japanese outlets have pointed out it does not mean 5.31 million individuals.

Source: Yamato fourth report, corroborated by INTERNET Watch.

Two details in that table matter for anyone thinking about follow on fraud. Product names, quantities and unit prices from real orders let a scammer write a message that refers to something the victim actually bought. Waybill numbers for delivery recipients let a scammer reference a real parcel. Yamato's notice warns customers not to open links or attachments in unexpected email or SMS and to be careful with suspicious calls and post, and it points to a separate page about fake emails that impersonate Yamato.

What Yamato has not said

The notice does not describe the entry method, the attacker, the systems involved beyond the service name, or the specific security measures taken. It says Yamato will strengthen its information security with advice from external experts, through measures already in place and further mid to long term measures, without listing them. We do not fill that gap.

Nikkei: a development cloud and stolen credentials

What Nikkei has said

Nikkei's notice, dated 16 October 2026, is short and specific about the mechanism, if not the details:

• A cloud service that Nikkei uses for system development was accessed without authorisation from the early hours to the morning of the 7th (the notice gives the day; reporting by NHK, INTERNET Watch and SecurityWeek places it on 7 October 2026).
• The credentials used to access the cloud service had been stolen by some means (「何らかの手段で窃取されました」). Nikkei does not say how.
• About 1.83 million records were leaked as of 16 October.
• About 150,000 of those contain at least one of name, email address, postal address, phone number or date of birth. About 120,000 of those include an email address.
• About 1.68 million contain only identifiers that cannot identify a person on their own.
• Credit card information is not included. The notice does not mention passwords either way.
• Nikkei invalidated the credentials used, reported to the PPC on the 11th, and is investigating the scope and the leaked data.
• As of 16 October, Nikkei had confirmed no secondary harm, no service outage and no data tampering.
• People whose personal information is confirmed as leaked will be told individually.

SecurityWeek, reporting on 20 October, describes the credentials as "previously compromised" and says Nikkei revoked them right after identifying the breach.

What makes this one different

Of the three incidents, Nikkei's is the only one where the company has named the class of failure: valid credentials for a cloud environment used for development. That is a familiar and uncomfortable pattern. Development environments often hold copies of production data for testing, often use long lived access keys for automation, and often sit outside the monitoring that covers production. Nikkei has not said which of those, if any, applied. The notice does not name the cloud provider, the services whose users are affected, or the registration periods involved.

What is clear from the numbers is that most of the 1.83 million records are identifiers rather than personal data. That split (about 8 percent of records with identifying fields) is what you would expect from a store that mixes user profile tables with event or session tables. It is also a reminder that a record count alone says little about harm; the 150,000 figure is the one that matters for notification.

What Nikkei has not said

How the credentials were stolen; which cloud service; which Nikkei products or registration periods; whether passwords or password hashes were in the data; whether police were informed. SecurityWeek notes that Nikkei disclosed an unrelated breach less than a year earlier that stemmed from a hacked Slack account. Nothing links the two, and we do not suggest a connection.

FANCL and Attenir: two e-commerce sites, one notice

What the companies have said

FANCL and Attenir, both part of the Kirin group, published a joint notice on 16 October 2026. The PDF's own metadata shows it was created at 15:16 JST that day. According to the notice:

• An internal investigation on Thursday 15 October 2026 found that both companies' e-commerce sites had received unauthorised access between Saturday 3 October and Saturday 10 October.
• An emergency task force was set up the same day. The investigation confirmed that part of the member information held by both companies had leaked.
• To stop further damage, the companies identified the function that caused the leak and stopped it (原因となった機能を特定し、その機能を停止しました). The notice does not name the function.
• No other unauthorised access and no malware infection had been found, and business operations were not affected.
• No public posting of the data, no misuse and no customer reports of harm had been confirmed.
• The companies reported to the PPC and consulted the police on 16 October.
• They are withholding the details of the cyberattack to prevent further damage (サイバー攻撃の詳細については開示を差し控えさせていただきます).

The data, field by field

The data items are the same for both brands:

• Email address, name, address, phone number, date of birth, gender, customer number.
• Sub email address and its password, in hashed form. The notice explains this is a hashed secondary password that some members had set, that it cannot be read as is, and that the main password is not included.
• Identity verification question items, without the answers.
• Other member registration data: points, member stage, whether the member wants the email newsletter, and whether they have bought in a store.

Payment information such as credit cards was not included.

The notice asks customers to watch for impersonation emails, SMS and calls, not to open unexpected links or attachments, and to update passwords regularly. It says neither company will ever ask for a password or card details. A shared helpline opened at 09:00 on 17 October.

NHK headlined the figure as "more than 780,000 people" and some outlets as "about 830,000 records". Both are right; one counts people and the other counts records.

What the companies have not said

The function that was abused, the hashing algorithm used for the secondary password, the attacker, and how the access was discovered.

Separate context: GMO's ARTEX finding

This section is context for the month in Japan. It is not an explanation of the three incidents above, and nothing published so far connects them.

What GMO reported

On 19 October 2026, GMO Cybersecurity by Ierae, part of GMO Internet Group, published research on the infrastructure behind recent intrusions at Japanese companies. Its own blog was running in a reduced mode when we tried to read it, so the details below come from Japanese and English reporting that cites it: Business+IT (SBBIT) and Rocket Boys in Japanese, and Jiji (via nippon.com) and the Taipei Times in English.

• GMO says it identified ARTEX, an autonomous penetration testing system that uses large language models, running on attack infrastructure used against Japanese companies.
• The first piece of infrastructure it examined had targeted about 20 Japanese companies, nine of them in the same industry, according to SBBIT and Rocket Boys.
• GMO also found six further pieces of attack infrastructure using AI, aimed almost only at Japan, each focused on different industries. Rocket Boys lists digital gifts and retail, education and printing, points and marketing, insurance and finance, and e-commerce, media and logistics.
• Eight of the targeted companies had disclosed data leaks in September and October 2026. GMO attributes those to the same group and has shared its findings with law enforcement.
• GMO did not name any of the companies. Rocket Boys stresses that "targeted" does not mean successfully breached.
• GMO had said on 15 October, from forensic log analysis, that AI was probably being used in recent Japanese intrusions; the 19 October report supports that estimate.

Where reports differ

• Date. SBBIT and Rocket Boys date GMO's report 19 October. The Taipei Times says GMO announced on 20 October; Jiji's English story is dated 20 October.
• The six servers. Jiji (via nippon.com) says all six servers used ARTEX. Rocket Boys says GMO did not state that ARTEX was confirmed on all six, only that they used AI.
• Sectors. Jiji describes the targets as financial and logistics companies. The Taipei Times describes the six servers as covering finance, e-commerce and logistics.

What ARTEX is

ARTEX first surfaced in reporting about South Korea, not Japan. The Hacker News, writing on 8 October 2026 from a security vendor's research, describes it as an open source, LLM driven, multi agent system for autonomous penetration testing published by the GitHub user Autumn-27. That research linked it to data theft from South Korean financial firms between late September and early October. The developer said the misuse ran against the tool's purpose, stopped updates and moved the project to closed source. The Taipei Times reports the developer called attacks with it "entirely contrary to" its intentions.

What this does and does not mean for the three companies

It does not mean Yamato, Nikkei or FANCL were attacked with ARTEX. GMO has not said so, the companies have not said so, and we have no basis to suggest it. Nikkei's stated cause, stolen cloud credentials, is not something a penetration testing tool is needed for. The useful lesson is general: when reconnaissance and exploitation of known weaknesses can be automated and run against dozens of companies at once, the gap between a weakness existing and someone trying it gets very short.

Timeline

Times are Japan Standard Time unless marked. Where a source gives only a date, the time column says so.

What changed since first reports

• Yamato narrowed its scope. On 2 October the company said billing amounts, receivable balances and staff names might be affected. On 16 October it said none of those were confirmed as taken, and it gave firm counts and data periods for the first time.
• Yamato's count is records, not people. Early headlines used "5.31 million". The notice itself breaks that into three groups and does not give a count of individuals.
• FANCL and Attenir figures exist in two units. Records (834,947) and people (785,496). Reports quoting "about 780,000" and "about 830,000" are describing the same notice.
• GMO moved from estimate to finding. On 15 October it estimated AI use from logs. On 19 October it said it had found ARTEX on attack infrastructure. Neither statement named a victim.
• ARTEX went closed source. Reports in early October described it as open source on GitHub. By 8 October the developer had closed the source and stopped updates, according to The Hacker News.

Technical details

None of the three companies has published indicators of compromise, hashes, IP addresses, file names or vendor and version details for the systems involved. FANCL and Attenir explicitly withheld attack details. What follows is everything defender useful that the primary notices do contain, with each value attributed.

Data scope by system

Official contact points

Use these to check whether a message claiming to come from one of the companies is genuine. Do not reply to an unexpected email to verify it; go to the company site yourself.

Regulatory clock under APPI

All three companies reported to the PPC. Under the Act on the Protection of Personal Information, a business must report a leak that involves sensitive personal data, data whose misuse could cause financial loss, a leak that may have been done for an improper purpose (which includes theft by an outsider), or more than 1,000 people. The PPC's guidance page gives the deadlines: a preliminary report (速報) within about 3 to 5 days of discovery, and a final report (確報) within 30 days, or 60 days where the leak may have been for an improper purpose. Each of these incidents meets at least two triggers: unauthorised access by a third party, and far more than 1,000 people. Nikkei reported on the 11th for access on the 7th, and FANCL and Attenir reported on the 16th for a discovery on the 15th. Yamato's notice does not give its report date.

ARTEX indicators (South Korea campaign only)

GMO has not published indicators for the Japanese infrastructure it examined, as far as the reporting we could read shows. The only published ARTEX indicators we found come from the South Korea campaign, as reported by The Hacker News from a security vendor's research. They are listed here so defenders who track ARTEX can check their logs. They are not linked to Yamato, Nikkei, FANCL or Attenir by any source.

The Hacker News also reports that the ARTEX instance used DeepSeek as its main model backend with other commercial models supplementing it. a security vendor did not tie the activity to a known group.

Who is affected and what customers should do

Detection and remediation for engineering teams

None of this describes how the three companies were breached. It is a checklist for teams that run similar systems: payment back ends, development clouds and e-commerce member stores. Run what applies to you this week.

1. Find and retire long lived cloud credentials

Nikkei's notice names stolen credentials for a development cloud. Start by listing every static key and how recently it was used.

AWS:

# Every IAM user's access keys, with age and status
aws iam list-users --query 'Users[].UserName' --output text | tr '\t' '\n' | while read u; do
  aws iam list-access-keys --user-name "$u" \
    --query 'AccessKeyMetadata[].[UserName,AccessKeyId,Status,CreateDate]' --output text
done

# When and where one key was last used
aws iam get-access-key-last-used --access-key-id AKIAEXAMPLEKEYID

# Full credential report as CSV (key age, last use, MFA)
aws iam generate-credential-report && sleep 5
aws iam get-credential-report --query Content --output text | base64 --decode > cred-report.csv

Google Cloud:

# User managed service account keys in a project
for sa in $(gcloud iam service-accounts list --format='value(email)'); do
  gcloud iam service-accounts keys list --iam-account "$sa" --managed-by=user \
    --format='table(name.basename(),validAfterTime,validBeforeTime)'
done

Azure:

# App registrations with client secrets and their expiry
az ad app list --all --query '[].{app:displayName,id:appId}' -o tsv | while read name id; do
  az ad app credential list --id "$id" --query "[].{app:'$name',end:endDateTime,hint:hint}" -o tsv
done

Then act on what you find:

1. Disable any key unused for 90 days, wait a week, then delete it.
2. Replace keys used by CI with short lived federated identity (OIDC from your CI system to the cloud provider) so there is no static secret to steal.
3. Require MFA for every human account that can reach development projects, and phishing resistant methods (security keys or passkeys) for administrators.
4. Put development projects under the same audit logging and alerting as production. A development account that can read customer data is a production account in every way that matters.

2. Get production personal data out of development and test

If a development environment holds a copy of real customer data, its breach is a customer data breach. Check what is actually there.

-- PostgreSQL: find columns that look like personal data in a dev database
SELECT table_schema, table_name, column_name
FROM information_schema.columns
WHERE column_name ~* '(mail|phone|tel|addr|birth|dob|name|zip|postal)'
  AND table_schema NOT IN ('pg_catalog','information_schema')
ORDER BY 1,2,3;

-- MySQL equivalent
SELECT table_schema, table_name, column_name
FROM information_schema.columns
WHERE column_name REGEXP 'mail|phone|tel|addr|birth|dob|name|zip|postal'
  AND table_schema NOT IN ('mysql','sys','performance_schema','information_schema');

For object storage, list what is sitting in development buckets and when it was written:

aws s3 ls s3://your-dev-bucket --recursive --human-readable --summarize | tail -20
gcloud storage ls -l -r gs://your-dev-bucket | tail -20

Replace real records with synthetic or masked data, and set a rule that production exports into development need a ticket and an expiry date.

3. Alert on bulk reads from customer stores

All three incidents involved a large volume of records leaving a system. Whatever the entry point, bulk reads are visible if you look for them.

AWS CloudTrail Lake or Athena over CloudTrail logs, looking for unusual data access by identity:

SELECT useridentity.arn, eventname, count(*) AS calls,
       min(eventtime) AS first_seen, max(eventtime) AS last_seen
FROM cloudtrail_logs
WHERE eventtime > '2026-09-01'
  AND eventname IN ('GetObject','SelectObjectContent','ExecuteStatement','BatchExecuteStatement','CreateDBSnapshot','CopyDBSnapshot','ModifyDBSnapshotAttribute')
GROUP BY 1,2
ORDER BY calls DESC
LIMIT 50;

PostgreSQL, with pg_stat_statements enabled, to see which queries return the most rows:

SELECT left(query, 120) AS query, calls, rows, rows / NULLIF(calls,0) AS rows_per_call
FROM pg_stat_statements
ORDER BY rows DESC
LIMIT 20;

MySQL 8, to find statements that sent the most rows:

SELECT DIGEST_TEXT, COUNT_STAR, SUM_ROWS_SENT, SUM_ROWS_SENT / COUNT_STAR AS rows_per_call
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_ROWS_SENT DESC
LIMIT 20;

Web access logs, to find clients pulling far more member or order pages than normal (adjust the path pattern to your application):

# Top client IPs hitting member, order or export endpoints in the last log file
awk '$7 ~ /\/(member|mypage|order|export|api\/customer)/ {print $1}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

Set an alert threshold on rows per identity per hour, based on a normal week. Multi day windows like FANCL's 3 to 10 October are exactly what a daily volume alert is meant to catch.

4. Inventory every internet facing commerce component

GMO's advice, as summarised by Rocket Boys, starts with inventory: list externally exposed web systems, APIs, admin panels and legacy applications, and confirm who owns and maintains each one. It also warns against trusting a web application firewall in place of patching. That is directly actionable.

For each e-commerce or payment front end, record the platform, version and plugins:

# PHP based storefronts: runtime and Composer packages
php -v
composer show --format=json > composer-inventory.json
composer audit

# Node based storefronts and APIs
node -v
npm ls --all --json > npm-inventory.json
npm audit --omit=dev

# Container images you deploy
docker image ls --format '{{.Repository}}:{{.Tag}} {{.CreatedSince}}'

PHP storefronts deserve particular attention this month because of PHP2Shell. If you run one, read PHP2Shell explained and the practical guide to finding and patching every PHP runtime. Nothing published links PHP2Shell to any of the three incidents here; the point is that the same inventory serves both jobs.

5. Close down admin functions and export features

FANCL and Attenir say they identified the function that caused the leak and stopped it. Whatever that was, most e-commerce platforms have features that can return many member records at once: CSV export, bulk search, reporting endpoints and debug or legacy APIs. List them, and for each one:

1. Require an authenticated administrator session with MFA.
2. Restrict by source network where you can.
3. Log every call with the identity and the row count.
4. Remove the feature if nobody has used it in a year.

6. Treat hashed secondary passwords as exposed

A hash that "cannot be read as is" can still be guessed offline if the password was weak or the hash was fast. If your platform stores any secondary or legacy password:

1. Check the algorithm. If it is unsalted MD5, SHA-1 or SHA-256, plan a migration to a slow, salted algorithm such as Argon2id or bcrypt, rehashing at next login.
2. After a breach of hashes, force a reset of the affected credential rather than only advising a change.
3. Tell members to change the same password anywhere else they used it.

# Quick check of the hash format stored in a table (looks at prefixes such as $2y$ or $argon2id$)
psql -c "SELECT left(secondary_password_hash, 10) AS prefix, count(*) FROM members GROUP BY 1 ORDER BY 2 DESC;"

7. Prepare customer communications that resist phishing

Every notice in this wave tells customers to distrust unexpected messages. Make that easier:

1. Publish your notice on your own domain and link to it from your home page, so customers can check without clicking an email.
2. Never include links that ask for a login in breach notification emails.
3. Set up SPF, DKIM and a DMARC policy of quarantine or reject on every domain that sends customer mail, and check it:

dig +short TXT _dmarc.example.co.jp
dig +short TXT example.co.jp | grep spf

4. Register obvious lookalike domains before someone else does.

8. Review payment and commerce vendors

Yamato's deferred payment service sits between online shops and their customers. If you are a merchant, your customers' data lives at your payment provider as well as in your own systems. Keep a list of every provider that holds customer data on your behalf, what fields they hold, how long they keep them, and who you call during an incident. For a related Japanese example of third party exposure, see our post on IDCF Cloud ransomware and third party risk.

Common mistakes and troubleshooting

• Adding the counts up as people. Yamato's 5.31 million and FANCL's 834,947 are records. Use the people figure where the company gives one, and say "records" otherwise.
• Saying these breaches were AI driven. No company has said so, and GMO named no victims. Keep the ARTEX finding as context.
• Rotating the stolen key and stopping there. Revoking one credential closes one door. Audit every key with the same scope, and check what the attacker could have created with it, such as new users, keys, roles or snapshots.
• Watching production and ignoring development. If development projects lack CloudTrail, Cloud Audit Logs or Azure Activity Log retention, you will not be able to scope an incident there.
• Trusting the WAF instead of patching. GMO's guidance, as reported, separates the two. A WAF buys time; it does not remove the flaw.
• Masking only some columns. Masking names but leaving phone numbers and birth dates in test data leaves the data identifiable.
• Forgetting merchants and recipients. Yamato's data includes people who never signed up for anything: parcel recipients. Your notification plan needs a route for people who are not your customers.
• Breach emails with login links. They train customers to click exactly the kind of link phishing will use next week.

Open questions

• How did the intruders get into Yamato's deferred payment service? Not stated.
• How were Nikkei's development cloud credentials stolen, which provider is involved, and which Nikkei services' users are affected? Not stated.
• Which e-commerce function did FANCL and Attenir stop, and what hashing algorithm protected the secondary passwords? Not stated.
• Are any of these three among the eight companies GMO says disclosed breaches after being targeted from ARTEX infrastructure? GMO has not named them, and we do not guess.
• Did ARTEX run on all six additional servers GMO found? Sources disagree.
• Will the totals change? All three companies say investigations continue and they will publish new facts if found.

What would have helped

The causes are not public, so none of this is a judgement about Yamato, Nikkei, FANCL or Attenir. It is what any team running similar systems can put in place so that a breach is less likely, smaller, found sooner and handled faster.

Practices any team can use

• Short lived credentials for development clouds. Federated identity for CI and people, no static keys, and MFA everywhere. A stolen credential that expires in an hour is worth far less than one that lives for a year.
• No production personal data in development. Synthetic or masked data by default, exceptions with an owner and an expiry.
• Bulk read alerts on every customer store. Rows per identity per hour, with a threshold set from a normal week.
• An inventory of internet facing commerce systems. Platform, version, plugins, owner, and the date of the last patch. When a framework CVE lands, you should be able to find every affected storefront the same day.
• Admin and export features behind MFA and logging. Remove the ones nobody uses.
• Strong hashing for every stored password, including legacy and secondary ones.
• A tested notification plan. PPC preliminary report fields, customer notice text in Japanese and English, and a phishing resistant way for customers to verify messages.
• A vendor register for payment and commerce providers. What they hold for you and who to call.

Zero-Day Discovery and Gold

Two Safeguard capabilities relate to the component side of these back ends, 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. Nothing published suggests a package flaw played any part in these three incidents, and Zero-Day Discovery does not look at cloud credentials, account access or how your own application authorises an export. We make no claim that it found, or could have found, anything related to them.

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.

The habit both support is simple: pull patched, signed components from a curated source, and rebuild and redeploy quickly when a fix lands. For storefronts and payment APIs, that shrinks the window in which a known bug in the stack can be found by the kind of automated reconnaissance GMO describes.

Where Safeguard fits

Safeguard helps with the parts of this problem that live in code, components and suppliers:

• SBOM and dependency scanning of repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, with JSON results under ./output), and a platform view of which projects contain a given component and version. That answers "which of our storefronts run this version?" in minutes.
• Vulnerability matching against vulnerability databases, with reachability analysis to show which findings sit on code paths your application actually uses.
• Policies and gates evaluated in the platform, and autonomous remediation that opens tested fix PRs. It ships switched off.
• Asset discovery across repositories, images, packages and SBOMs, with guardrails applied to what it finds.
• Third Party Risk Manager for a register of vendors, risk tiers and continuous alerts on vendor risk changes, useful for payment and e-commerce providers that hold customer data for you.
• 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 stolen cloud credentials or an intrusion in progress, does not monitor database reads, does not block phishing aimed at your customers, and does not file PPC reports or send breach notices. The three companies have not disclosed causes, so we cannot say whether any of the above would have changed the outcome, and we do not claim it would have prevented any of them.

FAQ

What happened in Japan in mid October 2026?

On 16 October, Yamato Transport, Nikkei, and FANCL with Attenir each disclosed unauthorised access that exposed customer data: about 5.31 million records, about 1.83 million records and 834,947 records respectively. None involved card data. The incidents are separate as far as any company has said.

Was my credit card exposed?

All three companies say card data was not included. Yamato and FANCL also say passwords (in FANCL's case, the main password) were not included. Nikkei's notice does not mention passwords.

How did the attackers get in?

Only Nikkei has described the mechanism: stolen credentials for a development cloud, stolen by means it has not identified. Yamato has not stated an entry method. FANCL and Attenir say they found and stopped the function that caused the leak and are withholding attack details.

Were these attacks carried out with ARTEX or AI?

Nobody has said so. GMO Cybersecurity by Ierae found ARTEX on infrastructure that targeted about 20 Japanese companies, eight of which had disclosed breaches, but it named none of them. Treat the ARTEX finding as context for the month, not as an explanation of these three incidents.

What is ARTEX?

An LLM driven, multi agent autonomous penetration testing system published on GitHub by the user Autumn-27, described in reporting as developed in China. That research linked it to data theft at South Korean financial firms. The developer stopped updates and moved it to closed source in early October.

Has the data been published or misused?

As of their 16 October notices, all three companies said they had confirmed no misuse or secondary harm. FANCL and Attenir also said they had found no public posting of the data.

Do these companies have to notify me?

Under Japan's APPI, a leak caused by unauthorised access or affecting more than 1,000 people must be reported to the PPC, and the people affected must be notified. All three companies say they are contacting affected people individually; Yamato says its notice also serves as notification for people it cannot reach.

Why is a development cloud breach a customer data breach?

Because the development environment held customer data. Nikkei's notice shows about 150,000 records with personal identifiers in that cloud. Any environment with real customer records needs production level access control and monitoring.

What should an e-commerce team check first?

Static cloud keys and their last use, production data in development, bulk read alerts on member and order tables, and an inventory of internet facing storefront components with versions. The commands above cover each.

Would Safeguard have prevented these breaches?

We do not claim that. The causes are not public. Safeguard can show which of your projects carry a vulnerable component, prioritise and fix it, and track the vendors that hold your customers' data. It does not detect credential theft or monitor database access.

Fix it without waiting for upstream

None of the three companies has said a vulnerable open source component was involved. But the GMO guidance reported this month starts with patching what is exposed, and the storefronts and APIs that hold customer data are built largely from open source. This is how to keep that part current without waiting on anyone.

In incidents like this one, 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 Yamato, Nikkei, FANCL or Attenir. Each is a real Safeguard session, and each intro says how the same flow applies to an e-commerce or payment back end.

This real CLI session fixes a lodash CVE in a sample repository: the assistant 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 storefront, you would run /scan . in the shop's repository, ask the assistant to upgrade a vulnerable framework or plugin it found, and approve each command as it runs.

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 a payment API, you would pick the service folder, ask for the dependency upgrade, and approve or deny each edit yourself before it is rebuilt.

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, which is the inventory question every storefront owner faced this month.

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 the wider month, see October 2026 security incidents and what would have helped, and for fast scoping with SBOMs, finding affected products fast.

Quick check

Sources

• Yamato Holdings: Kuroneko deferred payment service unauthorised access, fourth report, 16 Oct 2026 (Japanese)
• Nikkei Inc.: Personal information leak due to unauthorised access, 16 Oct 2026 (Japanese)
• FANCL and Attenir: Apology and notice on personal information leak from third party unauthorised access, 16 Oct 2026 (Japanese, PDF)
• FANCL news list (Japanese)
• NHK: Nikkei cloud service unauthorised access, 1.83 million records, 16 Oct 2026 (Japanese)
• INTERNET Watch: Yamato Kuroneko deferred payment leak, 16 Oct 2026 (Japanese)
• INTERNET Watch: Nikkei cloud service leak, 16 Oct 2026 (Japanese)
• ScanNetSecurity: Unauthorised access to Kuroneko deferred payment service, 1 Oct 2026 (Japanese)
• SecurityWeek: Hackers steal 1.8 million records from Nikkei, 20 Oct 2026
• Business+IT (SBBIT): GMO finds ARTEX on attack infrastructure (Japanese)
• Rocket Boys Security Measures Lab: GMO ARTEX finding and recommendations (Japanese)
• nippon.com (Jiji): Chinese AI tool likely used in cyberattacks on Japan firms, 20 Oct 2026
• Taipei Times: GMO finding on ARTEX, 21 Oct 2026
• The Hacker News: ARTEX AI pentesting tool used in data theft attacks on South Korean financial firms, 8 Oct 2026
• Personal Information Protection Commission: Responding to leaks (Japanese)

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