Fin août 2026, Klark a subi un incident de sécurité. Un attaquant a exploité une faille de Metabase, l'outil d'analyse de données que nous utilisions en interne, et a extrait des données accessibles depuis cet outil.
Nos clients ont été informés individuellement dès les premiers jours, et nous leur avons transmis notre rapport post-incident début septembre. Cet article s'adresse à tous les autres : prospects, partenaires, équipes support qui nous découvrent. Il reprend les faits, ce que nous avons corrigé, et ce que cet incident nous a appris.
Nous le publions parce qu'une entreprise qui traite les conversations de ses clients doit pouvoir expliquer ce qui s'est passé quand quelque chose tourne mal. Sans minimiser, sans dramatiser.
En bref :
Une faille critique de Metabase (CVE-2026-72898, notée 10/10 sur l'échelle CVSS) a permis à un attaquant de se créer un compte administrateur sur notre instance. Avec ce compte, il a pu lire et exporter les données accessibles depuis Metabase. Cette vulnérabilité concernait les instances Metabase exposées sur Internet et non mises à jour.
La chronologie :
| Date | Événement |
|---|---|
| 6 août | Metabase publie un correctif et un avis de sécurité critique |
| 16 août | Phase de reconnaissance de notre instance par l'attaquant |
| 17 août | Création d'un compte administrateur non autorisé |
| 22-23 août | Requêtes et extraction de données via les API de Metabase |
| 24 août, 9h26 | Détection de l'incident par l'équipe Klark |
| 24 août, 10h48 | Tous les accès à Metabase sont coupés |
| 25 août | Notification complète à la CNIL |
| 26 août | Dépôt de plainte auprès des autorités compétentes |
Entre la détection et la coupure des accès, il s'est écoulé 1 heure et 22 minutes.
Ce qui a été touché :
Metabase était relié à nos bases de données analytiques en lecture seule. Ces droits empêchaient toute modification ou suppression, mais pas la lecture ni l'export. Les données extraites comprenaient des champs issus des outils de nos clients, des journaux de traitement de nos modèles d'IA, des contenus de conversations et des éléments de configuration technique.
Certains contenus en texte libre contenaient des données personnelles. Selon les clients, il pouvait s'agir de noms, d'adresses email, de numéros de téléphone et, dans certains cas, d'identifiants bancaires. Chaque client concerné a reçu une analyse limitée au périmètre exact de ses propres données.
Ce qui n'a pas été touché :
Le jour de la détection, nous avons supprimé le compte malveillant, invalidé toutes les sessions, réinitialisé les mots de passe et révoqué les jetons d'accès. Metabase a été mis à jour vers une version corrigée.
Nous avons aussi renouvelé par précaution les clés d'API Klark concernées, désormais stockées chiffrées. Nous avons récupéré les fichiers exfiltrés identifiés pour mener l'analyse client par client.
Côté réglementaire, la CNIL a été notifiée le lendemain de la détection et une plainte a été déposée. Nous avons été accompagnés par le Centre de réponse aux incidents cyber de la région Nouvelle-Aquitaine.
Ce qui n'a pas fonctionné :
Notre veille reposait sur les bulletins du CERT-FR. Or l'avis du CERT-FR sur cette faille est paru le 24 août, alors que Metabase avait publié son correctif le 6 août, et que l'exploitation chez nous avait commencé le 16. Nous dépendions d'un intermédiaire, et l'intermédiaire est arrivé trop tard.
Ce que nous avons changé :
Depuis le 8 septembre, notre veille automatisée fonctionne chaque jour ouvré, à 7h30 et 13h30. Elle s'appuie aujourd'hui sur les avis des éditeurs et leurs notes de version, les GitHub Security Advisories, le catalogue CISA des vulnérabilités activement exploitées, la base OSV, OpenCVE et le CERT-FR. Chaque alerte est croisée avec notre inventaire des composants réellement déployés.
Une vulnérabilité critique déclenche une alerte nominative au responsable du composant, avec un délai de correction de 4 heures. Les délais sont de 7 jours pour une vulnérabilité élevée, 30 jours pour une moyenne et 90 jours pour une faible. Chaque alerte est horodatée, de la détection à la correction.
Notre veille consulte désormais directement les publications des éditeurs, sans attendre leur reprise dans un avis du CERT-FR.
Ce qui n'a pas fonctionné :
Metabase était un outil interne, mais il était accessible depuis Internet, protégé par un identifiant et un mot de passe. Une faille qui permet de créer un compte rend cette protection inutile.
Ce que nous avons changé :
Metabase et l'ensemble de nos outils internes auto-hébergés ne sont plus accessibles depuis Internet. Leur accès passe par un VPN dédié, avec authentification unique (SSO). Si une nouvelle faille permettait demain de créer un compte sur l'un de ces outils avant sa correction, ce compte ne donnerait accès à aucune donnée sans passer par ce VPN.
Ce qui n'a pas fonctionné :
Nous avions une surveillance en place. Pourtant, la création d'un compte administrateur inconnu et des exports anormaux n'ont pas déclenché d'alerte exploitable. L'incident a été découvert par l'équipe, pas par une alarme.
Ce que nous avons changé :
Nous avons mis en place une alerte à chaque création de compte sur nos outils sensibles, ainsi qu'une détection des exports anormaux. Les deux règles ont été validées par des tests contrôlés : une création de compte et un export anormal ont chacun déclenché une alerte exploitable.
Ce qui n'a pas fonctionné :
Nos bases analytiques contenaient des données personnelles et des champs techniques dont le suivi analytique n'avait pas besoin. Certaines données étaient aussi conservées plus longtemps que nécessaire. Le volume exposé a été plus important qu'il n'aurait dû l'être.
Ce que nous avons changé :
Ce qui n'a pas fonctionné :
Klark anonymise les données personnelles avant de les exploiter. Ce mécanisme a fortement réduit la quantité de données personnelles exposées. Mais l'analyse post-incident a montré qu'il laissait passer des données résiduelles qu'il n'avait pas détectées.
Ce que nous avons changé :
Nous avons mis en place un contrôle quotidien des taux de masquage, pour repérer et corriger les données personnelles qui échappent à la détection. Les seuils et les délais de traitement sont définis, et la procédure d'escalade a été testée.
Nous avons aussi reconstruit notre base de connaissances avec une nouvelle architecture : les identifiants détectés sont masqués dans les textes utilisés pour produire les représentations vectorielles et dans les contenus conservés. Cette architecture est déployée client par client.
Aucune technique de détection n'est infaillible. Notre objectif est de réduire au minimum la part de données personnelles exposée, et de le prouver par la mesure.
Pendant un incident, la tentation est d'attendre d'avoir toutes les réponses avant de parler. Nous avons fait l'inverse : informer nos clients dès les premiers jours, puis compléter au fur et à mesure.
Nous avons partagé notre rapport post-incident avec tous nos clients actifs, en français et en anglais. Chaque client concerné a reçu une analyse limitée à ses propres données, pour pouvoir informer à son tour ses équipes et, si nécessaire, ses propres clients.
Cette transparence a eu un coût. Certains clients ont choisi d'arrêter ou de suspendre leur utilisation de Klark, et nous le comprenons. D'autres ont repris le service après avoir examiné nos mesures avec leurs équipes sécurité. Dans tous les cas, nous pensons que c'était la seule façon de faire.
Trois chantiers se poursuivent :
Non. L'attaque n'a pas affecté la disponibilité du service. Certains clients ont choisi de suspendre temporairement l'utilisation de Klark le temps d'analyser l'incident.
Non. L'attaquant n'a eu aucun accès direct aux outils de nos clients. Les secrets d'intégration étaient chiffrés et n'ont pas été utilisés ; nous avons tout de même renouvelé les clés concernées par précaution.
Oui, dans une version corrigée, accessible uniquement via notre VPN et restreinte aux tables analytiques approuvées.
Chaque client concerné a reçu une analyse individuelle. Si vous ne la retrouvez pas, écrivez à votre interlocuteur Klark ou à contact@klark.ai.
Nous répondons aux questionnaires sécurité et nous pouvons partager notre rapport post-incident ainsi que la documentation de nos mesures. Demandez-les lors de votre premier échange.
Cet incident est le plus difficile que Klark ait traversé. Il nous a coûté des clients, et il a surtout mis à l'épreuve la confiance que des marques nous accordent en nous confiant leurs conversations.
Nous en retenons six leçons : lire l'information à la source, ne rien exposer d'inutile sur Internet, être alerté au bon moment, ne garder que les données nécessaires, mesurer l'anonymisation, et dire les choses vite et en entier.
Nous remercions les clients qui ont travaillé avec nous pendant ces semaines, ceux qui sont restés, ceux qui sont revenus, et ceux qui nous ont posé des questions exigeantes. Elles nous ont rendus meilleurs.
Nicolas, Yoann et James, fondateurs de Klark
Klark est une plateforme d'IA générative qui aide les agents du service client à répondre plus vite, plus précisément, sans changer leurs outils ni leurs habitudes. Déployable en quelques minutes, Klark est déjà utilisé par plus de 100 marques et 5 000 agents.
