Keystone Wallet Store Breach: Shipping Data, Phishing and Shopify Apps

Keystone, the air-gapped hardware wallet maker, says a third party obtained customer shipping information from its Shopify-based online store. Names, contact details, addresses and order items and prices were exposed; recovery phrases, private keys, passwords and card data were not. Buyers should expect targeted scams. Merchants should audit store apps, scopes and API tokens.

This post works from Keystone's own statement on X, published on 24 October 2026, Shopify's developer and help documentation, and Ledger's 2020 breach notices as the closest precedent. Keystone has said a detailed report is coming. Until it is published, nobody outside the company knows which app, token or account made the API calls, or how many customers are affected, and we do not guess at either. Where this post describes how Shopify store integrations generally work, it says so, and it does not claim that is what happened at Keystone.

What happened

In a post on X headed "We owe you an apology", Keystone said it detected unauthorized access to its official website on 20 October 2026. It then reviewed API activity together with Shopify, the commerce platform that runs its store, and on 23 October confirmed that a third party had obtained customer shipping information. It published the apology on 24 October.

Keystone listed what was exposed: names, contact details, shipping addresses, and order details, which it describes as items and prices. It listed separately what was not exposed: payment card or bank details, recovery phrases, private keys, and wallet passwords. It says it has blocked the access, fixed the vulnerability, opened an investigation and started emailing affected customers.

The statement spends most of its length on scams. Keystone warns that criminals may pose as the company by phone, text, email or post, offering refunds, replacement devices, or "fixes" for an order or address, and it says none of that will come from Keystone. It tells customers never to share a recovery phrase or private keys, never to enter a recovery phrase into a device they did not order, not to click links in unexpected messages, and to type keyst.one into the browser themselves. It gives support@keyst.one as the contact for anything that feels wrong.

Timeline

The 25 October date in some Chinese-language coverage is not a contradiction. Keystone's post went up at 17:59 UTC on 24 October, which was 01:59 on 25 October in Hong Kong, where Keystone is based according to Crypto Briefing.

What Keystone has not said yet

Keystone's statement is careful and short. It leaves out several things that a reader will want to know, and that we will not fill in:

• How many customers are affected. No figure has been published by Keystone, and none of the outlets we read gives one.
• How the access happened. Keystone says it "fixed the vulnerability" but does not say what the vulnerability was. It does not say whether a third-party app, a custom app token, a staff or collaborator account, or something else made the API calls.
• The time window. Keystone gives the detection date, 20 October, but not when the access began, so we do not know how far back the exposed orders go.
• The exact contact fields. Keystone says "contact details". Coin Edition lists phone numbers among the exposed data; the other outlets and Keystone's own post do not specify. We treat phone numbers as possible, not confirmed.
• Regulatory filings. Keystone has not said which data protection authorities it has notified.

Why "only shipping data" is not small for a hardware wallet buyer

For most online shops, a leak of names and addresses is a privacy problem and a phishing problem. For a hardware wallet seller it is more than that, because the order line items do something an ordinary address list does not: they mark each person as someone who bought a device to hold cryptocurrency, and often say which model and how many.

That combination creates three distinct risks.

Targeted phishing that sounds real. A scammer who knows your name, your address, the exact device you ordered and the price you paid can write an email, text or letter that is very hard to tell apart from a genuine one. Keystone's warning lists the pretexts it expects: refunds, replacement devices and order or address "fixes". All of them end in the same place, which is an attempt to get a recovery phrase typed into something the attacker controls.

Fake parcels. A postal address plus device model makes it possible to mail a "replacement" device or a letter with a QR code to the right person. Keystone's specific line, never enter a recovery phrase into a device you did not order, is aimed at exactly this. A device that arrives unrequested should be treated as hostile, however convincing the packaging.

Physical risk. A list of people who own self-custody wallets, with home addresses, has value to criminals beyond the internet. After its own 2020 breach, Ledger's chief executive advised customers to review home security if they keep significant value at home and not to keep their recovery sheet at home. That advice applies to anyone whose address appears in a wallet maker's order data.

What the leak does not do, according to Keystone, is expose recovery phrases or private keys. Keystone's devices are air-gapped and sign transactions over QR codes rather than USB, Bluetooth or Wi-Fi, according to Crypto Briefing's description, so an online store is not where wallet keys live. The danger is in what a criminal can persuade an owner to do.

Technical details

Keystone has not published technical indicators. There are no hashes, domains, IP addresses or CVE IDs for this incident, and we do not invent any. What follows is the full set of verifiable specifics: the exact wording and metadata of Keystone's disclosure, and the documented mechanics of the Shopify integration layer that Keystone's wording points to.

The disclosure itself

What "API activity with Shopify" tells us, and what it does not

Shopify stores expose their data to apps through the Admin API. Every app installed on a store, whether a public app from the Shopify App Store, a custom app built for one merchant, or a legacy admin-created custom app, gets an access token tied to a set of access scopes the merchant approved at install. Requests carrying that token can read whatever those scopes allow.

Keystone's wording, that it confirmed the data theft by verifying API activity, fits the pattern of data being read through the Admin API rather than, for example, a database being copied from Keystone's own servers. But Keystone has not named the app, token or account that made the calls, and API activity can come from several sources: a third-party app, a custom app's token, or a staff or collaborator session acting through an app. We describe the controls for all of them below, without suggesting which one applied.

Shopify access scopes that reach order and customer data

These are the scopes, as documented by Shopify, that govern access to the kind of data Keystone listed:

Two details matter for a merchant reviewing its own store. First, the 60 day default on orders is a real limit: an app with read_orders alone cannot read older orders, so the presence of read_all_orders on any installed app is worth a specific look. Second, Shopify notes that apps created in the Dev Dashboard under a merchant organization do not need approval for read_all_orders, while Partner apps do.

Protected customer data levels

Shopify classifies customer data into levels and, by default, gives apps no access to protected customer data at all. An app must meet Shopify's requirements and, for non-development stores, be approved before the API returns those fields.

Every category Keystone listed, names, contact details and shipping addresses, is Level 2 data in Shopify's scheme. Shopify's Level 1 requirements include processing only the data an app needs, setting retention periods so data is not kept longer than necessary, and encrypting data at rest and in transit. Level 2 adds encrypted backups, separate test and production data, a data loss prevention strategy, limited staff access, strong staff passwords, an access log of protected customer data, and a security incident response policy. Shopify also notes that custom Level 2 PII apps require the Grow plan or higher.

For a merchant, the practical reading is simple: any app on your store that shows Level 2 access can see the same categories of data Keystone lost.

Admin API tokens for custom apps

Shopify's documentation for admin-created custom apps, which can no longer be created but continue to work, sets out how their tokens behave:

• The Admin API access token is generated when the merchant installs the app, and it is shown only once.
• Shopify's examples send it in the X-Shopify-Access-Token header and keep it in an environment variable.
• The documentation does not describe an expiry for these tokens.
• You cannot rotate the API key or secret. To get a new access token, you uninstall and reinstall the app from the Shopify admin. Requests and webhooks break until your code uses the new token.
• Shopify warns not to delete such an app, because deletion is permanent and a new admin-created custom app cannot be made to replace it.
• Changing scopes needs the "Manage and install apps and channels" and "Develop apps" permissions, plus permission for the resource being changed.

New custom apps are created and managed in the Dev Dashboard. Store owners have full access there; staff need the "App development" and "Develop" permission; collaborators cannot reach the Dev Dashboard. Each custom app is linked to a staff or collaborator account that receives warnings about it.

Staff and collaborator access

Listing your own app's scopes

Shopify documents a GraphQL query an app can run to list the scopes it was granted on install. Running it with each integration's own token is a quick way to compare what an app holds against what it needs. Replace the store name and use the token from your secret store, never from a file in a repository:

curl -s -X POST \
  "https://YOUR-STORE.myshopify.com/admin/api/2026-10/graphql.json" \
  -H "Content-Type: application/json" \
  -H "X-Shopify-Access-Token: $SHOP_TOKEN" \
  -d '{"query":"query { currentAppInstallation { accessScopes { handle } } }"}' \
  | jq -r '.data.currentAppInstallation.accessScopes[].handle' | sort

If the output contains read_all_orders, read_customers or write_customers and the integration only needs, for example, product inventory, that is a scope to remove.

The precedent: Ledger in 2020

The closest earlier case is Ledger's 2020 e-commerce breach, and its timeline is worth knowing because it shows how long exposed order data stays dangerous.

According to Ledger's notice of 29 July 2020, an unauthorized third party accessed part of its e-commerce and marketing database on 25 June 2020 through an API key, which Ledger then deactivated. A bug bounty researcher reported the issue on 14 July. About 1 million email addresses were exposed, and for a subset of 9,500 customers (9,532 in Ledger's later message) postal address, name, phone number or ordered products were also exposed. Ledger said payment data, passwords and crypto funds were not affected.

Then, on 21 December 2020, Ledger's chief executive wrote that about 272,000 detailed records, including postal address, name and phone number, had been dumped on a public forum. Ledger said it believed the data came from its e-commerce database as of June 2020, and that customers were already being targeted by email and SMS phishing aimed at their 24 word recovery phrases.

That is the pattern Keystone's warning anticipates: a breach that looks contained when it is disclosed, followed months later by publication of the data and sustained phishing. Nothing published says the Keystone data has been posted anywhere, and we are not suggesting it has. The lesson is about duration. Customers in a shipping data leak should assume the phishing risk lasts for years, not weeks.

Other hardware wallet incidents this year, timing only

Keystone's breach comes in a year with several incidents around hardware wallet sellers. Trezor disclosed in August that its logistics provider ShipMonk had been breached, and in September said about 67,000 more US customers were affected, from orders that should already have been deleted; we covered it in Trezor and the ShipMonk breach. Crypto Briefing also reports that earlier in October Ledger said criminals had modified genuine devices to steal recovery phrases and resold them through resellers in Southeast Asia. These incidents involve different companies, systems and methods. The link between them and Keystone is timing and sector only. No source connects them.

Who is affected

What to do now

If you bought a Keystone device

1. Read Keystone's email carefully, then go to the source. If you receive a notification, do not click links in it. Type keyst.one into your browser, or check @KeystoneWallet on X directly. If anything is unclear, write to support@keyst.one from a new message, not a reply.
2. Never type or speak your recovery phrase to anyone. Keystone says it will never ask for it. No refund, replacement, verification, compliance check or "address fix" requires it. A request for it is always a scam.
3. Treat any device you did not order as hostile. If a "replacement" Keystone arrives unrequested, do not power it on with your recovery phrase. Keystone's statement is explicit on this point.
4. Verify any device you did order. Keystone runs a Device Verification page at keyst.one/auth. Use it on a device you ordered yourself, and reach it only by typing the address, never from a link in a message.
5. Get firmware only from the official page. Keystone publishes firmware at keyst.one/firmware. Ignore firmware files or "update links" sent by email, text or social media.
6. Expect calls and letters too. Keystone lists phone, text, email and mail as likely channels. A caller who knows your order is not proof the call is real.
7. Think about physical exposure. Your name and address are now tied to a crypto wallet purchase in a criminal's hands. Following Ledger's advice from 2020, avoid keeping your recovery backup at home in an obvious place and review basic home security. Do not discuss holdings with unknown callers or on social media.
8. If you already entered your phrase somewhere it should not go, treat that wallet as compromised and set up a new one on a device you trust. That is a security step, not investment advice.

If you run a Shopify store

Keystone's breach is a reminder that the store, its apps and their tokens hold the most sensitive customer list most merchants have. These checks take about an hour on a typical store.

1. List installed apps. In the Shopify admin go to Settings, Apps, Installed. For each app, open its About page and read the App history section for install and uninstall events and the staff member involved.

2. Uninstall what you do not use. Before you do, export any data you need, and remember that some apps leave code in your theme that uninstalling does not remove. Shopify's help page suggests contacting the developer through Settings, Apps, Get support about data the app retains.

3. Review scopes app by app. For each app with access to orders or customers, ask whether it needs read_customers, write_orders or read_all_orders. Shipping and fulfilment apps may need order addresses. A review widget or a pop-up builder usually does not need your whole customer list.

4. Check protected customer data access. Apps that read names, addresses, emails or phone numbers need Level 2 approval. Make a list of every app at Level 2. That list is your real exposure.

5. Find every custom app token in your own code. Search your integration repositories for the token header so you know where tokens are used:

   git grep -n "X-Shopify-Access-Token"
   git grep -n -i "shopify" -- '*.env*' '*.yml' '*.yaml' '*.json'
   

   Any token committed to a repository, pasted in a wiki, or stored in a spreadsheet should be treated as exposed.

6. Replace exposed or long lived tokens. For legacy admin-created custom apps, Shopify says the only way to get a new token is to uninstall and reinstall the app, which breaks requests and webhooks until your code is updated. Plan a short maintenance window, update the secret store first, and do not delete the app.

7. Move new integrations to the Dev Dashboard. Shopify recommends it for new custom apps. Request only the scopes the integration needs.

8. Lock down staff accounts. Make sure every staff member has two-step authentication on. On Shopify Plus, require a secure sign-in method for everyone in the organization. Remove staff who have left, and review roles for least privilege.

9. Review collaborators. Filter Users by Collaborators, remove partners you no longer work with, and click Generate new code to invalidate the collaborator request code you shared in the past.

10. Clean up exports. Order and customer CSV exports sit in laptops, shared drives and email. Find them and delete what is no longer needed:

    find ~/Downloads ~/Desktop -iname "*order*export*.csv" -o -iname "*customers*export*.csv"
    

11. Write down who to call. Know how you would contact Shopify support to review API activity, as Keystone did, and who on your side owns the customer notice. Prepare a template that lists exposed and not exposed data the way Keystone's post does.

If you build Shopify apps

1. Request the narrowest scopes. Do not ask for read_all_orders unless the feature needs history beyond 60 days.
2. Store only what you need, for as long as you need it. Shopify's Level 1 requirements already ask for retention periods; make yours short for addresses.
3. Keep tokens out of code and logs. Use an environment variable or secret manager, as Shopify's examples do, and redact the X-Shopify-Access-Token header in request logging.
4. Keep an access log of protected customer data, as Level 2 requires, so you can answer a merchant's questions within hours if something goes wrong.
5. Keep your own dependencies current. An app that holds tokens for many stores is a high value target, and its web framework, HTTP client and authentication libraries are part of that attack surface.

What changed since first reports

• 24 October, 17:59 UTC: Keystone's post sets the facts: detection 20 October, confirmation 23 October through Shopify API activity, data classes, exclusions, actions and scam warnings.
• 24 October, evening: Outlets repeat Keystone's statement. Crypto Briefing paraphrases "fixed the vulnerability" as "patched the vulnerability" and quotes the detailed report as due "in the coming days", where Keystone's own post says "coming soon".
• 24 October: Coin Edition lists phone numbers among exposed data. Keystone's post says "contact details" without listing phone numbers.
• 25 October: Chinese-language coverage, carried by KuCoin, dates the apology 25 October because of the Hong Kong time zone.
• As of 25 October: No affected customer count, no root cause and no detailed report have been published.

Open questions

• Which app, token or account made the API calls Keystone reviewed with Shopify?
• What was the "vulnerability" Keystone says it fixed: a credential, an app permission, an account setting, or something else?
• When did the access start, and how far back do the exposed orders go?
• How many customers are affected, and in which countries?
• Were phone numbers included in "contact details"?
• Has Keystone seen any scam attempts using the data yet?
• Will the detailed report include indicators, such as sender addresses or domains used in phishing, that customers can watch for?

We will update this post when Keystone publishes its report.

What would have helped

None of this is a judgement on Keystone. It detected the access, worked with its platform to confirm what was taken, blocked it, told customers what was and was not exposed within a day of confirmation, and put scam guidance first. The useful question for every other merchant is how to make this class of event smaller.

Practices any team can use

• Treat your commerce platform's apps as your supply chain. Every installed app with order or customer scopes is a vendor with a copy of, or live access to, your most sensitive list. Keep an inventory with owner, purpose, scopes and data level for each.
• Least privilege on scopes. Remove read_customers and read_all_orders from apps that do not need them. Revisit scopes whenever an app is updated.
• Short data lifetimes. Addresses are needed to ship a parcel. After the return window closes, few systems need them in clear text. The Trezor and ShipMonk case shows the cost of order data that outlives its purpose.
• Treat tokens as credentials with an owner and a replacement plan. Know where each token lives and how you would replace it today, including the uninstall and reinstall dance for legacy custom apps.
• Strong sign-in everywhere. Two-step authentication for every staff member, and secure sign-in enforcement where your plan allows it. Fresh collaborator codes after each engagement.
• Watch API usage. If your store or apps can report API call volume per app, alert on sudden bulk reads of orders or customers. Keystone's detection path, API activity, is the one to build.
• Prepare the customer message. Keystone's post is a good template: what happened, what was exposed, what was not, what we did, what scammers will try, how to reach us.
• Keep integration code healthy. Custom apps and middleware that hold store tokens are software you own. Track their dependencies, rebuild when fixes ship, and keep tokens out of source.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. Gold Open Source (gold.safeguard.sh, free, no login) gives searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API.

The limits matter here. Keystone 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. A hosted commerce platform, its permission model and its app marketplace are outside what these capabilities cover. Where they help is in the code merchants and app builders run themselves: the custom apps, middleware and storefront services that hold store tokens, whose frameworks and libraries should be patched and rebuilt fast when a fix ships.

Where Safeguard fits

Safeguard would not have prevented this incident, and we do not claim it would have detected it. It does not audit Shopify app scopes, monitor store API traffic, manage platform staff accounts or review order data retention. What it covers, at GA, is the software around the store that you build and run yourself:

• Dependency and image scanning of the repositories, container images and SBOM files behind a custom app, a fulfilment middleware or a headless storefront, 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 HTTP client, web framework or authentication library your integrations use.
• Vulnerability matching and reachability analysis, ranking the vulnerable code paths your integration 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 refactor an integration so the token is read from an environment variable instead of a config file, or to remove unused scopes from an app's configuration, 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

For finding every affected service quickly when an advisory lands, see SBOM incident response.

Common mistakes and troubleshooting

• "Nothing financial leaked, so customers are fine." For a hardware wallet seller, a postal address tied to a device purchase is the dangerous part. Say so plainly in your notice, as Keystone did.
• Deleting a legacy custom app to kill its token. Shopify warns that deletion is permanent and cannot be undone with a new admin-created app. Uninstall and reinstall instead, after preparing the code for the new token.
• Rotating the token but not the copies. If a token was in a repository, a CI variable and a teammate's notes, replacing it in one place leaves the old exposure documented elsewhere. Search all three.
• Assuming 2FA is on for everyone. On most plans, the owner cannot enforce it for staff. Check each account rather than assuming.
• Forgetting collaborators. Former agencies and freelancers often keep access for months. Collaborator accounts expire after 90 days without a login, but an active one stays until you remove it.
• Keeping CSV exports forever. A spreadsheet of every order with addresses is a full copy of your exposure, outside every control the platform offers.
• Answering the "replacement device" email. For customers, the most common mistake is responding to a convincing message that quotes a real order. The order details are now public to the attacker; they prove nothing.

FAQ

What happened at Keystone?

Keystone says it detected unauthorized access to its official website, a Shopify store, on 20 October 2026. After reviewing API activity with Shopify, it confirmed on 23 October that a third party obtained customer shipping information. It apologised publicly on 24 October.

What data was exposed?

Per Keystone: names, contact details, shipping addresses and order details, meaning items and prices. One outlet lists phone numbers; Keystone's post does not specify them.

Were recovery phrases or private keys exposed?

No, according to Keystone. Recovery phrases, private keys, wallet passwords and payment card or bank details were not exposed.

How many customers are affected?

Keystone has not said. It is emailing affected customers directly and has promised a detailed report.

How did the attacker get in?

Keystone has not said. It confirmed the theft by reviewing Shopify API activity and says it fixed the vulnerability. It has not yet named the app, token or account involved.

I got an email about a refund or replacement device. Is it real?

Keystone says scammers may pose as the company offering refunds, replacement devices or order and address fixes, and that none of that comes from Keystone. Do not click links. Contact support@keyst.one from a new message.

A Keystone device arrived that I did not order. What should I do?

Do not set it up with your recovery phrase. Keystone says never to enter a recovery phrase into a device you did not order. Contact Keystone support.

Is this connected to the Trezor or Ledger incidents?

No source says so. They involve different companies and systems. The only link is that they hit the same sector in the same year.

I run a Shopify store. Is my store affected?

Nothing published suggests other merchants are affected by this incident. It is still a good time to review installed apps, scopes, custom app tokens, staff two-step authentication and collaborator access.

Would Safeguard have prevented this?

No. Safeguard does not audit commerce platform apps or monitor store API traffic. It helps with the custom code and dependencies around a store that you build and run yourself.

Keystone's incident sits in a hosted platform rather than a library, but the custom apps and middleware that hold store tokens are open source heavy software you ship yourself, and that is where these steps apply.

Fix it without waiting for upstream

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 categories include dependencies, licenses, security posture and findings, and each one is set separately. 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.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) 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. 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 Keystone or its systems. Each is a real Safeguard session, and below each one we explain how the same flow applies to a team that runs custom code around a Shopify store.

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 a Shopify custom app, you would run /scan . in its repository, then ask the assistant to move the access token out of a config file into an environment variable and to drop unused scopes from the app configuration, approving each edit and 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 merchant's developer could pick the folder holding the fulfilment middleware, ask for its HTTP client and framework to be upgraded to fixed versions, 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 over a weekend for a library your store integration uses, the on call engineer could approve the dependency bump and test run from a phone, and deny any command that would touch production tokens 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 a structured response when a component you depend on goes bad, the compromised dependency playbook.

Quick check

Sources

• Keystone on X: apology and scam warning (24 Oct 2026)
• Keystone post metadata via X syndication
• Keystone: device verification
• Keystone: firmware
• Shopify: API access scopes
• Shopify: protected customer data
• Shopify: generate access tokens for admin-created custom apps
• Shopify: currentAppInstallation query
• Shopify Help Center: custom apps
• Shopify Help Center: uninstalling apps
• Shopify Help Center: two-step authentication
• Shopify Help Center: collaborator accounts
• Ledger: addressing the July 2020 e-commerce and marketing data breach
• Ledger: message from Ledger's CEO on the data leak (21 Dec 2020)
• Bitcoin News on X (24 Oct 2026)
• Crypto Briefing: Keystone data breach (24 Oct 2026)
• Coin Edition: Keystone wallet data breach exposes shipping details (24 Oct 2026)
• Coinfomania: Keystone hardware wallet confirms customer data exposure (24 Oct 2026)
• Cryptonews.net: Keystone breach report
• KuCoin news flash: Keystone confirms unauthorized access

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