ASOS and the push notification that spoke for the attacker: secure the identities that talk to your customers

Updated 6 October 2026. This article separates what ASOS has confirmed from what has only been claimed, and will be updated as the facts develop.

At about 10am on 6 October 2026, people with the ASOS app received a push notification titled "ASOS HACKED". It was addressed to the company's data protection officer and IT team, claimed that ASOS's Snowflake instance had been "fully compromised", and warned: "Engage with us, or we will leak it." It arrived with the official app icon, through the official channel.

ASOS has said it is investigating unauthorised activity involving third-party platforms it uses to communicate with customers, and that it restricted access to its notification platforms. It said basic personal information, including names and contact details, may have been accessed, and that it does not believe payment card information or account passwords were affected. Its shares fell sharply on the news.

What is confirmed, and what is not

The unauthorised activity on third-party customer-communication platforms is confirmed by ASOS. The Snowflake compromise is a claim made in the notification, and a newly created Telegram channel, Xuanye Group Gateway, has been linked to it. ASOS has not confirmed that its Snowflake environment or customer data was breached. Security specialists have noted that app push notifications normally come from a system separate from a data warehouse such as Snowflake, so compromised credentials may have opened more than one system. Nobody outside ASOS knows yet how access was gained.

It is also ASOS's second security incident in about ten weeks. In notification letters dated 21 August 2026, ASOS's US business told 138,828 customers that an unauthorised party had accessed their accounts in late July using login credentials obtained outside ASOS: a credential-stuffing attack, in which passwords stolen from other services are reused.

These are two different identity failures, and most retailers are exposed to both.

The channel is an identity

A push notification platform holds a credential that can put words, under your brand, onto customers' phones in seconds. So do the platforms behind your marketing email, SMS and in-app messages. Whoever holds that API key or console login does not need to steal any data to do harm: they can message your customers more convincingly than any lookalike domain.

Yet these credentials rarely get the governance we give to domain administrators. They are created by a marketing or mobile team, pasted into a build pipeline or a vendor dashboard, and seldom rotated. They are non-human identities with enormous reach and, too often, no named owner.

The pattern is not new

• 2024, Snowflake customers. Mandiant traced a data-theft and extortion campaign against roughly 165 Snowflake customer organisations to credentials stolen by infostealer malware, some dating back to 2020. The accounts involved did not have multi-factor authentication, the stolen credentials were still valid, and there were no network allow lists limiting where sign-ins could come from. Snowflake is now phasing in mandatory MFA for all human users and blocking passwords for service accounts.
• 2025, Salesloft Drift. Attackers used OAuth tokens stolen from the Drift integration to exfiltrate data from Salesforce customer instances, then searched that data for further secrets such as AWS access keys and Snowflake tokens.
• 2022, Fast Company. A breach of the publisher's content management system gave access to its Apple News account, and offensive push notifications were sent to subscribers.

In each case the attacker did not break the platform. They used an identity the platform trusted.

What to check this week

1. List every system that can message your customers: push, email, SMS, in-app and chat. For each, record who and what can send (people, API keys, OAuth integrations, service accounts) and give each a named owner.
2. Treat send-capable keys as privileged. Keep them in a vault, not in app code or build variables. Rotate them on a schedule and when staff or suppliers change. Scope them: separate keys for transactional and marketing messages, send-only where the platform allows, and source IP restrictions where supported.
3. Put platform consoles behind single sign-on with phishing-resistant MFA, remove local password accounts, and drive joiners and leavers from your HR system.
4. Watch for stolen credentials. Monitor infostealer leaks for staff and contractor credentials, and when one appears, revoke that person's sessions and tokens, not just their password.
5. Review connected apps. List every OAuth integration with access to your CRM, data warehouse and messaging platforms; remove unused ones and reduce the scopes of the rest.
6. Make a send to every customer an approved action. Alert on unscheduled or all-audience sends, new API keys, audience exports and sign-ins from new locations, and require a second person to approve a send to everyone where the platform supports it.
7. Rehearse the kill switch. Know how to stop all outbound customer messaging within minutes, and how you will tell customers which messages are genuine.

And for customer accounts

July's account takeovers are the other half of the lesson. Check new and changed passwords against known breached passwords, rate-limit and challenge suspicious sign-in attempts, and offer passkeys, so that a password stolen elsewhere is no longer enough to get into an account.

The takeaway

Customers trust messages that arrive under your name. Every identity that can send those messages, human or machine, is part of your security perimeter. Inventory them, give them owners, limit what they can do, and watch them.

If you would like a second pair of eyes on which identities can reach your customers, get in touch.