Andy Garcia · freelance dev
FRENES
Back to the blog
Security

ASOS's Own App Pushed 'ASOS Hacked' to Customers. ASOS Says the Way In Was One Employee Account.

October 19, 2026 8 min read

On Tuesday, October 6, ASOS app users got a push notification from the ASOS app itself. Its title was "ASOS HACKED". Its text, as quoted by Malwarebytes: "Dear Asos DPO and IT, we have fully compromised the Snowflake instance. Engage with us, or we will leak it." It came with a link to a Telegram channel. ASOS's own statement puts it at around 10 am, and customers in Great Britain, Ireland, the United States and other countries reported it, according to BankInfoSecurity.

Later that day, ASOS, which reports 16.5 million active customers, confirmed in a statement to the London Stock Exchange that "an unauthorised customer notification was sent to ASOS customers." "We are investigating unauthorised activity involving third-party platforms that we use to communicate with customers," it said. "We took immediate action to restrict access to the notification platforms." Its shares fell by more than 10 percent that Tuesday, PA reported; FashionUnited put the morning drop at around 11 percent, followed by a partial recovery. That evening, ASOS emailed customers to "disregard the notification and do not click or engage with the external third-party link it contained."

On Thursday, October 8, ASOS published what its first 48 hours of investigation had found: "an unauthorised party gained access to an ASOS employee account by impersonating a trusted contact to obtain log in credentials. Those credentials were then used to access information on certain third-party platforms used by ASOS."

ASOS's account describes no software flaw. A person was fooled, and a login that could reach the systems that talk to customers changed hands.

I ship iOS apps as an indie developer, and I am CTO of a LegalTech. I read the incident with one question: who, outside my own code, can make my app speak?

What is confirmed, and what is only claimed

ASOS's update says the intruder had access to "some personal information, including names and contact details, and certain non-personal account related information," and that no payment card information and no account passwords were accessed. The affected platforms were "immediately locked down," and the full investigation "will continue over the coming weeks." ASOS has not named the platforms.

The rest comes from the attackers or from researchers. The notification blamed Snowflake. Snowflake said it had "found no compromise" of its platform. In a report published on October 8, the BBC said the group, which calls itself Xuanye, claimed it had gone through Simon AI, an agentic marketing platform that, according to BankInfoSecurity, ASOS uses on top of its Snowflake instance. A sample the group sent to the BBC contained names, addresses, phone numbers, emails, customer numbers, dates of birth and searches made on the site, with terms like "glamorous wide fit", the BBC reported. That goes beyond the "basic contact details" ASOS had first said might have been accessed. Simon AI, which Monetate acquired in July, had been asked for comment.

The security researcher Kevin Beaumont wrote on Mastodon on October 8 that Simon AI does not require multifactor authentication for accounts, that it is not enabled by default, and that "This was the route into ASOS." Neither ASOS nor Monetate has confirmed that. Group-IB, for its part, told Infosecurity Magazine that the Telegram channel in the notification was created on October 6, by an account that had previously carried names tied to gaming-item trading.

So the entry point is confirmed in ASOS's own words. The platform is not.

The sender is wider than the push provider

In most apps, the code that receives a push lives in the app, and the code that sends it lives somewhere else. Marketing teams need to send without waiting for a release, so the sending credentials go into a customer engagement platform and, through integrations, into other tools that can trigger a send.

An undated case study on Simon AI's site describes exactly that at ASOS: "Simon enabled ASOS to trigger push notifications in response to a shopper's activity in-app." Malwarebytes notes that ASOS has described using Simon AI alongside Braze, a customer engagement platform, to trigger messages such as push notifications. None of the reports I read ties Braze to the incident.

That is the lesson I take, whatever the final report says. Any tool that can trigger a send is a sender, whatever its category on the invoice. A marketing tool with a "trigger push" integration has the same reach into your users' lock screens as your own backend. And its logins usually sit with a marketing team, outside the controls the engineering team applies to production.

The lock screen is a megaphone

The other thing that struck me is who the message was for. It was addressed to ASOS's data protection officer and IT team. Customers were the audience, not the target. Camellia Chan, CEO of X-Phy, put it this way to Computer Weekly: "It didn't sit in an inbox waiting to be read; it lit up the lock screens of app users, under the Asos name, before the company itself had a statement out."

A ransom note on a leak site needs someone to repeat it. A ransom note on customers' phones repeats itself. The shares fell more than 10 percent during trading on a day when ASOS itself could only say what "may have been accessed." The damage came through the channel before anyone knew the size of the data. And ASOS's help page now answers a question no retailer wants on its FAQ: "Are ASOS push notifications safe to open?"

The keys behind an iOS push

On Apple's side, the documentation is short and worth rereading. One APNs signing key can authenticate tokens for several apps. It "works for both the development and production environments," and it "doesn't expire, but can be revoked." When you create a key, you choose its environment configuration and whether it is Team Scoped or Topic Specific, limited to the topics you select. Only an Account Holder or Admin can manage keys. If a key may be compromised, Apple's procedure is to create a new key, transition to it, then revoke the old one. Revoking, Apple warns, "affects any services that use the key."

Put those lines together and the risk is plain. A team-wide key that never expires, pasted into a vendor's dashboard years ago, is a standing permission for every app in the team until someone revokes it. And revoking it stops every legitimate send that uses it at the same moment. Rotation is a migration, not a click.

Push platforms have their own settings. Braze's public documentation, as one example, lets each REST API key be limited to specific endpoints, such as messages.send, and to allowlisted IP addresses: "If you don't specify any, requests can be sent from any IP address." Permissions and allowlisted IPs cannot be edited after a key is created, so changing scope means issuing a new key. None of that helps when someone signs in with an employee's stolen login, which is what ASOS describes. That part is about enforced MFA and about who holds an account at all.

What I would check before the next campaign

This is the list I would run on any app that sends push, mine included.

First, the inventory. Every system that can make a push, an email or an SMS reach all users: the push provider, the customer data platform, the AI marketing tool, the automation tool with a webhook. For each one, who has a login, and whether MFA is enforced, not just offered.

Second, the blast radius. A message to a segment and a message to everyone should not need the same permission. If a platform supports an approval step, I would require it for sends to the full audience.

Third, the keys. Where possible, one Topic Specific APNs key per app and per environment, a written list of every place each key was pasted, and a rotation rehearsed once, and timed, before it is needed.

Fourth, the tap. What appears on the lock screen comes from the sender. What happens when the user taps it goes through code I ship. If an app opens any URL that arrives in a notification payload, a hijacked sender can send users anywhere. An allowlist of the app's own routes and domains is a small change.

Fifth, the alarm and the apology. An alert when a send reaches an unusual number of users outside a scheduled campaign, and a pre-written "please disregard" message for the channels that still work. ASOS used email and, according to CPO Magazine, an in-app notice.

For a CTO, there is one more line. The vendors that clients audit are usually the ones that store their data. The ones that can speak to your users in your name belong on the same list.

ASOS's notification was addressed to its DPO. It reads better as a memo to everyone who gave a marketing tool the keys to their users' lock screens and never checked who else could log in.

Sources

A project like this one?

I design and deploy products like this. Let's talk.

Let's talk