Third-party data hosting has become the persistent breach vector for retail brands that long ago hardened their direct-customer infrastructure. The Zara data breach disclosed in April, and updated this month by BleepingComputer after Have I Been Pwned’s analysis of the leaked archive, exposed 197,400 customer records pulled from a former technology provider’s BigQuery instance using compromised authentication tokens.
- The ShinyHunters extortion gang claimed responsibility and published a 140GB archive of records pulled from BigQuery instances using compromised Anodot authentication tokens.
- Inditex says names, phone numbers, addresses, credentials, and payment data were not in the exposed set, which contained email addresses, geographic locations, purchase SKUs, order IDs, and support ticket origins.
- ShinyHunters has used the same Anodot-token pathway against dozens of brands recently, including Google, Cisco, Match Group, Vimeo, ADT, the European Commission, McGraw Hill, Medtronic, Carnival, 7-Eleven, and Instructure.
- The gang separately runs a vishing operation targeting employees and BPO agents at Microsoft Entra, Okta, and Google SSO consoles to harvest SaaS credentials across Salesforce, SAP, Slack, Atlassian, Zendesk, and Microsoft 365.
Inside the Zara data breach: 197,400 records via retired provider
Inditex, the Zara parent that also runs Bershka, Pull&Bear, Massimo Dutti, and Stradivarius across more than 1,500 stores, says the compromised databases sat with a former technology provider. The phrasing matters operationally. A provider that no longer has the contract often retains live credentials, hosted snapshots, and BigQuery exports the retailer no longer monitors. The 140GB ShinyHunters dump confirms the data was current enough to enable customer-level targeting at scale, including support ticket metadata that surfaces unresolved complaints and purchase histories useful for follow-on phishing.
The Anodot authentication token reuse is the procedural detail security teams should sit with. Anodot is an AI-driven business analytics platform; its tokens have read access to the retailer’s BigQuery warehouse for anomaly detection. Once ShinyHunters obtained those tokens, the warehouse exposure was a feature of the integration, not an exploited vulnerability. The same group has hit dating apps, edtech, retail, automotive, and pharma in other ShinyHunters campaigns using the same broad pathway. ShinyHunters told BleepingComputer that AI-based detection blocked equivalent attempts against Salesforce instances, which is a signal worth tracking: the same actors are encountering different control surfaces depending on where the SaaS vendor invested in behavioural anomaly detection.
What Inditex’s statement under-emphasizes is the inventory dimension. The Zara data breach is being described as historical (a former provider, a discontinued relationship), but the exposed records are recent enough that ShinyHunters could monetize them through retail-fraud pipelines targeting Inditex customers directly. The relevant question for CISOs reviewing third-party offboarding is whether their own retired-provider relationships still have live cloud tokens, live data, or live snapshots that surface a year or two after contract end.
Closing the offboarded-vendor exposure
The work sequences from data discovery to credential revocation to monitoring sunset. Each step gates the next: you cannot revoke what you have not discovered, and you cannot monitor what you assume is decommissioned.
Build a retired-vendor data inventory tied to contract close-out. Inditex’s “former technology provider” framing only works as a control if the security team can produce, on demand, the list of all data exports, BigQuery views, S3 snapshots, and tokens that any retired vendor ever touched. ShinyHunters succeeded against 197,400 records because the data was still discoverable and the tokens still authorised.
Treat SaaS analytics tokens as privileged credentials with mandatory rotation on relationship change. Anodot-style integrations granting BigQuery read access are functionally service accounts with persistent warehouse exposure. They belong inside the same rotation, monitoring, and just-in-time access controls applied to administrator credentials. Vendor offboarding workflows should fire token revocation as a hard precondition for contract close-out, with security verification rather than vendor self-attestation.
Add behavioural anomaly detection at the warehouse query layer. The ShinyHunters comment about Salesforce blocking equivalent attempts is the procedural opening. Salesforce’s AI-based detection catches token misuse patterns that look legitimate at the credential layer; the equivalent inspection at the BigQuery, Snowflake, or Redshift query layer is the control that closes the gap third-party tokens open. The Zara data breach exfiltrated 197,400 records through queries that authenticated correctly and did not, evidently, trip warehouse-side rate or volume anomalies, leaving customers exposed to follow-on retail fraud built on order histories and support ticket metadata pulled directly from the leaked archive.
Join our LinkedIn group Information Security Community!
