Master of Malt had to tell its customers that their names, addresses, emails and phone numbers were in attackers' hands. Master of Malt was not hacked. Cooksongold asked its customers to have their payment cards replaced. Cooksongold was not hacked either. And on 21 September, the Nepal Stock Exchange suspended a full day of trading because a single data centre, shared by most of the country's brokers, had been encrypted by ransomware.
Three incidents in one week, three sectors, three countries, and the same mechanism: the organization paying for the incident is not the one that was attacked. It is the pattern we were already tracking in August with Ceva Logistics and the six Quebec and Ontario breaches. This week it goes one level deeper: the link that gave way is no longer the vendor, it is the vendor's vendor, or a log nobody was looking at.
The facts
Master of Malt: the key held by an app installed on the platform
Master of Malt is a UK online spirits retailer. Its store runs on BigCommerce, an e-commerce platform offering more than 1,200 third-party apps and integrations. Two of them, Ribon and Ribon 1.5, operated by Be A Part Of, a Fastr company, held a BigCommerce API key for the stores that had installed them.
Between 13 and 17 September, attackers used those credentials to inject malicious scripts into stores and access customer data: names, emails, phone numbers, shipping addresses. BigCommerce confirmed the compromise on 17 September, uninstalled the apps from affected stores and notified merchants. According to Master of Malt, the access lasted around a hundred hours before the key was disabled. Passwords and payment data, stored separately, were not touched.
Master of Malt is the only merchant named so far. BigCommerce has not disclosed how many stores or customers are affected.
What it changes. The chain has four links: the merchant, the platform, the app installed on the platform, and the key the app held. In most registers, an app added from a SaaS marketplace does not show up as a vendor. It is a configuration line, installed one day by the marketing team, and yet it holds read access to your customer base.
Cooksongold: a log that should never have existed
Cooksongold, a UK supplier of precious metals and jewellery-making materials, notified its customers on 25 September. The provider that handles 3-D Secure authentication for its card payments suffered unauthorized access on 12 September. What was accessed: a system log that had not been redacted, containing the full card number, expiry date and security code, along with the billing name, email, order number and amount. The period covered runs from 1 November 2025 to 12 September 2026, more than ten months of payments.
Cooksongold identified affected customers on 23 September, notified them two days later and is asking them to contact their bank to have their card replaced. The UK Information Commissioner's Office has been notified. The provider says it has fixed the logging.
What it changes. The control that failed is not a firewall: it is the automatic masking of sensitive data in logs, which did not apply. PCI DSS forbids retaining the card security code after authorization. The provider was retaining it without knowing, in a diagnostic file. No external security rating sees that. A precise question, asked of the right vendor, can.
The Nepal Stock Exchange: 72 of 90 brokers in the same data centre
On 20 September around 5:30 a.m., ransomware hit Data Hub, the data centre hosting the servers of 72 of the 90 brokerage houses registered with the Nepal Stock Exchange. Order management systems, systems tied to the central depository, payment gateways: all were taken offline. At the brokers' association's request, the exchange suspended trading on Monday 21 September. It resumed on the 22nd.
A full backup, isolated from the network, had been completed at 4 a.m., an hour and a half before the attack. That is what made a one-day recovery possible. The securities regulator set up an inspection committee and asked for its findings by 28 September.
What it changes. No broker was attacked individually. Each of them chose, one by one and for sound cost reasons, the same provider. Taken alone, each choice was reasonable. Added up, they created a single point of failure for an entire market. Regulators call it concentration risk, and it is exactly what Guideline B-10 from the Office of the Superintendent of Financial Institutions asks federally regulated institutions to assess: over-reliance on one third party by one institution, and a whole sector's reliance on the same third party.
What it changes in Canada
Two of these three incidents involve personal information. In Canada, the legal answer to "whose fault is it?" changes nothing about "who has to notify?". PIPEDA holds an organization accountable for the personal information it holds, including information it transfers to a third party for processing. In Quebec, Law 25 places the duty to notify the Commission d'accès à l'information and the people affected on the business that holds the information, even when the incident happened at its provider.
In other words, had a Quebec equivalent of Master of Malt suffered the same incident, its name would have been on the notice. And the cost follows: according to IBM's 2026 Cost of a Data Breach report, supply chain compromise is the factor that adds the most to the bill in Canada, about $367,900 more per incident, for a record average cost of $7.11 million.
Five actions for this week
- Inventory the apps installed on your SaaS platforms. E-commerce, CRM, office suite, ticketing tool: list the marketplace apps and OAuth integrations, who installed them, and what data they can read. Uninstall the ones nobody claims.
- Shrink and date the keys held by third parties. For every API key a third party holds in your environment: the minimum scope needed, the date of the last rotation, and the name of the person who revokes it on an alert. A hundred hours of access is the time to beat.
- Ask your payment and sensitive-data providers about logs. Can card data, social insurance numbers or health data end up in a diagnostic log, and how is masking verified? Add the question to your questionnaire.
- Look for your concentrations. Which providers do you share with most of your sector: hosting, payroll platform, payment provider, industry software? For each one, write down how you operate through a one-day outage.
- Prepare the letter you will sign for someone else's fault. A customer notice template for an incident at a vendor, the name of who notifies the Commission d'accès à l'information or the Privacy Commissioner, and a 72-hour notification clause in your contracts with the third parties that hold your data.
For points 1 and 3, the free vendor security questionnaire already covers logging, subprocessors and data location. To track continuously the third parties that can stop you, including the ones you did not choose, that is the job of the platform's third-party risk module. And for the vocabulary, our entry on third-party risk management.
Sources: BleepingComputer, BigCommerce and the Ribon apps · The Register, Master of Malt confirms the leak · Cooksongold, data breach notice of 24 September · Nepal News, the Nepal Stock Exchange and Data Hub · ICT Frame, the ransomware at Data Hub · OSFI, Guideline B-10 on third-party risk management · Office of the Privacy Commissioner, accountability principle · Benefits and Pensions Monitor, IBM 2026 report in Canada