Asos Push Alert Hack: What Was Sent and What Was Accessed
What shoppers saw
Asos shoppers received a push notification on Tuesday, 6 October 2026, claiming that Asos cloud services had been hacked. Engadget
The message was not written for shoppers. It was addressed to the company's data protection officer and IT staff. Engadget It said the Snowflake instance, a cloud database for storing and querying large customer data sets, had been fully compromised. It threatened a leak unless Asos engaged with the attackers, and included a link to a Telegram channel claiming to be operated by Xuanye Group.
Delivery came through the Asos app itself. App users across the UK received pop-up messages that appeared to have been sent by hackers. BBC Asos app users received the threatening notification on Tuesday. The Independent
What Asos said
Asos said it is investigating unauthorised activity involving third-party platforms it uses to communicate with customers. The company said it took immediate action to restrict access to the notification platforms. It is also investigating unauthorised access to its app system in connection with the shopper notifications. The Guardian Its app and website were operating as usual.
On exposure, Asos said customers' names and contact information may have been accessed in the hack. It said it does not believe payment details or passwords were compromised.
ASOS stock dropped 13% after the hacker push notification was sent through its mobile app. QZ
Why it matters
The broader context here is architectural. Push infrastructure, the separate service that sends app alerts, lives outside the core commerce stack but carries inside-level trust. A third-party service with permission to address every installed app can speak as the brand, bypass inbox filters and force an immediate incident response.
In my view, two separate compromises need to be kept distinct until logs say otherwise. One is established by delivery itself, unauthorised use of the customer messaging layer. The other remains an attacker assertion, full compromise of a Snowflake instance. The first gives the attacker leverage. The second still needs independent corroboration through warehouse access logs, credential scope review and data exfiltration telemetry, in other words records of who queried the database, what those logins allowed, and whether data left the system.
Worth flagging for anyone operating a similar stack, the claimed data set matters even if limited. Names plus contact information are sufficient for targeted follow-on phishing and SIM-swap pretexting, meaning tailored scam messages and tricks to take over a phone number, especially when the initial lure arrives as a legitimate push. The apps stayed online. That distinction matters. Operational continuity does not settle the question of prior read access to customer tables or notification provider exports.
If there is a constructive outcome, it is tighter isolation between systems that can message customers and systems that store customer data. Scoped API keys, short-lived OAuth grants, IP allowlisting for messaging providers and separate audit trails for warehouse queries, meaning limited software passwords, temporary access passes, approved-sender lists and independent query records, are now baseline controls, not hardening extras.
