On the morning of 6 October 2026, ASOS app users received a push notification that read "ASOS HACKED". The UK online retailer confirmed the same day that it was investigating unauthorized activity involving third-party platforms it uses to communicate with customers. Two days later, ASOS said the attacker got in by impersonating a trusted contact to obtain an employee's login credentials.
No ASOS core system is described as breached. The attacker needed one person's credentials and the SaaS tools that person could reach.
What's affected
From ASOS's 6 October market update and its later statement as reported by BleepingComputer on 8 October:
- Entry point: An unauthorized party "gained access to an ASOS employee account by impersonating a trusted contact to obtain log in credentials," then used those credentials to access information on third-party platforms.
- Platforms: ASOS refers to third-party platforms used to communicate with customers. It has not named them.
- Data: Full names, contact details and certain non-personal account-related information. ASOS says payment card information and account passwords were not accessed.
- Scale: ASOS has not said how many customers were affected.
- Response: ASOS restricted access to the platforms, locked them down and opened an investigation with external experts, law enforcement and regulatory authorities. Its website and app kept operating normally.
The push notification itself claimed the sender had compromised the company's Snowflake environment and linked to a Telegram channel run by a group calling itself the "Xuanye group". ASOS has not confirmed that claim. Treat it as the attacker's statement, nothing more.
ASOS's customer advice was that no account action is needed, that customers should be cautious of unexpected messages or calls claiming to be from ASOS, and that ASOS will never ask for passwords, security codes or payment details through unsolicited contact.
How to check if you're exposed
If you are an ASOS customer, follow the company's advice and treat any unexpected ASOS message asking for codes or payment details as phishing.
If you run a consumer brand, the more useful exercise is mapping your own customer messaging stack:
- List every platform that can send to customers. Push notification services, email service providers, SMS gateways, in-app messaging, CRM and customer data platforms. Each one is a channel an attacker can broadcast through.
- List who can log in to each. Export users from each admin console and compare against your identity provider. Accounts that are not behind SSO are the ones a phished password opens directly.
# Compare a SaaS user export against your IdP's active users
comm -23 <(cut -d, -f1 saas_users.csv | tr 'A-Z' 'a-z' | sort -u) \
<(cut -d, -f1 idp_active_users.csv | tr 'A-Z' 'a-z' | sort -u)
Anything printed is a SaaS account with no matching active identity: a leaver, a contractor, a shared login or a local account outside SSO.
- Check who can send a broadcast. In most push and email platforms, "send to all users" is a role. Count how many people hold it.
- Check data export rights. Being able to read customer profiles is different from being able to export them in bulk. Find out who can do the second.
What to do now
- Put every customer-facing SaaS tool behind SSO. Local passwords on a marketing or messaging platform are exactly what a social engineering call is after.
- Use phishing-resistant MFA for those accounts. Codes read out over the phone or approved in a push prompt can be talked out of someone. Hardware keys and passkeys are much harder to hand over.
- Separate broadcast and export permissions. Most people who work in these tools need neither. Grant them to a small named group and review it monthly.
- Add a second approver for mass sends. Many platforms support approval workflows for campaigns. Turn it on for audiences above a threshold.
- Train for impersonation of known contacts. ASOS's attacker posed as someone trusted. Give staff a simple rule: credentials and codes never go to anyone over chat, email or phone, no matter who asks, and suspicious requests go to a named team.
- Prepare a holding message. ASOS posted an in-app notice telling customers to ignore the rogue push. Have that wording and the authority to publish it ready in advance.
Why it matters
Customer messaging platforms sit outside most security reviews because they belong to marketing, not engineering. Yet they hold customer contact data and can reach every customer at once. In this case, customers first heard about the incident from the attacker's own push notification.
The control that matters most here is identity. If every customer-facing platform requires SSO with phishing-resistant MFA, and only a few people can export or broadcast, a single phished login does far less damage.
Try it yourself
Open the admin console of your push notification or email platform. Count the users who can send to your full audience and the users who can export customer data. If either number is higher than you would be comfortable defending to a regulator, cut it this week.
Click through it at your own pace, or open it full screen.
Quick check
How did the attacker get in, according to ASOS?
By impersonating a trusted contact to obtain an ASOS employee's login credentials, then using them to access third-party platforms used to communicate with customers.
Did ASOS confirm the Snowflake claim in the push notification?
No. The claim came from the attacker's message. ASOS has not confirmed it.
Were payment cards or passwords affected?
ASOS says it does not believe payment card information or account passwords were accessed.
