In late August 2026, Klark experienced a security incident. An attacker exploited a vulnerability in Metabase, the data analysis tool we were using internally, and extracted data accessible through that tool.
We notified our customers individually from the very beginning, and we shared our post-incident report with them in early September. This article is intended for everyone else—prospects, partners, and support teams who are just getting to know us. It outlines the facts, the corrections we’ve made, and what we’ve learned from this incident.
We're publishing this because a company that handles its customers' conversations needs to be able to explain what happened when something goes wrong—without downplaying it or overreacting.
In short:
A critical vulnerability in Metabase (CVE-2026-72898, rated 10/10 on the CVSS scale) allowed an attacker to create an administrator account on our instance. With this account, the attacker was able to read and export data accessible through Metabase. This vulnerability affected Metabase instances exposed to the Internet that had not been updated.
The timeline:
| Date | Event |
|---|---|
| August 6 | Metabase Releases a Patch and a Critical Security Advisory |
| August 16 | Phase in which the attacker identifies our system |
| August 17 | Creation of an unauthorized administrator account |
| August 22–23 | Queries and Data Extraction Using Metabase APIs |
| August 24, 9:26 a.m. | Incident detected by the Klark team |
| August 24, 10:48 a.m. | All access to Metabase has been blocked |
| August 25 | Full notification to the CNIL |
| August 26 | Filing a complaint with the appropriate authorities |
One hour and 22 minutes elapsed between the detection and the blocking of access.
What was affected:
Metabase was connected to our read-only analytical databases. These permissions prevented any modifications or deletions, but did not prevent reading or exporting. The extracted data included fields from our clients' tools, logs of our AI model processing, conversation content, and technical configuration settings.
Some free-text content contained personal data. According to customers, this could include names, email addresses, phone numbers, and, in some cases, bank account information. Each affected customer received an analysis limited to the exact scope of their own data.
What was not affected:
On the day the issue was detected, we deleted the malicious account, invalidated all sessions, reset passwords, and revoked access tokens. Metabase was updated to a patched version.
As a precaution, we have also renewed the affected Klark API keys, which are now stored in encrypted form. We have retrieved the identified exfiltrated files to conduct an analysis on a client-by-client basis.
From a regulatory standpoint, the CNIL was notified the day after the breach was detected, and a complaint was filed. We received support from the Nouvelle-Aquitaine Region’s Cyber Incident Response Center.
What didn't work:
Our monitoring was based on CERT-FR bulletins. However, CERT-FR’s advisory on this vulnerability was released on August 24, even though Metabase had published its patch on August 6, and exploitation had already begun at our site on the 16th. We were relying on an intermediary, and that intermediary arrived too late.
What we've changed:
Since September 8, our automated monitoring system has been running every business day at 7:30 a.m. and 1:30 p.m. It currently draws on vendor advisories and release notes, GitHub Security Advisories, the CISA catalog of actively exploited vulnerabilities, the OSV database, OpenCVE, and CERT-FR. Each alert is cross-referenced with our inventory of actually deployed components.
A critical vulnerability triggers a named alert to the component manager, with a 4-hour resolution deadline. The deadlines are 7 days for a high-severity vulnerability, 30 days for a medium-severity vulnerability, and 90 days for a low-severity vulnerability. Each alert is time-stamped, from detection to resolution.
Our monitoring system now directly accesses publishers' releases, without waiting for them to be included in a CERT-FR advisory.
What didn't work:
Metabase was an internal tool, but it was accessible via the Internet and protected by a username and password. A vulnerability that allows users to create an account renders this protection useless.
What we've changed:
Metabase and all of our self-hosted internal tools are no longer accessible from the Internet. Access to them requires a dedicated VPN with single sign-on (SSO). If a new vulnerability were to allow someone to create an account on one of these tools before it is fixed, that account would not grant access to any data without going through this VPN.
What didn't work:
We had monitoring in place. However, the creation of an unknown administrator account and unusual exports did not trigger any actionable alerts. The incident was discovered by the team, not by an alert.
What we've changed:
We have implemented an alert that triggers whenever an account is created on our sensitive tools, as well as a system to detect abnormal exports. Both rules were validated through controlled tests: an account creation and an abnormal export each triggered an actionable alert.
What didn't work:
Our analytics databases contained personal data and technical fields that were not necessary for analytics tracking. Some data was also retained longer than necessary. The volume of data exposed was greater than it should have been.
What we've changed:
What didn't work:
Klark anonymizes personal data before processing it. This mechanism has significantly reduced the amount of personal data exposed. However, the post-incident analysis showed that it allowed residual data that it had not detected to slip through.
What we've changed:
We have implemented daily monitoring of masking rates to identify and correct any personal data that slips through the detection process. Thresholds and processing deadlines have been established, and the escalation procedure has been tested.
We have also rebuilt our knowledge base using a new architecture: detected identifiers are masked in the texts used to generate vector representations and in the stored content. This architecture is being rolled out on a client-by-client basis.
No detection technique is foolproof. Our goal is to minimize the amount of personal data exposed and to demonstrate this through measurement.
During an incident, it's tempting to wait until we have all the answers before speaking up. We did the opposite: we kept our customers informed from the very beginning, then provided additional details as we went along.
We shared our post-incident report with all of our active clients, in French and English. Each affected client received an analysis limited to its own data, so that it could in turn inform its teams and, if necessary, its own clients.
This transparency came at a cost. Some customers chose to stop or suspend their use of Klark, and we understand why. Others resumed using the service after reviewing our measures with their security teams. In any case, we believe this was the only way to proceed.
Three projects are currently underway:
No. The attack did not affect service availability. Some customers chose to temporarily suspend their use of Klark while the incident was being investigated.
No. The attacker had no direct access to our customers' tools. The integration secrets were encrypted and were not used; however, we renewed the affected keys as a precaution.
Yes, in a corrected version, accessible only through our VPN and restricted to approved analytical tables.
Each affected customer has received a personalized analysis. If you cannot find it, please contact your Klark representative or email contact@klark.ai.
We complete security questionnaires and can share our post-incident report as well as documentation of our security measures. Please request these during your initial conversation.
This incident has been the most challenging one Klark has ever faced. It cost us customers, and above all, it put a strain on the trust that brands place in us when they entrust us with their conversations.
We’ve learned six lessons from this: read information at its source, don’t share anything unnecessary online, be alerted at the right time, keep only the necessary data, be mindful of anonymization, and communicate quickly and fully.
We would like to thank the customers who have worked with us over the past few weeks—those who stayed with us, those who came back, and those who asked us challenging questions. They have made us better.
Nicolas, Yoann, and James, founders of Klark
Klark is a generative AI platform that helps customer service agents respond faster and more accurately, without changing their tools or workflows. Klark can be deployed in just a few minutes and is already used by more than 100 brands and 5,000 agents.
