Sagawa Express: when a parcel-tracking lookup puts 100 days of delivery data in scope.

What is confirmed

Sagawa Express says a third party gained unauthorised access to the parcel tracking service on its website on 30 September 2026. On 1 October it said customers' personal information may have leaked. Second notice.

Summary card: the article headline beside a shipping label with the sender, recipient and phone fields blacked out

At a glance. Original graphic for this article.

The wording matters. The notice says information may have leaked. It does not say that it did, and it gives no count.

Three groups of people may be affected:

Senders and recipients of parcels Sagawa handled. Name, address and phone number. For companies, the company name and the contact person's name. The notice describes this as cumulative data for about 100 days back from 30 September.
Customers with a freight contract, both companies and individuals. Name, address and phone number, with the same company and contact-person fields.
Registered users of the Smart Club web service. Name, address, phone number, email address and Smart Club member ID.

Matrix of the three groups that may be affected and the data items listed for each. No group has a published count.

Figure 1. Who may be affected, and which items the notice lists. Original graphic for this article.

The notice says credit card information and passwords are not included.

Sagawa stopped nine web services to contain the incident. They include the online tracking lookup, the tracking API, pickup requests and delivery address changes. Pickup and delivery of parcels continue as normal.

The nine stopped web services listed beside the two activities that continue: pickup and delivery of parcels.

Figure 2. The nine stopped web services, and what continues. Service names are translated for this article.

Date (JST)	Event	Source
1 Oct	Third notice: a dedicated call centre opens. Scope and cause are still under investigation.	Third notice
1 Oct	Second notice: personal information may have leaked. Nine web services stopped.	Second notice
30 Sep	First notice: unauthorised access to the tracking service confirmed. Access to the service partly restricted.	First notice

Timeline: parcel data in scope runs from around 22 June to 30 September. Access was confirmed on 30 September and a possible leak announced on 1 October. A separate Smart Club mail error was reported on 18 July.

Figure 3. The data window and the notices. Original graphic for this article.

Sagawa asks customers to watch for suspicious emails, SMS and phone calls in its name. A standing page on its site says the company does not send SMS about pickup or delivery. Sagawa's warning page.

How to read the scope

There is no number yet. The notice says the count and range are under investigation. Treat any figure you see elsewhere as unconfirmed.

“About 100 days” describes the parcel data, not the intrusion. Counting back from 30 September gives a window that opens around 22 June. The notices do not say when the access began or how long it lasted.

Recipients are in scope without being customers. A person who received one parcel has no account with the carrier and may never have visited its site. Their name, address and phone number are listed all the same.

Do not import a cause from secondary coverage. Some summaries state that a vulnerability was exploited through disguised lookup requests, that the flaw was patched, and that the regulator and police were notified. None of that appears in the three notices reviewed here. Sagawa says only that the cause is still being investigated.

Keep the July incident separate. In July, Sagawa reported that Smart Club notification emails had shown other users' details, affecting about 70,000 people. It attributed that to a configuration error during recovery work and said it was not unauthorised access. ITmedia, 18 July. The two events share a service name and nothing else that has been disclosed.

What changes in the security review

Related response guide: use the API data exposure playbook to examine public lookup scope, backend data access, alternate API routes and recovery evidence. This is a workflow connection; Sagawa's notice does not establish broken object authorization or a particular API exploit.

Two reviews follow from this incident. One is for any organisation that runs a public lookup service. The other is for any company that ships with a carrier.

What a public lookup can reach

The access was to a tracking lookup. The data that may have leaked is wider than a tracking status: names, addresses and phone numbers for about 100 days of parcels, plus contract customers and Smart Club members.

Editorial assessment: the notices do not explain how one led to the other, and this article does not guess. The useful point is the gap itself. A lookup screen shows a visitor very little. The service behind it may be able to read far more.

For your own lookup, search and status services, ask four questions:

Which data stores can the service's own account read, and is that wider than what any screen displays?
Is there an API beside the web page, and does it return more fields than the page shows?
How far back does the data go, and what decides that period?
Can you stop the lookup alone, or does stopping it take order intake and changes down with it?

The fourth question is not hypothetical. Sagawa stopped nine services, including pickup requests and delivery address changes, while collection and delivery carried on. That is containment by service. It only works if the services can be separated when it matters.

Your customers inside a carrier's breach

If your company ships with Sagawa, two sets of your data may be in scope. One is the contract record: company name, contact person, address and phone number. The other is every recipient you shipped to in the window, which means your customers.

Editorial assessment: a message that uses the right name and address, sent to someone who did receive a parcel recently, is far more convincing than a generic one. Fake delivery notices in Sagawa's name are an old lure. Sagawa's own warning page lists dozens of examples, including fake missed-delivery SMS.

For a company that ships with the carrier:

Ask your Sagawa contact whether your contract account and your shipments in the window are in scope.
Check anything that calls the tracking API or the web pickup service. Those are stopped, so order pages and customer emails may show errors or dead links.
Decide what you will tell customers, and wait for confirmed scope before you state that their data leaked.
Brief customer support. Customers will ask whether a delivery message is real.
Tell staff who receive parcels at work. The contact person on a company delivery is in the listed data.

SMS and phone calls bypass your mail gateway. For your customers, the only control you have is a clear statement of how you and your carrier do and do not contact them.

Which teams should act

Team	Practical next step
Third-party risk	List the carriers and logistics providers that hold your customers' delivery data. Ask Sagawa whether your account and shipments are in scope, and how long lookup data is kept.
IT operations	Find every integration that calls the Sagawa tracking API or web pickup service and plan a manual fallback. Inventory your own public lookup services against the four questions above.
Legal / privacy	Map which customer and staff data you passed to the carrier. Have counsel assess any duty toward those people once scope is confirmed. Prepare customer wording now.
Email security	Review inbound mail that uses the Sagawa name from other domains. Tighten impersonation rules for delivery brands.
SIEM / SOC	Run the hunts below for lookalike domains and mail. Expect no IOCs from the carrier at this stage.
EDR	Watch for payloads delivered through fake delivery pages on managed devices. Phones outside management are a blind spot to state, not to ignore.

IOCs and hunting

The notices reviewed contain no attacker IP, domain, hash or technique. There are no incident IOCs in this article, and none should be inferred.

What a company can hunt for is the follow-on: fake delivery messages and the lookalike sites they point to. Sagawa's warning page shows fake sites on hosts that contain “sagawa” but sit outside its own domain. The three queries below look for that pattern. They are illustrative and were not run against live data.

Inbound mail that uses the Sagawa name from another domain:

// Illustrative. Microsoft Defender XDR advanced hunting, EmailEvents table.
// In Microsoft Sentinel, replace Timestamp with TimeGenerated.
// sagawa-exp.co.jp is the domain of the carrier's public website.
// Confirm its real sending domains before relying on this filter.
EmailEvents
| where Timestamp >= datetime(2026-09-30)
| where EmailDirection == "Inbound"
| where Subject contains "佐川" or Subject contains "sagawa"
    or SenderDisplayName contains "佐川" or SenderDisplayName contains "sagawa"
| extend SenderDomain = tolower(SenderFromDomain)
| where SenderDomain != "sagawa-exp.co.jp"
    and not(SenderDomain endswith ".sagawa-exp.co.jp")
| project Timestamp, SenderFromAddress, SenderDisplayName, Subject,
          RecipientEmailAddress, DeliveryAction, ThreatTypes

Managed devices that connected to a host with “sagawa” in its name, outside the carrier's domain:

// Illustrative. Microsoft Defender XDR advanced hunting, DeviceNetworkEvents table.
DeviceNetworkEvents
| where Timestamp >= datetime(2026-09-30)
| where isnotempty(RemoteUrl) and RemoteUrl contains "sagawa"
| extend ParsedHost = tostring(parse_url(RemoteUrl).Host)
| extend Host = tolower(iff(isempty(ParsedHost), RemoteUrl, ParsedHost))
| where Host != "sagawa-exp.co.jp" and not(Host endswith ".sagawa-exp.co.jp")
| summarize Connections = count(), FirstSeen = min(Timestamp), LastSeen = max(Timestamp)
          by DeviceName, Host

The same idea for DNS requests in CrowdStrike Falcon:

// Illustrative. CrowdStrike Falcon LogScale, DnsRequest events.
// These events carry the sensor ID (aid), not the host name.
// Map aid to your host inventory before triage.
#event_simpleName=DnsRequest
| DomainName=/sagawa/i
| DomainName!=/(^|\.)sagawa-exp\.co\.jp$/i
| groupBy([aid, DomainName], function=[count(as=Requests),
          min(@timestamp, as=FirstSeen), max(@timestamp, as=LastSeen)])

Read the results with three limits in mind:

A hit is a lead, not a verdict. Unrelated businesses and legitimate partner sites can carry the same name.
News coverage and newsletters about the incident will match the mail query. Exclude them after you have looked at them.
Fake delivery SMS that reach personal phones appear in none of these tables.

What remains unknown

Sagawa says it is still investigating the scope and the cause. As of the cut-off below, the notices leave these points open:

How many people. No count for any of the three groups.
Whether data left. The notices say information may have leaked. They do not confirm that it did.
Method and entry point. Not described.
Start and duration of the access. Only the date the access was confirmed is given.
Why the tracking service could reach this data. The link between a tracking lookup and contract or member records is not explained.
Individual notification. The notices do not say whether or how affected people will be told.
Service restoration. No date for the nine stopped services.
Regulator and police reporting. Not mentioned in the three notices.

Revisit this article when the next notice appears. A confirmed count or a stated cause would change the assessment above.

Reporting note

Reviewed for public information up to 2 October 2026, 03:36 UTC / 12:36 JST. Sagawa's notice list showed no update after the third notice at that time. Facts about this incident come from Sagawa's three notices. The July incident is described from ITmedia's report; Sagawa's own July notice was no longer available at the address that report links to.

Two secondary write-ups were read as leads: Security Taisaku Lab and a general news blog. Where either goes beyond the notices, this article follows the notices.

This is independent editorial analysis of public statements. It is not an investigation conducted by SecOpsNomad, and it makes no claim about how the access happened.

Sources

16 October 2026: added a link to the reusable API data exposure response guide; the incident's factual findings and uncertainties are unchanged.

30-second briefing