Sagawa Express Breach: Up to 53.23M Shipping Records, What to Know

Sagawa Express says a third party broke into the system behind its online parcel tracking service, and that up to about 53.23 million personal data records may have leaked. That figure counts records with duplicates still in it, not people. Senders, recipients, contract customers and Smart Club members are in scope. Expect courier phishing; merchants should prepare their APPI reports.

This post sets out what Sagawa Express has confirmed across its five official reports and its FAQ, what the 53.23 million figure does and does not mean, which services are still offline, what online merchants and other shippers need to do under Japan's Act on the Protection of Personal Information (APPI), and what any team running a tracking or lookup service can check this week. Sagawa has not said how the intruder got in, and we do not guess.

What happened

Sagawa Express (佐川急便) is one of Japan's major parcel carriers. Its website offers a parcel inquiry service (お荷物問い合わせサービス): you type in the number printed on a shipping slip and see where the parcel is. According to Sagawa's fourth report, that service runs on a system the company calls the Internet freight system (インターネット貨物システム). The same system backs a business tracking API, online pickup booking, return and refund pickup services and delivery redirection.

On 30 September 2026, Sagawa confirmed unauthorized access by a third party to the inquiry service. The next day it said customer personal data may have leaked, shut down nine web services and cut all external access to the Internet freight system at noon. On 23 October, in its fifth report, it put the maximum count of possibly leaked personal data at about 53.23 million records (最大約5,323万件), with duplicates included, and brought the web tracking page back online.

Timeline

What is still unknown

• How the intruder got in. Sagawa's FAQ says the cause is still being investigated with an outside specialist firm. No vulnerability, product, credential or technique has been named.
• When the access began. Only the discovery time, 07:30 on 30 September, is public.
• Who did it. No group has been named by Sagawa, and we have not seen a credible claim in the reporting we read.
• How many people are affected. Sagawa says the 53.23 million figure is not a head count and that it is still removing duplicates.
• The split by category. Sagawa has not published how many records come from shipping slips, the contract customer list or Smart Club, because duplicates make those numbers misleading.
• Whether item names or delivery histories were taken. The FAQ says this is still being checked (Q3-4).
• When the tracking API and booking services come back. No date has been given.

What the 53.23 million figure means

The number in the headlines is easy to misread, and Sagawa has gone out of its way to explain it. Read it as a ceiling on records, not a count of people.

• It is a record count with duplicates. The same person can appear many times. Someone who received ten parcels from online shops between June and September appears on ten slips. A business that ships daily appears on hundreds or thousands.
• Some deduplication has been done, but not all. Sagawa says it has merged duplicates "to a certain extent" (一定程度) through name matching (名寄せ), and that a considerable number of duplicates remain, especially in slip data.
• Spelling differences inflate it. The 4th report notes that names and addresses written on slips can be spelled differently for the same customer, which makes matching harder.
• It is a maximum, not a confirmed leak. The 5th report says the figure is not a count of records actually confirmed to have left the company.
• It counts people, not companies. For business customers, records that identify a specific person, such as a contact name, are counted. Records that hold only a company name and no individual are excluded.
• Handwritten slips are excluded. Parcels sent with a handwritten slip are not in scope.

A security news site in Japan described this as the largest leak count published in Japan so far in 2026. We could not confirm that ranking from an official source, and since the figure is records with duplicates rather than people, comparisons with other incidents should be made with care.

What data was involved

All of the following comes from the 2nd and 5th reports and the FAQ.

Not included, according to Sagawa:

• Credit card data
• Passwords, including Smart Club passwords
• Bank account details
• Handwritten slip data

Still being checked: item names (品名) and delivery history (FAQ Q3-4).

As of 23 October, Sagawa says it has found no secondary harm, such as misuse of the data, linked to the incident. It has reported to the PPC and says it has also consulted the police (FAQ Q6-2).

Who is affected

The FAQ is clear that you do not need a Smart Club account to be in scope. If a parcel was sent to you or by you through Sagawa between 21 June and 30 September 2026 with a typed slip, your name, address and phone number may be in the data.

Sagawa says it will contact affected customers in turn, and that for people it cannot reach individually, the public notice itself serves as the notification.

Which services are still offline

The web tracking page came back on Friday 23 October after outside specialists checked the system and new security measures were put in place. The other eight services suspended on 1 October remain offline, with no restart date.

Pickup and delivery have continued throughout. LINE inquiries also kept working during the outage, limited to delivery status.

Technical details

Sagawa has published no CVE, no affected product or version, no hashes, no IP addresses and no domains for this incident. That is common for a breach notice from a company in Japan while an outside forensic review is still running, and it means there are no official indicators of compromise to load into a blocklist. What follows is every concrete, defender-useful detail we could find in the primary sources, attributed.

Disclosed facts about the affected system

Phishing patterns Sagawa itself has documented

Sagawa keeps a standing warning page about emails that impersonate it, and the 5th report points readers to it. Two details on that page are useful for anyone writing mail filters or training material:

• Sagawa says it does not send SMS messages about pickup or delivery. Any text message claiming to be a Sagawa delivery notice should be treated as fake.
• The page lists 43 sample lures with links and sender addresses masked. Recurring subject line themes include delivery information notices (【佐川急便】配達情報のお知らせ), failed delivery and redelivery requests (配達失敗のお知らせと再配達のご案内, 再配達のご依頼はこちら), parcels held because the address is unknown (配達住所不明によるお荷物保管), urgent procedures (緊急配達状況お手続き必要), billing confirmation (請求内容確定のご案内) and shipping completion notices (出荷完了メール, 商品本日発送). Sender display names seen include 佐川急便, 佐川配達センター, SAGAWA再配達受付センター, 佐川クール便 and SAGAWA飛脚便, and some use punctuation inside the brand name to slip past filters.

These samples predate the breach, so they are not indicators tied to it. They show the lures already aimed at Sagawa customers, which could now carry a real name and address. The Council of Anti-Phishing Japan has published alerts about Sagawa-themed phishing for years, including in 2018 and 2023.

Shipper self-check: pulling your own shipment history

For shippers that need to know which of their own shipments fall in the window, FAQ Q2-7 explains how to export shipment history from Sagawa's slip issuing systems:

• Biz-LogiWEB: search range is limited to 3 months, so run two searches, 2026/06/21 to 2026/08/31 and 2026/09/01 to 2026/09/30, with "shipment confirmed" (出荷実績確定) selected.
• Biz-LogiWEB II: search range is limited to 1 month, so run four searches: 2026/06/21 to 06/30, 07/01 to 07/31, 08/01 to 08/31 and 09/01 to 09/30, with "shipment confirmed" (出荷実績確定済) selected.
• e飛伝III: the FAQ refers users to the system's own instructions.

What online merchants and other shippers need to do

This is the part of the incident that reaches beyond Sagawa. An online shop that hands parcels to Sagawa has entrusted its customers' names, addresses and phone numbers to the carrier. Under APPI, a leak of that data can create reporting duties for the shop as well.

Joint reporting to the PPC

Sagawa says it filed a preliminary report with the PPC on 1 October, and that it plans to compile the final report (確報) itself and file it jointly with each affected shipper (出荷人). Key points from the 5th report and FAQ Q6-5:

• Sagawa will contact affected shippers with the record counts and the procedure once it has confirmed them.
• A shipper that does not agree to a joint report may need to file its own preliminary and final reports.
• A joint report does not stop a shipper from filing its own report.
• A shipper that has already filed separately can switch to the joint report.
• Sagawa says it will update the PPC report as the investigation continues.

The APPI rules that apply

The PPC's guidance says a report is required when a leak of personal data involves any of four situations, two of which clearly apply here: a leak that may have been carried out for an improper purpose (不正の目的), which covers unauthorized access, and a leak affecting more than 1,000 people. The PPC asks for a preliminary report promptly, roughly within 3 to 5 days of discovery, and for cases that may involve an improper purpose, a final report within 60 days of discovery. Affected individuals must also be notified, in a way they can understand, with an outline, the data items and the cause.

Shippers should get legal advice for their own situation. The practical steps below are what most will need regardless.

A checklist for shippers

1. Find your Sagawa shipments in the window. Export shipment history for 21 June to 30 September 2026, using the date splits above if you use Biz-LogiWEB or Biz-LogiWEB II.
2. Count people, not parcels. Deduplicate recipients so that your numbers for the PPC report are people, not slips. A query like this, run against your own order database, gives both figures:

-- Shipments handed to the carrier in the affected window
SELECT
  COUNT(*)                                        AS slips,
  COUNT(DISTINCT regexp_replace(recipient_phone, '[^0-9]', '', 'g')) AS distinct_phones,
  COUNT(DISTINCT (lower(trim(recipient_name)) || '|' ||
                  regexp_replace(recipient_postcode, '[^0-9]', '', 'g'))) AS distinct_name_postcode
FROM shipments
WHERE carrier = 'sagawa'
  AND handed_over_at >= '2026-06-21'
  AND handed_over_at <  '2026-10-01'
  AND slip_type <> 'handwritten';

The gap between slips and the distinct counts is the same gap Sagawa describes between 53.23 million records and the real number of people. 3. Decide on joint or separate reporting and record the decision and the reason. 4. Prepare your customer notice in plain Japanese (and English if you sell abroad). Say which fields may be involved, that card data and passwords were not, and how to spot fake delivery messages. 5. Warn your support team. Customers will ask whether a delivery text is real. Give agents Sagawa's line that it does not send delivery SMS. 6. Check your own notification mail. If you send shipping notifications from your own domain, make sure SPF, DKIM and DMARC are in place so lookalike messages are easier to filter:

dig +short TXT example.jp | grep -i spf
dig +short TXT _dmarc.example.jp
# Check that a DKIM selector you use publishes a key
dig +short TXT selector1._domainkey.example.jp

If you integrate with the tracking API

The tracking API for business integrations is still suspended, and Sagawa says it will give business users individual guidance (FAQ Q5-7). In the meantime:

1. Find every integration. Search code, configuration and job schedulers for the carrier's name and endpoints:

grep -rniE "sagawa|hikyaku|飛脚" \
  --include=*.{js,ts,py,php,rb,java,go,cs,yaml,yml,json,env,properties,xml} .
crontab -l 2>/dev/null | grep -i sagawa

2. Make the outage visible, not silent. Polling jobs that fail quietly can leave order pages showing stale status. Add a circuit breaker and show customers a "status unavailable, check the carrier site" message rather than an error.
3. Rotate any credentials used for the integration once Sagawa restores the API, as a precaution. Sagawa has not said that API credentials were affected; ask your account contact rather than assume either way.
4. Do not scrape the web tracking page as a workaround. It was just restored after a security review, and bulk automated lookups are exactly the traffic a carrier will now be watching for.

What consumers should watch for

• Delivery texts. Sagawa says it does not send SMS about pickup or delivery. Delete them.
• Emails that know your address. A message that includes your real name and address is not proof it is genuine, because that is exactly what may have leaked.
• Calls about a parcel. Hang up and call the number on Sagawa's website or the dedicated line, 0120-28-3449.
• Unexpected parcels or bills. The FAQ asks people to be careful with unexpected parcels, invoices or requests.
• Smart Club passwords. They were not included, but if you used the same password elsewhere, change it there (FAQ Q4-3).

Tracking and lookup services as a bulk data surface

Sagawa has not said that the intruder used the tracking page or API to pull data in bulk. The point of this section is not to explain this incident. It is that any service where a short identifier returns personal data is a target, and every team that runs one can check it this week.

Why lookup services are attractive

A tracking page takes a number and returns information about a parcel. If that number is short, numeric or follows a predictable pattern, and if the response includes names, addresses or phone numbers, then the service can in principle be walked through one number at a time. The OWASP API Security Top 10 (2023) covers the three weaknesses that make this possible:

• API1, Broken Object Level Authorization: an endpoint returns an object by ID without checking that the caller is entitled to that object.
• API4, Unrestricted Resource Consumption: no limit, or too high a limit, on how many requests a client can make or how many records a request can return.
• API6, Unrestricted Access to Sensitive Business Flows: a legitimate flow, such as a lookup, can be automated at a scale that harms the business, and nothing distinguishes a person from a script.

A self-review for anyone running a lookup endpoint

1. Minimize the response. Does the public tracking response need full names and addresses? Many carriers show only status, the delivering office and a partly masked recipient. Return the least you can.
2. Require a second factor for detail. Show status to anyone with the number, but require a phone number suffix, a postcode or a login before showing personal fields.
3. Rate limit per client and per identifier range. For example, in nginx:

# 30 lookups per minute per client IP, short burst allowed
limit_req_zone $binary_remote_addr zone=tracking:10m rate=30r/m;

server {
  location /tracking/ {
    limit_req zone=tracking burst=10 nodelay;
    limit_req_status 429;
    proxy_pass http://tracking_backend;
  }
}

Per IP limits are a floor, not a fix, because distributed clients get around them. Combine them with per API key quotas and with detection of sequential lookups. 4. Look for enumeration in your logs. Count distinct identifiers looked up per client per hour. A person tracks a handful of parcels; a script tracks thousands. This example reads a combined format access log and lists the busiest clients by distinct tracking numbers, assuming the number is the last path segment:

awk '$7 ~ /^\/tracking\// {
  n = split($7, p, "/"); id = p[n]; split(id, q, "?");
  key = $1 " " substr($4, 2, 14);   # client IP and hour
  if (!seen[key, q[1]]++) count[key]++
} END { for (k in count) print count[k], k }' access.log \
  | sort -rn | head -20

Then check whether the top clients' identifiers are close to sequential. A short script can flag runs of consecutive numbers:

import sys
ids = sorted(int(x) for x in sys.stdin if x.strip().isdigit())
run = 1
for a, b in zip(ids, ids[1:]):
    run = run + 1 if b - a <= 10 else 1
    if run == 50:
        print(f"sequential run reaching {b}")

5. Scope business API keys. A shipper's API key should return only that shipper's parcels, not any parcel by number. Log which key fetched which object and alert on keys that suddenly read far more than their baseline.
6. Watch the database, not only the edge. Alert on queries that return unusually large row counts from tables holding slip or customer data, and on new database users or connections from unexpected hosts.
7. Keep less. Sagawa's scope ends at about 100 days because that is how long the system kept slip data. Retention limits worked as a ceiling here. Ask whether your lookup service needs personal fields after delivery is complete, or whether they can move to a separate store with tighter access.
8. Know what your service is built from. Keep an SBOM for every image behind the lookup service so that when a framework, web server or library advisory lands, you know within the hour whether you run the affected version.

What changed since the first reports

• From "access restricted" to "external access cut". The 1st report described partial restrictions. The 4th report said all external access to the Internet freight system was blocked from noon on 1 October.
• From "investigating" to a ceiling. The 2nd and 4th reports gave no count. The 5th report gave up to about 53.23 million, with a long explanation of duplicates.
• A clearer date window. "About 100 days back from 30 September" in the 2nd report became 21 June to 30 September in the 5th report, explained as the system's retention period.
• Handwritten slips excluded. This was first stated on 23 October.
• Joint PPC reporting. First set out on 8 and 9 October, and expanded on 23 October to cover shippers who decline or have already filed.
• Web tracking restored. The inquiry page came back on 23 October; the API and booking services did not.

Open questions

• What was the entry method, and was it a software vulnerability, stolen credentials, a logic flaw or something else?
• When did the unauthorized access start, and how long did it run before 07:30 on 30 September?
• How many distinct people are affected once deduplication is finished?
• Were item names or delivery histories exposed?
• Were business API credentials or Smart Club sessions affected?
• When will the tracking API and online booking services return, and with what changes?

What would have helped

The cause is not public, so none of this is a judgement about Sagawa Express. Its notices show several things that worked: fast containment, a retention limit that capped the data window, steady updates and a careful explanation of what the count means. What follows is what any team that holds large volumes of customer contact data can put in place so that an incident is smaller, found sooner and easier to explain.

Practices any team can use

• Treat retention as a security control. The 100 day slip window is the reason the scope is bounded at all. Set retention by purpose, delete on schedule and test that deletion actually happens.
• Separate lookup data from personal data. A tracking page needs status and location. Keep names, addresses and phone numbers in a separate store that the public lookup path cannot read directly.
• Rate limit and baseline every public lookup. Per client, per key and per identifier range, with alerts on unusual volume and on sequential access patterns.
• Scope partner APIs. Every business key should be limited to its own records, logged per object and rotated on a schedule.
• Plan for counting before you need to count. If your data has no stable person identifier, you will face the same deduplication problem Sagawa describes. Decide in advance how you would count people, not rows.
• Prepare joint reporting with your customers. If your business processes personal data on behalf of others, agree in advance how you would notify them and file reports together.
• Know your components. Maintain an SBOM for every service and image so that when a framework or library advisory lands, you can find and rebuild affected services the same day.

Zero-Day Discovery and Gold

Two Safeguard capabilities touch the component part of the 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 a company's hosted web application logic, its API authorization or its credentials, and no package 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 is simple: pull patched, signed components from a curated source, and rebuild and redeploy quickly when a fix lands. That shrinks the window in which a known bug in a web stack can be used, whatever the cause of this particular incident turns out to be.

Where Safeguard fits

Safeguard helps with the component side of a tracking or lookup service:

• SBOM and dependency scanning of repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image tracking-web:latest, safeguard scan --sbom sbom.json, with JSON results under ./output), plus a platform view of which projects contain a given component and version.
• Vulnerability matching against vulnerability databases, with reachability analysis to show which findings sit on code paths you use.
• Policies and gates evaluated in the platform, and autonomous remediation that opens fix PRs (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. You could ask it to add the nginx rate limit above to a repository's config and approve each edit. 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 in progress, block scraping, rate limit your API or prove that your authorization logic is correct. It does not deduplicate customer records, file PPC reports or send notices. It does not stop phishing aimed at your customers. Since the cause of this incident has not been disclosed, we cannot say whether any of the above would have changed the outcome, and we do not claim it would have prevented it.

Common mistakes and troubleshooting

• Reporting 53.23 million as people. It is records with duplicates. Say "up to about 53.23 million records" and add that it is not a head count.
• Mixing this up with the July incident. The July Smart Club email misdelivery affected about 70,000 users and was a configuration error. This is a separate case of unauthorized access.
• Assuming the tracking page was the way in. Sagawa has named the inquiry service as the place it found unauthorized access, but has not said how the access happened or how data was taken.
• Counting parcels in your own PPC report. Shippers should deduplicate to people before reporting, and keep the parcel count separately.
• Waiting for Sagawa before telling customers anything. You can warn customers about fake delivery messages today without knowing whether their record is in the data.
• Rate limiting only by IP. Distributed clients get around it. Add per key quotas and sequential access detection.
• Troubleshooting a broken order status page. If order pages stopped updating on 1 October, the cause is likely the suspended tracking API, not your code. Confirm with your integration logs before you debug.

FAQ

What happened at Sagawa Express?

Sagawa found unauthorized third party access to the system behind its online parcel tracking service at 07:30 on 30 September 2026. It cut external access the next day, suspended nine web services and reported to the PPC. On 23 October it said up to about 53.23 million personal data records may have leaked.

Does 53.23 million mean 53 million people were affected?

No. Sagawa says the figure counts records with duplicates still included, especially in shipping slip data where the same person appears on many slips. It has merged some duplicates and is still working on the rest. It is a maximum, not a count of people or of records confirmed to have leaked.

What data may have leaked?

Names, addresses and phone numbers of senders and recipients on typed slips from 21 June to 30 September 2026; names, addresses and phone numbers of contract customers; and for Smart Club members, also email addresses and member IDs. Card data, passwords and bank details were not included. Item names and delivery histories are still being checked.

I only received a parcel from an online shop. Am I affected?

Possibly. The FAQ says recipients are in scope whether or not they have a Smart Club account, if a parcel was handled in the window with a typed slip. Sagawa says it will contact people in turn, and that the public notice counts as notification for those it cannot reach.

How did the attackers get in?

Sagawa has not said. Its FAQ says the cause is under investigation with an outside specialist firm. Anything else you read about the method is speculation unless it comes from Sagawa.

Is the tracking service safe to use now?

Sagawa restarted web tracking on 23 October after an outside inspection and new security measures, and says it continues to monitor the system. The tracking API and online booking services remain suspended.

What should an online shop that ships with Sagawa do?

Export your shipments for the window, count distinct people, decide whether to join Sagawa's joint PPC report or file your own, warn customers about fake delivery messages and brief your support team. If you use the tracking API, prepare for it to stay offline and rotate credentials when it returns.

Does Sagawa send delivery notices by SMS?

Sagawa says it does not send SMS messages about pickup or delivery. Treat any such text as fake.

Is this the same as Sagawa's July 2026 data leak?

No. Sagawa says the July case, which affected about 70,000 Smart Club users, came from a configuration error during recovery from a system fault, not from unauthorized access.

Would Safeguard have prevented this?

We cannot say, and we do not claim it would. The cause has not been disclosed. Safeguard covers the open source components and container images in a service; it does not detect intrusions, stop scraping or fix authorization logic.

Fix it without waiting for upstream

This incident has no published CVE or affected component, so there is nothing to patch from an advisory today. The habits below are about the next advisory that does land in the web stack behind a tracking or lookup service.

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 Sagawa Express or its systems. Each is a real Safeguard session, and each intro says how the same flow applies to a tracking or lookup service.

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 tracking service, you would run /scan . in the repository behind the lookup endpoint, ask the assistant to upgrade a vulnerable web framework and add the per client rate limit from the self-review above, 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 merchant whose order pages call the carrier's tracking API, you would pick the integration's folder, ask for a circuit breaker and a clear "status unavailable" message, and approve or deny each edit yourself.

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

This real Android session sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. When an advisory lands for a component in your lookup service late at night, the on call engineer could approve the image rebuild from a phone instead of waiting for the morning.

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 other breaches in Japan this month, read our posts on the Japan breach wave involving Yamato, Nikkei and FANCL and the Burger King Japan app breach. 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

• Sagawa Express: Unauthorized access to the parcel inquiry service (1st report, 30 Sep 2026, Japanese)
• Sagawa Express: Possible leak of personal data (2nd report, 1 Oct 2026, Japanese)
• Sagawa Express: Dedicated call centre (3rd report, 1 Oct 2026, Japanese)
• Sagawa Express: Investigation status (4th report, 9 Oct 2026, Japanese)
• Sagawa Express: Service restart and investigation status (5th report, 23 Oct 2026, Japanese)
• Sagawa Express: FAQ on the unauthorized access, updated 23 Oct 2026 (Japanese)
• Sagawa Express: Beware of spam emails impersonating Sagawa (Japanese)
• Nikkei: Sagawa Express personal data may have leaked, up to a cumulative 53 million (23 Oct 2026, Japanese)
• Impress Watch: Sagawa Express personal data leak up to 53.23 million records (23 Oct 2026, Japanese)
• Keitai Watch: Sagawa Express personal data leak up to about 53.23 million (23 Oct 2026, Japanese)
• Business+IT via Yahoo News Japan: up to about 53.23 million records, tracking resumes (Japanese)
• TBS NEWS DIG via Yahoo News Japan: up to about 53.23 million records (Japanese)
• Japan Security Summit Update: Sagawa Express up to about 53.23 million records (Japanese)
• Security Measures Lab: Sagawa parcel inquiry service unauthorized access (Japanese)
• MLex: Japan's Sagawa Express reports data leak affecting 70,000 users (July 2026)
• Personal Information Protection Commission: Responding to leaks (Japanese)
• Personal Information Protection Commission: Mandatory leak reporting and notification (Japanese)
• OWASP API Security Top 10 2023: API1 Broken Object Level Authorization
• OWASP API Security Top 10 2023: API4 Unrestricted Resource Consumption
• OWASP API Security Top 10 2023: API6 Unrestricted Access to Sensitive Business Flows
• Council of Anti-Phishing Japan: phishing alerts (Japanese)

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