ASOS Customers Sent ‘Hacked’ Notifications - Why Customer Messaging Platforms Are a Blind Spot

At around 10am on 6 October 2026, ASOS customers across the UK picked up their phones to an app push notification headed “ASOS HACKED”. It read: “Dear ASOS DPO and IT, we have fully compromised the Snowflake instance. Engage with us or we will leak it.” An extortion demand, addressed to the company’s data protection officer, delivered not to the company but to its customers — through the company’s own app. ASOS has confirmed that “an unauthorised customer notification was sent”, that it is “investigating unauthorised activity involving third–party platforms that we use to communicate with customers”, and that it has restricted access to those notification platforms. The NCSC has published an advisory on the incident.

Two things need separating straight away, because the story is easy to read as more settled than it is. What is confirmed is that someone gained enough access to a customer communication platform to send a push notification to ASOS’s app users, and that ASOS believes basic personal information — names and contact details — may have been accessed. What is claimed, by a group calling itself Xuanye Group, is that it has fully compromised ASOS’s Snowflake data platform and holds the data. Snowflake says it has seen no evidence yet of a compromise of its platform similar to the wave of Snowflake–linked breaches in 2024. As Eset’s Jake Moore put it, sending the notification proves access to at least some connected systems; it does not confirm the attackers’ full claims. The useful lesson for UK businesses sits in the confirmed part, not the claimed one: the channel you use to talk to your customers is itself a target, and in the wrong hands it speaks with your voice.

What is confirmed, what is claimed, and what is unknown

ASOS’s account is the most authoritative and it is deliberately narrow. The company confirms an unauthorised customer notification was sent, that it is investigating unauthorised activity involving third–party platforms it uses to communicate with customers, and that it has restricted access to the notification platforms. It says “basic personal information including name and contact details may have been accessed”, but that it does not believe payment card information or account passwords were impacted. Its website and app continued to operate normally, with no disruption to core business.

Snowflake confirmed it was aware of the notification and had begun its own investigation, but said there was as yet no evidence of a compromise of its platform similar to the Snowflake–linked breaches that hit multiple companies in 2024. That is worth reading precisely. A customer’s own Snowflake instance — the account and data a company holds on the service — is a different thing from Snowflake’s underlying platform. The attackers claim the former; Snowflake is speaking to the latter. The two statements are not in direct contradiction, and neither settles what, if anything, happened to ASOS’s data in Snowflake.

The attackers’ claims deserve to be reported as claims. The notification linked to a Telegram channel that the BBC’s Verify service traced to a group calling itself Xuanye Group, not previously observed. Messages on the channel say payment data was not compromised and that stolen data remains “safe on our server” for a “designated period” — standard extortion language designed to create time pressure. The group’s name and terminology suggest a possible Chinese origin, potentially referencing the Qing dynasty Kangxi emperor, who reigned from 1661 to 1722. A name is not attribution, and nothing published so far establishes who the group is or where it operates.

What is unknown is the thing that matters most: the actual extent of access. Black Duck’s Boris Cipot cautioned that the full extent of any data access is unconfirmed and that the investigation needs to establish which accounts, credentials and systems were actually touched. That is the honest position on day two of any incident, and it is worth resisting the temptation — in either direction — to fill the gap with assumption.

Moore’s description of it as likely “one of the most visible hacks in history” is accurate in a specific sense. Most breaches are discovered by the victim, disclosed in a statement and reported days later. This one announced itself on the lock screens of the victim’s customers, in the victim’s name, before the victim had said anything. That inversion — customers learning of the incident before or at the same time as the company’s own security team — is the defining feature, and it is entirely a product of which system the attackers reached.

How the incident unfolded

The sequence below follows what ASOS, Snowflake, the NCSC and those reporting on the incident have published. Most of it happened within a single day, which is itself unusual.

The compression of that timeline is instructive. In a conventional breach, the victim usually controls the first public statement and has time — sometimes weeks — to investigate before customers hear anything. Here the attacker made the first announcement, to the customers, and the company’s first communication was necessarily a response to something its customers had already seen. That is the operational consequence of losing control of a customer channel: you lose control of the sequence in which people find things out.

Which systems give an attacker the most direct reach to your customers

The chart below is an indicative planning model — not measured data — ranking common business systems by how directly a compromise of each would let an attacker reach your customers in your name.

The ordering inverts how most businesses allocate their security attention. An individual staff mailbox — the bottom row — is where most of the training, monitoring and multi–factor enforcement goes, and for good reason. The top four rows are typically owned by marketing or a digital agency, accessed through shared credentials or long–lived API keys, and rarely reviewed by anyone responsible for security. Yet each of them can reach every customer at once, instantly, in an authenticated channel that carries the brand’s full credibility.

The website CMS and social accounts sit lower because a defaced page or rogue post is visible but does not land directly on a customer’s phone or in their inbox. The push and email rows are different in kind: they deliver into a personal, trusted space and invite action. That is why they are as useful for phishing as for extortion, and why their compromise has consequences long after the original incident is contained.

The “least sensitive” data is the data that enables the next attack

ASOS’s statement addresses three categories of customer data. Sort them by its current assessment.

On the face of it this is reassuring, and in a meaningful sense it is: cards and passwords are the categories with the most immediate financial consequence, and ASOS’s current belief is that neither was affected. But the category that may have been accessed — names and contact details — is not harmless. It is the raw material for exactly the attack that tends to follow a highly visible breach: messages impersonating the brand, referring to the incident, and inviting customers to “verify” their account, claim a “refund” or “secure” their details through a link.

That pattern is well established, and the visibility of this particular incident makes it more likely rather than less. Millions of people now know ASOS was attacked. A message that mentions the incident, uses the customer’s real name and arrives at their real email address or phone number will look entirely plausible — and is far more likely to be acted on than generic phishing. That is why Natalie Page of Talion advises customers to avoid clicking links in unexpected messages. Her advice to update passwords, including on any other accounts sharing the same one, is worth following even though ASOS does not believe passwords were impacted: it costs a customer a few minutes and removes a risk that nobody can yet fully rule out.

For businesses, the transferable lesson is about how incident severity is judged. Data protection assessments often rank contact details as low sensitivity, which is true in isolation and misleading in practice. Combined with a moment of public alarm, a trusted brand and a plausible pretext, a list of names and contact details becomes a targeting list. The question to ask about any breach of customer data is not only “how sensitive is this field?” but “what attack does this make easier, and for how long?”

Where UK businesses carry the same exposure

Very few UK SMEs run an app with push notifications. Almost all of them use at least one third–party platform to communicate with customers. The rows below reflect where that exposure typically sits, with badges indicating how much attention each usually needs.

The fourth row is the one most often found during a review, and the one nobody intended. A marketing agency engaged two years ago, a freelancer who built the newsletter template, a former employee who set up the SMS account with their personal email — each may still hold credentials with full send rights over your customer list. None of them needs to be malicious for this to be a risk. Their own accounts may be compromised, their credentials may be reused elsewhere, and you will have no visibility either way. Removing access you have forgotten granting is one of the highest–value and lowest–cost actions available.

The seventh row is the one this incident made unmissable. ASOS’s customers heard from the attackers before or alongside hearing from ASOS. A business that has never planned how it would reach customers if its normal channel were compromised — or untrusted — will be drafting that message under pressure, while the attacker’s version is already out. A short, pre–agreed holding statement, a named person who can approve it, and an alternative channel to publish it through are inexpensive to prepare and decisive in the first hour.

What closing this gap costs

The bands below are indicative planning figures for UK businesses securing their customer communication platforms and incident response — not quotes.

The first row is close to free and covers the majority of small businesses. Most email marketing and CRM platforms already support multi–factor authentication and individual user accounts; the work is switching them on, removing people who should no longer be there, and replacing any API key that has been sitting in an integration for longer than anyone remembers. It is an afternoon’s task that closes the route this incident used.

Two ways to run your customer channels

Very little in the right–hand column requires spending. It requires reclassifying a set of tools that most organisations think of as marketing infrastructure. Once a push service or email platform is understood as something that can address every customer in the company’s name, the controls follow naturally — the same ones already applied to a finance system or an administrator account. The gap is not technical. It is that these platforms sit in a department whose job is reaching customers easily, which is precisely the property an attacker wants.

What customers should do, and what businesses should take from it

For ASOS customers, the expert advice is straightforward and worth following regardless of the eventual findings. Natalie Page recommends updating passwords, including on any other accounts that share the same password; avoiding links in unexpected messages; and she notes that ASOS does not currently offer mandatory multi–factor authentication to customers, which the incident may prompt it to reconsider. The middle point is the most important for the coming weeks. Any message referring to the breach, offering compensation or asking a customer to verify details should be treated with suspicion, and the safe route is to go to the retailer’s site or app directly rather than following a link.

For businesses, the lesson is less about this retailer than about a category of system that has quietly become security–critical. Customer communication platforms are now among the most powerful accounts most organisations hold: they reach everyone, instantly, with full brand credibility. They are also among the least protected, because they are procured for convenience and reach rather than control. An attacker who obtains one does not need to steal data to cause harm; the channel itself is the weapon, whether used for extortion, as here, or for a campaign of perfectly branded phishing.

For organisations pursuing Cyber Essentials, the relevant hook is scope and access control. Cloud services that hold customer data or can act on the organisation’s behalf fall within the scheme’s thinking about user access and multi–factor authentication on cloud services, and marketing platforms are routinely left out of the inventory because they are managed by a non–technical team. An assessment is a good moment to ask explicitly: which third–party platforms can send messages to our customers, and are every one of their accounts protected to the same standard as our email?

Finally, there is a data protection dimension that applies regardless of size. Names and contact details are personal data, and a compromise of a platform holding them may engage UK GDPR obligations, including potential notification to the ICO. The practical difficulty, as Boris Cipot’s comments make clear, is establishing what was actually touched. A business that has never mapped which platforms hold its customer data, and keeps no audit logs on them, will struggle to answer that question — and will be left notifying broadly because it cannot notify precisely.

The story at a glance

This story connects to several we have covered recently, and the common thread is trusted channels and concentrated data. The BT email password reset flood is the closest parallel: an official channel used against the customers it was meant to serve, leaving them unable to tell genuine messages from malicious ones. The Kiteworks shutdown warning makes the case for knowing exactly what data sits on a platform before someone else claims to have taken it. The JadePuffer attackers hijacking Azure identities shows how a single unprotected credential becomes reach across a whole estate — the same mechanism by which a forgotten API key becomes a direct line to every customer. OpenAI notifying 100–plus organisations about its agents is a reminder of how much depends on logs being good enough to establish what was actually touched. The actively exploited Citrix NetScaler flaws share the same day–two problem of an extent nobody can yet confirm. And Microsoft’s maintenance breaking Azure hybrid connectivity shows how third–party platforms can fail you in ways you neither caused nor control.

Frequently asked questions

CloudSwitched

London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.