Master of Malt a dû prévenir ses clients que leurs noms, adresses, courriels et numéros de téléphone étaient entre les mains d'attaquants. Master of Malt n'a pas été piraté. Cooksongold a demandé aux siens de faire remplacer leur carte bancaire. Cooksongold n'a pas été piraté non plus. Et le 21 septembre, la Bourse du Népal a suspendu une journée entière de transactions parce qu'un seul centre de données, partagé par la plupart des courtiers du pays, était chiffré par un rançongiciel.
Trois incidents en une semaine, trois secteurs, trois pays, et le même mécanisme : l'organisation qui paie la facture de l'incident n'est pas celle qui a été attaquée. C'est le motif que nous suivions déjà en août avec Ceva Logistics et les six brèches du Québec et de l'Ontario. Cette semaine, il descend d'un cran : le maillon qui a cédé n'est plus le fournisseur, c'est le fournisseur du fournisseur, ou un journal que personne ne regardait.
Les faits
Master of Malt : la clé d'une application installée sur la plateforme
Master of Malt est un marchand britannique de spiritueux en ligne. Sa boutique tourne sur BigCommerce, une plateforme de commerce électronique qui propose plus de 1 200 applications et intégrations tierces. Deux d'entre elles, Ribon et Ribon 1.5, exploitées par Be A Part Of, une marque du groupe Fastr, détenaient une clé d'API BigCommerce pour les boutiques qui les avaient installées.
Entre le 13 et le 17 septembre, des attaquants ont utilisé ces identifiants pour injecter des scripts malveillants dans des boutiques et accéder aux données des clients : noms, courriels, numéros de téléphone, adresses de livraison. BigCommerce a confirmé la compromission le 17 septembre, désinstallé les applications des boutiques touchées et prévenu les marchands. Selon Master of Malt, l'accès a duré une centaine d'heures avant que la clé soit désactivée. Les mots de passe et les données de paiement, stockés séparément, n'ont pas été touchés.
Master of Malt est le seul marchand nommé à ce jour. BigCommerce n'a publié ni le nombre de boutiques ni le nombre de clients concernés.
Ce que ça change. La chaîne compte quatre maillons : le marchand, la plateforme, l'application installée sur la plateforme, et la clé que détenait l'application. Dans la plupart des registres, une application ajoutée depuis la place de marché d'un SaaS n'apparaît pas comme un fournisseur. Elle est une ligne de configuration, installée un jour par l'équipe marketing, et elle détient pourtant un accès en lecture à votre base clients.
Cooksongold : un journal qui n'aurait jamais dû exister
Cooksongold, fournisseur britannique de métaux précieux et de matériel de bijouterie, a prévenu ses clients le 25 septembre. Le prestataire qui gère pour lui l'authentification 3-D Secure des paiements par carte a subi un accès non autorisé le 12 septembre. Ce qui a été consulté : un journal système qui n'avait pas été expurgé, et qui contenait le numéro complet de la carte, sa date d'expiration et son cryptogramme, avec le nom de facturation, le courriel, le numéro et le montant de la commande. La période couverte va du 1er novembre 2025 au 12 septembre 2026, soit plus de dix mois de paiements.
Cooksongold a identifié les clients touchés le 23 septembre, les a prévenus deux jours plus tard et leur demande de contacter leur banque pour faire remplacer leur carte. Le commissaire britannique à l'information a été saisi. Le prestataire indique avoir corrigé la journalisation.
Ce que ça change. Le contrôle qui a échoué n'est pas un pare-feu : c'est le masquage automatique des données sensibles dans les journaux, qui ne s'est pas appliqué. La norme PCI DSS interdit de conserver le cryptogramme après l'autorisation. Le prestataire le conservait sans le savoir, dans un fichier de diagnostic. Aucune note de sécurité externe ne voit ça. Une question précise, posée au bon fournisseur, le peut.
La Bourse du Népal : 72 courtiers sur 90 dans le même centre de données
Le 20 septembre vers 5 h 30, un rançongiciel a frappé Data Hub, le centre de données qui héberge les serveurs de 72 des 90 maisons de courtage inscrites à la Bourse du Népal. Systèmes de gestion des ordres, systèmes liés au dépositaire central, passerelles de paiement : tout a été mis hors ligne. À la demande de l'association des courtiers, la Bourse a suspendu les transactions le lundi 21 septembre. Elles ont repris le 22.
Une sauvegarde complète, isolée du réseau, avait été terminée à 4 h, une heure et demie avant l'attaque. C'est elle qui a rendu la reprise en un jour possible. Le régulateur des valeurs mobilières a formé un comité d'inspection et demandé ses conclusions pour le 28 septembre.
Ce que ça change. Aucun courtier n'a été attaqué individuellement. Ils ont tous choisi, un par un et pour de bonnes raisons de coût, le même prestataire. Pris isolément, chacun de ces choix était raisonnable. Additionnés, ils ont créé un point unique de défaillance pour tout un marché. C'est ce que les régulateurs appellent le risque de concentration, et c'est précisément ce que la ligne directrice B-10 du Bureau du surintendant des institutions financières demande aux institutions fédérales d'évaluer : la dépendance excessive à un tiers pour une institution, et celle de tout un secteur à un même tiers.
Ce que ça change au Canada
Deux de ces trois incidents touchent des renseignements personnels. Au Canada, la réponse juridique à la question « à qui la faute ? » ne change rien à celle de « qui doit prévenir ? ». La LPRPDE rend l'organisation responsable des renseignements personnels qu'elle détient, y compris ceux qu'elle confie à un tiers pour traitement. Au Québec, la Loi 25 fait peser l'obligation d'aviser la Commission d'accès à l'information et les personnes concernées sur l'entreprise qui détient les renseignements, même quand l'incident a eu lieu chez son prestataire.
Autrement dit, si l'équivalent québécois de Master of Malt avait subi le même incident, c'est son nom qui aurait figuré sur l'avis. Et le coût suit : selon le rapport IBM 2026 sur le coût d'une brèche, la compromission de la chaîne d'approvisionnement est le facteur qui alourdit le plus la facture au Canada, environ 367 900 $ de plus par incident, pour un coût moyen record de 7,11 millions de dollars.
Cinq actions pour cette semaine
- Inventoriez les applications installées sur vos plateformes SaaS. Commerce électronique, CRM, suite bureautique, outil de tickets : listez les applications de la place de marché et les intégrations OAuth, qui les a installées, et quelles données elles peuvent lire. Désinstallez celles que personne ne revendique.
- Réduisez et datez les clés détenues par des tiers. Pour chaque clé d'API qu'un tiers détient chez vous : la portée minimale nécessaire, la date de la dernière rotation, et le nom de la personne qui la révoque en cas d'alerte. Cent heures d'accès, c'est le délai à battre.
- Posez la question des journaux à vos prestataires de paiement et de données sensibles. Les données de carte, les numéros d'assurance sociale ou les données de santé peuvent-ils apparaître dans un journal de diagnostic, et comment le masquage est-il vérifié ? Ajoutez la question au questionnaire.
- Cherchez vos concentrations. Quels prestataires partagez-vous avec la majorité de votre secteur : hébergeur, plateforme de paie, fournisseur de paiement, logiciel sectoriel ? Pour chacun, écrivez le mode dégradé d'une journée d'arrêt.
- Préparez la lettre que vous signerez pour la faute d'un autre. Un gabarit d'avis aux clients pour un incident survenu chez un fournisseur, le nom de qui avise la Commission d'accès à l'information ou le Commissariat, et une clause de notification sous 72 heures dans vos contrats avec les tiers qui détiennent vos données.
Pour les points 1 et 3, le questionnaire de sécurité fournisseur gratuit couvre déjà la journalisation, les sous-traitants et la localisation des données. Pour suivre en continu les tiers qui peuvent vous arrêter, y compris ceux que vous n'avez pas choisis, c'est le rôle du module Risque tiers de la plateforme. Et pour le vocabulaire, notre fiche sur la gestion du risque tiers.
Sources : BleepingComputer, BigCommerce et les applications Ribon · The Register, Master of Malt confirme la fuite · Cooksongold, avis d'atteinte aux données du 24 septembre · Nepal News, la Bourse du Népal et Data Hub · ICT Frame, le rançongiciel chez Data Hub · BSIF, ligne directrice B-10 sur la gestion du risque lié aux tiers · Commissariat à la protection de la vie privée, principe de responsabilité · Benefits and Pensions Monitor, rapport IBM 2026 au Canada