On 6 October 2026, customers of the online fashion retailer ASOS received a push notification from the ASOS app. It was headed ASOS HACKED. It had not come from ASOS.
The message read: “Dear Asos DPO and IT, we have fully compromised the Snowflake instance. Engage with us, or we will leak it,” followed by a link to a Telegram channel. ASOS shares fell around 13% on the day.
That detail is what makes the ASOS cyber incident worth your attention rather than just another breach headline. The attackers did not simply take data. They got far enough into the systems ASOS uses to talk to its customers that they could use that channel against the company, in public, on hundreds of thousands of phones, before ASOS had finished working out what had happened.
This is an early assessment of a developing incident. We have been careful below to separate what ASOS has confirmed from what the attackers have claimed, because those are very different things.
The ASOS cyber incident: what has been confirmed
ASOS says an unauthorised customer notification was sent at around 10am on 6 October. Its statement was that it is “investigating unauthorised activity involving third-party platforms that we use to communicate with customers.”
The company restricted access to those notification platforms, brought in internal and external specialists, and involved the relevant authorities. It says basic personal information, including names and contact details, may have been accessed. It also says it does not believe payment-card information or account passwords were affected, while making clear that this is an initial assessment rather than a settled conclusion.
The website and app have continued to operate normally.
That picture looks quite different from a ransomware event, where servers and applications stop working and the damage is obvious within minutes. What the visible evidence points to here is unauthorised access to cloud and SaaS infrastructure, customer data exposure, and an extortion attempt.
The unusual part: the attackers spoke through ASOS
The data theft may not turn out to be the most significant feature of this incident. The notification might.
The familiar double-extortion pattern runs: gain access, escalate privileges, find the data, take a copy, contact the victim, demand payment, threaten publication. Here the attackers appear to have added a step, and used the victim’s own customer communication channel to announce the compromise themselves.
That changes the pressure on the victim enormously. Customers, journalists, regulators, investors and security researchers all learn about it at the same moment, and well before the affected company has had time to complete a forensic investigation. A marketing platform becomes an extortion mechanism.
A group calling itself Xuanye Group has been reported as claiming responsibility. At this stage that is a claim, not established fact, and the same applies to the scope of compromise the attackers assert.
Where does Snowflake fit into this?
The attackers’ message named Snowflake, the cloud data platform many organisations use to centralise and analyse large volumes of customer and business information.
There is an important distinction here, and it is one that gets lost in headlines. A customer’s Snowflake account being compromised is not the same as Snowflake being breached. At the time of writing we have not seen a public statement from Snowflake about this incident, and it would be wrong to present the attackers’ claim as established.
There is precedent worth knowing about, though. In 2024, attackers accessed data belonging to a large number of Snowflake customers. Mandiant’s investigation found around 165 affected organisations, and concluded the attackers were using stolen customer credentials rather than exploiting a flaw in Snowflake’s platform.
So the useful question is not “was Snowflake hacked?” It is “how did someone obtain the identity or credential that let them into this environment?” At present, that has not been publicly established.
What the attack path might look like
It would be premature to claim the actual route in. But there are only so many plausible shapes, and they are worth understanding because they apply to your business too.
An attacker might compromise a person: phishing, credential theft, infostealer malware, or a stolen session token. Or they might compromise something that is not a person at all — an API key, an OAuth token, a service account, an integration credential.
That second category matters more than most businesses realise. A modern retail stack is not a network with a wall around it. It is a chain of trust: customer, to website or app, to identity provider, to ecommerce platform, to CRM, to data warehouse, to marketing and notification platforms, to whatever APIs connect them.
Every one of those arrows is an identity, a token or a trust relationship. Compromise one that has enough privilege and an attacker can move through several systems without ever putting malware on a single company laptop. Investigating an incident like this purely as an endpoint problem would miss the point.
Your notification platform is a publishing system
Push notifications are usually owned by marketing and treated as a feature. They should be treated as privileged publishing infrastructure, because that is what they are.
Consider what somebody in control of that platform could send. “Your account has been compromised. Sign in here to secure it.” Arriving as a genuine notification from an app already installed on the phone, that carries vastly more credibility than any phishing email ever will. The victim has already decided to trust the sender.
In the ASOS case the link went to Telegram, and ASOS told customers to ignore it. Imagine instead that it had gone to a convincing copy of the login page. Trusted notification, to fake login, to captured credentials, to account takeover. Or trusted notification, to fake payment verification, to card theft.
The principle is simple enough: your communications infrastructure is part of your security perimeter. Email platforms, SMS gateways, CRM systems, push services and marketing automation all belong inside it.
Third-party access is becoming the perimeter
ASOS’s own wording is worth noting. It referred to “third-party platforms that we use to communicate with customers” — not to its own servers.
Most businesses now run across dozens of interconnected SaaS environments. Firewalls, endpoint protection and VPNs still matter, but an attacker holding a valid SaaS credential does not need to cross your firewall. They authenticate to the service, and from the provider’s side the traffic looks entirely legitimate.
Which moves the problem towards identity, privilege, token security, SaaS configuration and watching for behaviour that does not fit.
Why multi-factor authentication on its own is not enough
We do not know what authentication was in place at ASOS. But the question it raises is worth answering generally, because “we’ve got MFA” is where a lot of businesses stop thinking about identity.
MFA is one of the highest-value controls there is, and you should have it everywhere. It is not the same as having secured identity. Attackers increasingly go after the things that sit around it: session cookies, OAuth tokens, API keys, service accounts, refresh tokens, already-authenticated browser sessions.
A stolen session token lets somebody inherit a session that has already passed the MFA challenge. An API key never faces an interactive challenge at all. Which is why the work continues past MFA into conditional access, device trust, shorter session lifetimes, privileged identity management, secret rotation, and alerting on logins that do not look right.
Service accounts deserve more attention than they get
The most common weakness we find in cloud environments is a machine identity with far more privilege than its job requires.
The quick way to make an integration work is to create a service account, grant it broad permissions, generate a token and leave it in place indefinitely. It is convenient, it works on the first try, and it is still there three years later with the same credential.
The better pattern is least privilege, narrowly scoped API permissions, short-lived credentials, rotation, monitoring, and production identities kept separate from everything else. An integration that needs to read a customer’s email address should not be able to export the entire customer database. A marketing system should not be able to publish anything it likes to every customer you have without a second pair of eyes.
Should a mass notification need approval?
Which raises an architectural question most businesses have never asked. Should one compromised account be able to broadcast an arbitrary message to your whole customer base?
For a platform with that reach, the controls used for payments or production changes start to look reasonable: one person creates the campaign, a second authorised person approves it, and only then does it publish.
High-risk actions could also trigger re-authentication, privileged-access approval, device or address restrictions, volume thresholds and alerting. Somebody trying to send a global notification from an unfamiliar device, in an unusual place, at an odd hour should not be treated the same as a scheduled Tuesday-morning campaign.
Names and email addresses are not harmless
ASOS’s belief that passwords and card details were not involved is genuinely reassuring. It does not make the rest of the data unimportant.
Knowing that somebody is a customer of a particular retailer is exactly what makes a phishing message work. Orders, refunds, deliveries, loyalty points, failed payments, account verification — all of it becomes more plausible when the attacker already knows you shop there.
And there is a particular cruelty to the timing. A message saying “there has been a security incident affecting your account, please verify here” is far more believable in the weeks after a real incident that customers have read about in the news. Expect follow-on phishing, and expect it to arrive some time after the event rather than immediately.
What to review this week
The useful response to an incident like this is not to check whether you happen to use Snowflake. It is to look at your own identity and SaaS trust chain.
Work out which systems hold customer data, which third parties can reach it, which accounts can export it, which APIs join those systems together, where your secrets are kept, and who is able to send a message to every customer you have.
Then: phishing-resistant MFA on every privileged SaaS account that supports it. Remove the dormant accounts and the integrations nobody remembers setting up. Rotate API keys and secrets rather than leaving them valid forever. Cut service account permissions back to what each one actually needs. Feed authentication logs from your critical platforms into one place. And alert on the things that should be rare: large exports, new OAuth grants, logins from somewhere unexpected, new API keys, privilege changes, mass communications.
Incident response has to cover more than laptops
ASOS restricted access to the notification platforms as soon as it found out. That is the right instinct, and it points at something most incident-response plans are missing.
If a SaaS platform is compromised, whoever is responding needs to know how to revoke active sessions, disable integrations, revoke OAuth applications, rotate API secrets, disable service accounts, preserve the audit logs and switch off privileged functions — quickly, and in the right order.
Working out how to do any of that while an attacker is still inside is an expensive way to spend the first hour. Those steps belong in the plan, written down, before you need them.
Logging is what decides whether you ever find out
An investigation of this kind runs on evidence: identity provider authentication logs, data platform access history, OAuth grants, API activity, administrative changes, notification platform logs, cloud audit trails, addresses, devices and export activity. The job is to reconstruct the sequence from initial access through to whatever the attacker did last.
Retention is the part businesses get wrong. If you keep only thirty days of SaaS audit logs and the intrusion began two months ago, the evidence of how they got in has already gone. Logging without enough retention is not far from no logging at all.
The 72-hour clock
Because personal information may have been accessed, this is a data protection matter and not only an IT one. Under UK GDPR you have to assess whether a personal data breach poses a risk to people’s rights and freedoms, and where it does, notify the ICO without undue delay and within 72 hours of becoming aware where feasible.
That clock starts when you become aware, not when your investigation finishes. You are not expected to have all the answers at the point you notify — you can provide more detail as the picture develops. Businesses lose time to the belief that they need the full story first.
Online is not the same as trustworthy
ASOS’s website and app kept working throughout. That is worth sitting with.
Traditional business continuity planning asks what happens when a system stops. Cyber resilience has to ask a harder question: what happens when the system carries on working perfectly, and you can no longer trust what it is doing?
Every dashboard green, every page loading, and an attacker inside sending messages to your customers in your name.
The lesson worth taking
Plenty remains unknown. We do not know the initial access route. We do not know whether the attackers’ claim about the scope of compromise is accurate. We do not know the full dataset involved, or whether a person’s account, a service account, an API credential or an integration gave them their first foothold.
But there is already enough here to be useful. The attack surface that matters is no longer the network. It is the fabric of identities and trust relationships joining your cloud platforms to each other.
You can have excellent endpoint protection, a well-configured firewall and fully patched servers, and still lose customer data through one compromised SaaS identity or a forgotten integration.
So the questions worth asking in your own business are: who can reach our data, what can each identity actually do, which systems trust each other, which machine identities hold credentials that never expire, would we notice unusual behaviour, and could we revoke access today if we had to?
And after this week, one more. Could somebody compromise one of our platforms and use our own trusted channels to attack our customers?
For a lot of businesses, that last one deserves an answer rather sooner than later.
Status: 6 October 2026. This is a developing incident. We have deliberately separated what has been confirmed from what has been claimed, and we have left out a couple of widely repeated details we could not verify. If you would like us to look at your own identity and SaaS exposure, get in touch — or start with our free domain health check.
Sources
Cyber Security News — ASOS app users receive notifications sent by attackers
Quartz — ASOS shares fall after hacker push notification
The Hacker News — Mandiant findings on the 2024 Snowflake customer compromises
National Cyber Security Centre
