Lawson ID Breach: 2.15M Records via an App Display Mechanism

Lawson says a third party accessed the security mechanism that shows each user their own information in the Lawson app, exposing 2,155,345 LAWSON ID records in September 2026. Names leaked and birth dates may have; email addresses did not, after a 24 October correction. Users should expect targeted scams; app teams should test per user authorisation.

Lawson, Inc. (株式会社ローソン) runs one of Japan's largest convenience store chains, and LAWSON ID is the account behind its apps and web services. This post works from Lawson's own notice of 8 October 2026 and its updates of 13, 19 and 24 October, translated from Japanese as closely as we can, plus Lawson's separate 1 October notice about its mail server. Lawson has not named the technique the attacker used. We describe the pattern its wording points to in general terms, label that clearly as general, and do not claim it is what happened at Lawson.

What happened

According to Lawson's notice, an investigation carried out on Wednesday 7 October 2026 established that a third party had made unauthorised access to LAWSON ID between Saturday 12 September and Monday 14 September, and to Lawson App Reservations (ローソンアプリ予約) on Thursday 17 September. Lawson published the notice the next day. It says it confirmed that there was no other unauthorised access and no malware infection.

Lawson describes LAWSON ID as "the account service for using Lawson's apps and web services", and Lawson App Reservations as a service for reserving and paying in advance, from the official Lawson app, for seasonal event goods. The notice also says that, at the time of writing, no misuse or secondary harm caused by the incident had been confirmed.

Timeline

The mail server incident, and why we call it timing only

On 1 October Lawson said a third party had used its mail server to send an estimated 700,000 suspicious English emails between 25 and 27 September (details in Technical details below). It said it had found no leak of personal information, no intrusion into its data centre, no data tampering and no malware infection.

That notice came out before Lawson found the LAWSON ID access. Neither notice says the two events are connected. Innovatopia's editorial analysis makes the same point: nothing published says the same attacker was behind both. The overlap is timing only, and this post treats it that way.

What Lawson said about the cause

The cause section of the notice is two sentences. We translate them as literally as we can, because every word matters here.

本件は、ローソンアプリに関連するシステムが不正に利用されたことにより発生したものと考えられます。

"This incident is thought to have occurred because a system related to the Lawson app was used without authorisation."

本来、アプリ上で利用者本人に対し情報を表示するためのセキュリティ機構が第三者による不正アクセスを受け、情報漏えいしたことを確認しております。

"We have confirmed that a security mechanism whose original purpose is to display information to the user themself on the app was subjected to unauthorised access by a third party, and that information leaked."

Three phrases carry the meaning. 本来 (honrai) means "originally" or "by its proper design", signalling use for something other than its purpose. 利用者本人に対し means "to the user in person", the account holder rather than anyone else. セキュリティ機構 is "security mechanism". Lawson does not say whether that mechanism is an API, a token service, a session system or something else, or how it was accessed.

What is still unknown

Lawson has not published, and we do not know:

• The technique used, or whether a software flaw, a configuration issue or stolen credentials were involved.
• Whether a specific product, library or vendor was involved. No CVE has been referenced.
• Who the third party was, or whether any group has claimed the incident.
• How many requests were made, from which networks, or how the access was discovered.
• Whether passwords, Ponta or d POINT data were touched. These do not appear in the list of leaked items, and the notice says nothing either way.

The numbers and data fields, exactly as published

Lawson publishes the figures as 件 (ken), which means records or cases, and calls the line 対象人数, the number of people concerned. We quote the figures as published.

The 24 October correction, word for word

The notice keeps the original list visible and marks it up. On the live page, "email address" and the newsletter item are shown struck through, and "date of birth" is underlined as an addition. The note beneath reads, in our translation:

"Added 24 October 2026: after further detailed investigation, it was found that 'email address' and 'newsletter acquisition information' had not been leaked, and that 'date of birth' may have been leaked, so we have corrected the list as shown above."

メルマガ取得情報 literally means "mail magazine acquisition information", which in context means whether, and how, the member signed up for Lawson's email newsletter. We render it as newsletter opt in information.

The wording of the correction is careful. Email address and newsletter data are now stated as not leaked. Date of birth is stated as possibly leaked (漏えいの可能性), which is weaker than the confirmed wording used for the other fields.

Why the correction matters for readers

Nikkei on 8 October and Impress Watch on 9 October listed email addresses among the leaked data, and Innovatopia's phishing advice assumed names and emails had leaked together. Those reports matched the notice at the time. Since 24 October the official position is:

• Email address: not leaked, according to Lawson.
• Date of birth: may have leaked.
• Gender, phone number, address: leaked where the member had entered them, for example for a prize entry.

For the 2.15 million affected members, that changes the likely scam channel. Phone numbers and postal addresses point toward SMS, calls and post rather than email. Lawson's own advice already covered all three: be careful with suspicious emails, SMS and phone calls to the contact details registered with LAWSON ID.

Technical details

This section collects every defender useful specific Lawson and the related primary notices have published. There is no CVE, no affected product version, no file hash and no network indicator in any of them. Where a value below is an indicator, it is an official sender address or a published subject line, not attacker infrastructure.

Systems in scope

What a LAWSON ID can hold

Lawson's LAWSON ID page says registration requires only an email address and a password. Depending on the service used, a member may also be asked for name, postal code, prefecture, address, phone number, date of birth, and a Ponta member ID or d POINT card number. The page says a member can link a Ponta member ID or d POINT card number to LAWSON ID for point lookups and campaigns, and that linking a card is allowed once a day.

Password, Ponta member ID, d POINT card number and postal code are not in the notice's list. We cannot say whether they were reachable, only that they are not listed.

Dates and dwell time

These are calendar differences between the dates in Lawson's notice; Innovatopia gives the same ranges.

Containment, as listed

Lawson lists these actions after discovery:

1. Blocking suspicious access sources (不審なアクセス元のブロック).
2. Suspending the Lawson App Reservations function. It was resumed on 19 October.
3. Posting a notice to customers inside the Lawson app.
4. Contacting affected customers individually, in sequence, by email from the official addresses below.
5. Contacting and reporting to the relevant bodies, including the Personal Information Protection Commission (個人情報保護委員会).

The 19 October update adds that from 19 October users must update the Lawson app to keep using it. Lawson has not said what changed in that release. A mandatory update is one of the few levers a company has to retire an old client that behaves in a way the server should no longer accept, but we do not know that this was the reason here.

Prevention measures, as listed

Lawson's three stated measures, translated:

1. Strengthen security measures for the target system.
2. Strengthen the monitoring system for the target system.
3. Strengthen the incident response system.

Official sender addresses

These are the addresses Lawson says it uses for its individual notices. The second was added on 13 October.

A message that shows one of these addresses is not proof that it is genuine. Lawson's own 1 October notice says spoofed sender displays were seen in the mail server incident. Check authentication results (SPF, DKIM and DMARC alignment for lawson.jp) in the full headers, and go to the official app or site directly rather than following a link.

Published details of the 1 October mail server incident

Mail teams that saw inbound messages with those subjects in that window can tag them in their own records. Lawson has not linked this event to LAWSON ID.

Regulatory context in Japan

The Personal Information Protection Commission's guidance on breach reporting says a business should report promptly once it discovers a reportable leak. Reports are required in four situations: leaks involving special care personal information, leaks that could cause financial harm if misused, leaks that may have resulted from an act done with an improper purpose (unauthorised access is the commission's first example), and leaks involving more than 1,000 people. Where an improper purpose is possible, the commission's page gives 60 days from discovery for the report. The same page notes that the last four digits of a card number combined with the expiry date do not by themselves make a case reportable under the financial harm category. Lawson does not say which part of the card number was exposed in the 26 reservation records, and we do not guess.

On the facts Lawson has published, its case appears to fall under at least the improper purpose and over 1,000 people categories, and Lawson says it has reported to the commission.

What the "display to the user" mechanism usually is

Everything in this section is general. It explains the kind of component Lawson's wording describes and the weaknesses that commonly affect such components. It is not a finding about Lawson.

The pattern in plain language

A loyalty app shows you your own profile: name, birthday, address, points. The app asks a server for that data, usually through an API call, and a check on the server decides whose record to return. Innovatopia's editorial describes this flow, then states plainly that Lawson's announcement does not show whether its case fits the pattern.

That check is the security mechanism. It typically does two jobs:

1. Authentication: is this request really from a logged in user? That usually means a session cookie, an access token or a signed token issued at login.
2. Authorisation: is this user allowed to see the record being asked for? For a "show me my profile" call, the only correct answer is the caller's own record.

If either job is done weakly, the endpoint built to show one person their own data can be made to show other people's data. Because the endpoint is designed to return exactly the fields a profile screen needs, those fields are what leaks: name, birthday, contact details. That matches the shape of the field list in Lawson's notice, but a matching shape is not evidence of the cause.

Where the OWASP API Security Top 10 puts this

The OWASP API Security Top 10 (2023 edition) lists the weaknesses most often behind incidents like this. Four are relevant to any team running a profile or account API.

OWASP rates API1 as "Exploitability Easy" and "Prevalence Widespread", and explains that it is common because servers often rely on identifiers sent by the client to decide which object to return. OWASP also warns that simply comparing a user ID in the session token with an ID parameter only fixes "a small subset of cases". The durable fix is an authorisation layer that every data access passes through.

Why a mobile app makes this an internet facing API

A mobile app is a public client. Anyone can install it, watch its traffic and replay requests, so the endpoints behind a profile screen are internet facing APIs whether or not they are documented. Their security has to live on the server; anything the app enforces on the device is a convenience, not a control.

How this connects to the software supply chain

Account APIs are rarely written from scratch. They sit on web frameworks, authentication libraries, token libraries, API gateways and container base images. A flaw in any of those can weaken authentication or authorisation for every endpoint built on them, which is why the dependency inventory behind your account service matters. Equally, many authorisation failures are in a team's own handler code, where no upstream patch will ever arrive. Both need attention, and the second is where most of the work below sits.

Who is affected

What to do now

If you have a LAWSON ID

1. Treat unexpected calls, SMS and letters that mention your Lawson account with suspicion. With name, phone number, address and possibly birth date in play, a scammer can sound well informed.
2. Check sender details on any email about the incident. Lawson lists lawson_id@mailservice.lawson.jp and lawson_id@id.lawson.jp. A display name alone proves nothing.
3. Go to the app or site directly, and update the Lawson app, which Lawson says is required from 19 October.
4. If you used Lawson App Reservations, check your card statements, and call your card issuer using the number on the back of the card if anything is unfamiliar.
5. Use Lawson's dedicated inquiry form for questions about the incident.
6. Change your LAWSON ID password if you reuse it elsewhere. Lawson has not listed passwords as leaked, so this is general hygiene, not a response to a stated leak. Lawson's own LAWSON ID page asks members not to use names, birth dates or phone numbers in passwords, and not to reuse passwords from other sites.

If you run a consumer app with an account API

These steps are for systems you own and are authorised to test. Run tests against staging or with accounts you control.

1. Inventory every endpoint that returns personal data.

Start from the code, not the documentation, because undocumented mobile endpoints are the ones most often missed.

# Express or Fastify style routes
grep -rnE "\.(get|post|put|patch)\(['\"]/(api/)?(v[0-9]+/)?(me|profile|member|user|account)" src/

# Spring
grep -rnE "@(Get|Post|Put)Mapping\(.*(me|profile|member|user|account)" src/main/java

# Django / DRF
grep -rnE "path\(['\"].*(me|profile|member|user|account)" */urls.py

# OpenAPI specs, if you have them
yq '.paths | keys | .[]' openapi.yaml | grep -Ei "me|profile|member|user|account"

2. Find handlers that take an identifier from the client.

A profile endpoint should not need one. If the handler reads a member ID from the path, query string, body or a custom header, flag it for review.

grep -rnE "req\.(params|query|body)\.(memberId|userId|accountId|id)" src/
grep -rnE "request\.(GET|POST|data)\.get\(['\"](member_id|user_id|account_id)" .
grep -rnE "@(PathVariable|RequestParam).*(memberId|userId|accountId)" src/main/java

The fix pattern is to derive the subject from the verified session or token on the server, and to ignore any identifier the client supplies for "my" data.

3. Write two account authorisation tests and make them block deploys.

OWASP's API1 guidance is to write tests for the authorisation mechanism and not to deploy changes that make them fail. A minimal version uses two test accounts you control: log in as A, try to read B's record by every route that accepts an identifier, and expect a refusal.

# tests/test_profile_authz.py  (pytest, against staging with two test accounts)
import os, requests

BASE = os.environ["STAGING_API"]

def login(user, pw):
    r = requests.post(f"{BASE}/auth/login", json={"user": user, "password": pw}, timeout=10)
    r.raise_for_status()
    return r.json()["access_token"]

def test_profile_returns_only_caller():
    tok_a = login(os.environ["TEST_USER_A"], os.environ["TEST_PASS_A"])
    me = requests.get(f"{BASE}/me", headers={"Authorization": f"Bearer {tok_a}"}, timeout=10).json()
    assert me["member_id"] == os.environ["TEST_ID_A"]

def test_cannot_read_other_member():
    tok_a = login(os.environ["TEST_USER_A"], os.environ["TEST_PASS_A"])
    other = os.environ["TEST_ID_B"]
    r = requests.get(f"{BASE}/members/{other}", headers={"Authorization": f"Bearer {tok_a}"}, timeout=10)
    assert r.status_code in (403, 404)

Run it in CI on every merge to the account service, and add a case for every new route that returns member data.

4. Return only the fields the screen needs.

OWASP API3 advises against generic serialisers. If a profile screen shows name and points, the response should not carry birth date and address just because the model has them. Define a response schema and validate against it in tests.

5. Rate limit the profile endpoint per account and per client.

A real user reads their own profile a handful of times a day. Limits tuned to that make bulk reading slow and noisy. An nginx example for a gateway in front of the account service:

# per access token, falling back to client address
map $http_authorization $limit_key {
    default $http_authorization;
    ""      $binary_remote_addr;
}
limit_req_zone $limit_key zone=profile:20m rate=30r/m;

location /api/v1/me {
    limit_req zone=profile burst=10 nodelay;
    limit_req_status 429;
    proxy_pass http://account_service;
}

6. Alert on the ratio, not just the volume.

The signal that matters for this pattern is one client reading many distinct member records. If your access logs are JSON, a quick check:

# distinct member IDs requested per token per hour, top offenders
jq -r 'select(.path|test("^/api/v[0-9]+/(members|profile)")) |
       [.token_hash, (.ts[0:13]), .member_id] | @tsv' access.log \
 | sort -u | cut -f1,2 | sort | uniq -c | sort -rn | head -20

In SQL against a log table:

SELECT token_hash,
       date_trunc('hour', ts)       AS hour,
       count(DISTINCT member_id)    AS distinct_members,
       count(*)                     AS requests
FROM api_access_log
WHERE path LIKE '/api/v1/members/%' OR path = '/api/v1/me'
GROUP BY 1, 2
HAVING count(DISTINCT member_id) > 1
ORDER BY distinct_members DESC
LIMIT 50;

For a "my profile" endpoint, any token reading more than one member is worth a look. Wire the query into whatever alerting you already run, so that a three day burst does not wait three weeks to be noticed.

7. Check token validation on the server.

Confirm that the account service verifies signature, issuer, audience and expiry on every request, rejects unsigned tokens, and does not accept a token issued for another client or service. Confirm that refresh and recovery flows are rate limited, as OWASP API2 recommends.

8. Plan how you would force an app update.

Lawson required an app update from 19 October. Your server should be able to reject requests from client versions you no longer trust, with a clear message telling the user to update. Build and test that switch before you need it.

9. Inventory the libraries under your account service.

Know which web framework, authentication and token libraries, gateway and base image versions the service runs, so that if an advisory lands for one of them you can tell within minutes whether you are exposed.

safeguard scan --dir services/account          # the account service repository
safeguard scan --image registry.example.com/account-api:prod

Prepare your own breach notice before you need it

Lawson's notice covers dates, systems, counts, fields, cause, actions, prevention, sender addresses and an inquiry form. Two habits are worth copying: it added a second sender address as soon as it mattered, and it corrected the data list in place, striking old items through rather than deleting them, so readers could see exactly what changed.

What changed since first reports

The count of 2,155,345 has not changed in any update.

Open questions

• What exactly was the "security mechanism", and how was it accessed?
• Did the third party need a valid LAWSON ID login of its own?
• How was the access discovered on 7 October, about three weeks after it happened?
• Why did the field list change on 24 October? Lawson says only that further detailed investigation found it.
• Which part of the card number was exposed for the 26 reservation records?
• What changed in the app release required from 19 October?
• Is there any link between the September mail server misuse and the LAWSON ID access? Nothing published says so.

Wider context, timing only

Several Japanese consumer apps disclosed incidents within days of each other. On 29 September, Seicomart said a third party had reached a server holding member information by way of the Seicomart app's server, and Japan Post and Japan Post Co. announced unauthorised access to the Post Office app the same day. Impress Watch's 9 October roundup put Lawson alongside skyticket, Daiichikosho, BOOKOFF and NewsPicks. None of these companies has said the incidents are connected, and the link here is timing only. For more of this month's Japanese cases, see Japan's October breach wave, Burger King Japan's breach and the Capcom ID breach.

What would have helped

None of this is a judgement on Lawson. It found the access, blocked it, suspended a function, reported to the regulator, published counts and fields the next day, added sender addresses, required an app update and corrected its own notice in public. The useful question for everyone else is how to make this class of event smaller and shorter.

Practices any team can use

• Treat every API behind a public app as a public API. Authenticate and authorise every request on the server, and assume the client can be replaced.
• Derive "who am I" from the verified session, never from the request. A profile endpoint should not accept a member identifier at all.
• Centralise authorisation. One policy layer that every data access passes through is easier to test and review than checks scattered across handlers.
• Test authorisation with two accounts in CI. Block the deploy when a cross account read succeeds.
• Return the minimum. A profile screen that shows points does not need an address in the response.
• Rate limit per token and per client, and alarm on distinct records read per token. A burst over three days should page someone within hours.
• Know what sits under the account service. Framework, authentication library, token library, gateway and base image versions should be one query away, and rebuilds should be fast when a fix ships.
• Collect fewer optional fields, and age them out. Gender, phone and address appear in this notice because members entered them for prize entries.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists, in two modes, an agentic mode and a deterministic scanner mode. Its findings are issued as SGZ advisories before they reach public CVE databases, and it covers seven package ecosystems. Gold Open Source (gold.safeguard.sh, free, no login) is 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 (registry.safeguard.sh, paid) supplies hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher and Sigstore signed, with evidence pages; an artifact loses its badge if it regresses.

The limits are important here. Lawson has not said that any open source component or known vulnerability was involved, there is no CVE, and Safeguard has no advisory and no patched build related to this incident. If the weakness was in first party authorisation logic, as Lawson's wording leaves open, no package advisory would ever cover it. These capabilities help in the shared layer that account services are built on, the frameworks, authentication and token libraries and base images, where pulling patched, signed components and rebuilding fast removes one common way in.

Where Safeguard fits

Safeguard would not have prevented this incident, and we do not claim it would have detected it. It does not monitor production traffic, rate limit APIs or alert on unusual read patterns. What it covers, at GA:

• Dependency and image scanning of the repositories, container images and SBOM files behind an account service, with JSON results under ./output.
• Component search across projects, showing every project that contains a given component and version when an advisory lands for an authentication or token library.
• Vulnerability matching and reachability analysis, ranking the vulnerable code paths your application actually calls.
• Policies and gates, so a build carrying a known exploited vulnerability can be blocked or held for approval.
• Autonomous remediation with tested fix pull requests, off by default.
• The Safeguard CLI assistant, which edits code and runs commands only with your approval, under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. You could ask it to add the two account authorisation tests above to your account service, or to replace a handler that reads a member ID from the request with one that uses the session subject, and approve each edit and test run.

safeguard scan --dir .                 # a repository
safeguard scan --image <name>          # a container image
safeguard scan --sbom <file>           # an SBOM file

Safeguard also has first party DAST, in early access, for targets you have verified you own. We make no claim that it would have flagged the weakness behind this incident, which Lawson has not described; the two account tests above are the direct check.

Common mistakes and troubleshooting

• Hiding fields in the app instead of the API. If the response carries the birth date, anyone reading the traffic has it, whatever the screen shows.
• Checking authentication but not ownership. A valid token proves who is calling, not which record they may read.
• Rate limiting only by client address. Bulk reads can be spread across many addresses; limit per token and per account too.
• Alerting on request volume alone. A careful client can stay under a volume threshold. Distinct records per token is the better signal for a profile endpoint.
• Testing authorisation once, by hand. New routes arrive every sprint. Put the two account test in CI.
• Treating the first notice as final. Lawson's own list changed after 16 days. Plan for corrections, and keep the original visible when you make them.

FAQ

What happened at Lawson?

Lawson says a third party made unauthorised access to its LAWSON ID account service from 12 to 14 September 2026 and to Lawson App Reservations on 17 September, through a security mechanism designed to show users their own information in the app. It found the access on 7 October and disclosed it on 8 October.

How many people are affected?

Lawson gives 2,155,345 for LAWSON ID and 26 for Lawson App Reservations, counted in 件 (records). The figure has not changed in any update.

Were email addresses leaked?

No, according to Lawson's 24 October correction. The original list included email addresses and newsletter data; further investigation found they were not leaked. Earlier press reports that list email addresses reflect the first version of the notice.

Was my date of birth leaked?

Possibly. Lawson's 24 October update added date of birth as information that may have leaked. It uses weaker wording for it than for the confirmed fields.

Were passwords or point card data stolen?

Lawson's notice does not list passwords, Ponta or d POINT data among the leaked items, and says nothing else about them. We cannot say more than that.

Were credit card numbers stolen?

For 26 Lawson App Reservations records, part of the credit card number leaked, along with name and phone number. Lawson does not say which part. No card data is listed for LAWSON ID.

How did the attacker get in?

Lawson has not said. It describes a system related to the app being used without authorisation, and a mechanism meant to show users their own data being accessed by a third party. Patterns such as broken object level authorisation fit that description in general, but Lawson has not named a technique, so we do not.

Is this connected to the spam sent from Lawson's mail server?

Nothing published says so. Lawson's mail server sent an estimated 700,000 suspicious English emails between 25 and 27 September, after the LAWSON ID access and before its discovery. Neither notice links the two. The overlap is timing only.

Would Safeguard have prevented this?

No. Safeguard does not monitor API traffic or enforce authorisation in production. It helps teams inventory and patch the components under an account service, and its CLI assistant can help write and run authorisation tests with your approval.

Fix it without waiting for upstream

Lawson has not tied this incident to any open source component, and authorisation bugs in your own handlers have no upstream at all. For the frameworks, authentication libraries and images your account service is built on, though, the patch clock is in your hands.

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 Lawson or its systems. Each is a real Safeguard session, and below each one we explain how the same flow applies to a team running an app with an account API.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For an account service, you would run /scan . in its repository, then ask the assistant to add a two account authorisation test for every route that returns member data, approving each file edit and each test run.

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. A team could pick the folder holding its API gateway configuration, ask for a per token rate limit on the profile route, and approve or deny each change before it lands.

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. If an advisory lands at night for the token library your login API uses, the on call engineer could approve the dependency bump and test run from a phone, and deny anything that touches production data until a second person has looked.

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, read October 2026 security incidents and what would have helped, and for finding affected services fast, SBOM incident response.

Quick check

Sources

• Lawson: notice of personal information leak due to unauthorised access (8 Oct 2026, updated 13, 19 and 24 Oct)
• Lawson: suspicious email sent through misuse of our mail server (1 Oct 2026)
• Lawson: what is LAWSON ID
• Lawson customer center inquiry form
• Personal Information Protection Commission: breach reporting
• Seicomart: second notice on unauthorised access to the Seicomart app (29 Sep 2026, PDF)
• Japan Post: unauthorised access to the Post Office app (29 Sep 2026)
• OWASP API Security Top 10 2023
• OWASP API1:2023 Broken Object Level Authorization
• OWASP API2:2023 Broken Authentication
• OWASP API3:2023 Broken Object Property Level Authorization
• OWASP API4:2023 Unrestricted Resource Consumption
• Nikkei: Lawson unauthorised access, about 2.15 million personal records leaked (8 Oct 2026)
• Nikkei: running list of companies disclosing personal data leaks
• Impress Watch: leaks continue at Lawson, skyticket, Daiichikosho and others (9 Oct 2026)
• ScanNetSecurity: unauthorised access to Lawson's account service, 2,155,345 LAWSON IDs leaked (13 Oct 2026)
• Innovatopia: unauthorised access to LAWSON ID, 2.15 million records leaked (9 Oct 2026)

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