ASOS's "Hacked" Push Notification Named Snowflake. ASOS and Snowflake Both Say That's Not What Happened.
What ASOS has actually confirmed — a social-engineered employee login and "names and contact details" — is narrower than what the attacker told the BBC it stole. Here's where the two accounts split.
CVE Tools7 min read
On October 6, 2026, millions of ASOS app users got a push notification that read: "Dear Asos DPO and IT, we have fully compromised the Snowflake instance. Engage with us, or we will leak it." It was signed by a Telegram handle, "xuanyewengateway," and it came from ASOS's own app — the company's own trusted channel, weaponized to deliver an extortion threat to its own customers.
Four days of reporting later, two things are clear and one thing isn't. ASOS has confirmed a breach, caused by social engineering, that exposed "names and contact details." Snowflake has flatly denied its platform was compromised at all. And the specific system the attacker says they actually broke into — an AI marketing tool called Simon AI — has not been confirmed by ASOS, by Snowflake, or by the company that now owns Simon AI. It comes from one place: the attacker's own account, given directly to a BBC reporter over Telegram.
The attack chain ASOS actually describes
Strip away the Snowflake framing in the notification itself, and ASOS's own account of how this started is a straightforward credential-theft story: someone impersonated a "trusted contact" to talk an ASOS employee into handing over login credentials for a work account. Those credentials gave the attacker access to "third-party platform(s) used to communicate with customers" — ASOS's phrase, not a named product. From there, the attacker had two things at once: a way to read customer data, and a way to send messages through ASOS's own customer-facing channels.
How one stolen login became a customer-facing extortion message
- Attacker impersonates a "trusted contact"
- ASOS employee hands over account login credentials
- Attacker logs into a third-party customer-comms platform
- Same access, two uses
- Read/exfiltrate customer data
- Hijack push-notification channel to send extortion message to customers
Where ASOS and the attacker's account diverge
ASOS's confirmed scope and the attacker's claimed haul are not the same list. One comes from a public company's regulatory filing; the other comes from a Telegram channel that didn't exist under its current name until the day of the attack, relayed through a single reporter's conversation. Both are worth stating plainly, side by side — and neither should be mistaken for the other.
Confirmed vs. claimed
- Employee login credentials obtained via "trusted contact" impersonation (social engineering)
- Access to unnamed "third-party platform(s) used to communicate with customers"
- Names and contact details "may have been accessed"
- No evidence payment-card data or account passwords were impacted
- App, website and core operations unaffected
- Claims to have breached "Simon AI," a marketing platform connected to Snowflake — not Snowflake's own platform
- Claims to hold names, addresses, phone numbers, emails, and customer account numbers
- Claims to also hold dates of birth and on-site search-history terms (sample shown to BBC)
- Claims no payment-card data was taken
- Claims the data is "safe on our server" and won't be released for a "designated period"
This issue did not in any way result from a vuln, weakness, flaw or misconfiguration with the Snowflake service, platform or internal environments, and was not caused by Snowflake. No remediation is required for Snowflake customers.
That statement directly rebuts the wording of the push notification itself ("we have fully compromised the Snowflake instance"). Using someone's stolen employee credentials to log into a SaaS tool that happens to sit on top of Snowflake's infrastructure is not the same thing as a vulnerability in Snowflake — and Snowflake is drawing that line explicitly, distinguishing this from the 2024 wave of breaches where attackers used credential-stuffing to log directly into customers' own Snowflake accounts.
How the story moved from notification to denial in three days
- A Telegram presence later tied to "Xuanye Group" is active under earlier aliasesGroup-IB traced the account's history to prior handles, including JohnCZ and Moon Transfers, before it settled on @xuanyegroup.
- Rogue "HACKED" push notification sent via ASOS's own appClaims to have "fully compromised the Snowflake instance"; signed by Telegram handle xuanyewengateway.
- ASOS issues its first statement and LSE filingConfirms investigating "unauthorised activity involving third-party platforms"; restricts access to the notification platforms.
- Reporters trace the Telegram account's historyInfosecurity Magazine links the handle to earlier aliases on the same Telegram ID.
- ASOS confirms fuller detail; BBC interviews the attacker directlyASOS emails customers confirming names and contact details may have been accessed. Separately, BBC's Joe Tidy gets the Simon AI / DOB / search-history claims directly from the attacker over Telegram.
- BBC publishes; Snowflake issues its on-record denialSnowflake states its platform was not compromised and distinguishes the incident from 2024's credential-stuffing wave.
This is the same playbook, again
Compromising a vendor's marketing or customer-communications platform and then using that platform's own legitimate channel to blast a message straight to the victim's customers isn't new. In a prior incident, fintech firm Betterment was compromised through a marketing-platform integration and used to send a fraudulent crypto-themed message to its customers — also exposing names, emails and phone numbers. The mechanism is the same: the attacker doesn't need to breach the retailer's core systems at all. A single marketing-SaaS credential gets them data, a megaphone, and a way to bypass the company's own crisis-communications process in one move.
- Audit which third-party marketing/communications platforms (CDPs, personalization tools, notification senders) can trigger messages directly to your customers, and under what credentials
- Treat "someone impersonating a trusted contact" as a live phishing/social-engineering vector against the specific employees who hold vendor-platform logins, not just against finance or IT generally
- Confirm whether MFA is enforced on every such third-party integration account — not just on your own core identity provider
- Have a plan to revoke a vendor-platform session and lock out its send capability within minutes, not hours — the exposure window here was the entire time the stolen credential remained valid
- Don't let a victim-facing claim ("we compromised Snowflake") go unchallenged in your own incident comms if your own investigation doesn't support it — ASOS and Snowflake both corrected that framing within days
Reporting current as of 2026-10-13live record →