Double Counter suffered a data breach attributed to a vulnerability in the Metabase analytics tool

The attacker’s last action in our cloud infrastructure was recorded at 17:54 on 4 October. A full audit found no backdoor left behind. Double Counter was restored at 19:19 with new credentials and is under continuous monitoring.

On 4 October 2026, Double Counter was the target of a deliberate, multi-stage attack. The attacker broke into a server from our hosting setup through a vulnerability in an analytics tool it was still running, then used credentials found on that server to reach our cloud infrastructure and adapted to each of our containment steps. During the attack they took control of the bot’s Discord token, used it to post links to their own Discord server in 50 large servers, copied part of one of our databases, and used a stolen payment key to commit financial fraud on a separate account.

We cut off their access, found no persistence, replaced the exposed credentials and restored the service at 19:19. We sincerely apologise to everyone affected.

5 h 51 min of attacker activity in our cloud (12:03 → 17:54).

12 GB copied from one of our databases (15:09 → 15:34).

50 large servers where the bot posted the attacker’s links.

$7,316 in fraudulent charges on a separate payment account. Customer funds are safe.

How the attack unfolded

1 Initial access The entry point was an old server from our OVH hosting setup. It was no longer in use and no longer linked to the operational Double Counter service. The attacker probed it from rotating VPN addresses starting on 3 October at 04:37, then worked methodically through a list of usernames — root, nathan, debian, and service names such as analytics-sync and metabase — before logging in at 00:47 on 4 October; the login took only a few tries once they reached the right account. The way in was a self-hosted analytics tool (Metabase) that was still running, and publicly reachable, on that retired server: a vulnerability in it let the attacker forge an administrator session and, through it, reach the host and the credentials used to log in — rather than a password leaked from our source code, which contains none. The server held two credentials for our cloud: the key of a service account (a non-human identity our services use to talk to the cloud, here with administrator rights) and an administrator’s saved command-line session. The attacker created no new account; they used these two existing, legitimate credentials, which is part of why their activity initially blended in.

The entry point was an old server from our OVH hosting setup. It was no longer in use and no longer linked to the operational Double Counter service. The attacker probed it from rotating VPN addresses starting on 3 October at 04:37, then worked methodically through a list of usernames — root, nathan, debian, and service names such as analytics-sync and metabase — before logging in at 00:47 on 4 October; the login took only a few tries once they reached the right account. The way in was a self-hosted analytics tool (Metabase) that was still running, and publicly reachable, on that retired server: a vulnerability in it let the attacker forge an administrator session and, through it, reach the host and the credentials used to log in — rather than a password leaked from our source code, which contains none. The server held two credentials for our cloud: the key of a service account (a non-human identity our services use to talk to the cloud, here with administrator rights) and an administrator’s saved command-line session. The attacker created no new account; they used these two existing, legitimate credentials, which is part of why their activity initially blended in.

2 Entry into the cloud (12:03) With the service-account key, the attacker added their own SSH key to the project (12:08) and exported one of our databases into a storage bucket they created (12:19–12:35). That export was never downloaded.

Entry into the cloud (12:03)

With the service-account key, the attacker added their own SSH key to the project (12:08) and exported one of our databases into a storage bucket they created (12:19–12:35). That export was never downloaded.

3 Control of the Discord bot (12:26) They opened a shell inside a running bot container and read the bot token. On our support server they used it to give their account Administrator rights (13:24) and to unban it after our staff banned it (13:33), and from 13:30 they used it to post links to their own Discord server in 50 large servers that use Double Counter.

Control of the Discord bot (12:26)

They opened a shell inside a running bot container and read the bot token. On our support server they used it to give their account Administrator rights (13:24) and to unban it after our staff banned it (13:33), and from 13:30 they used it to post links to their own Discord server in 50 large servers that use Double Counter.

4 Adapting to our response (14:46–15:34) When we set a new bot token, they read it within two minutes. They then deleted backups they had created, changed the database administrator password to lock our services out (15:09), and started copying the databases they could find from a cloud-hosted machine until we located and terminated their session (15:34).

Adapting to our response (14:46–15:34)

When we set a new bot token, they read it within two minutes. They then deleted backups they had created, changed the database administrator password to lock our services out (15:09), and started copying the databases they could find from a cloud-hosted machine until we located and terminated their session (15:34).

5 Fallback credential (15:54–17:54) When we revoked the service-account key, they switched to the administrator session taken from the same server, re-added their SSH key and connected to the database again, without any measurable data transfer. All sessions of that account were revoked at 17:55.

Fallback credential (15:54–17:54)

When we revoked the service-account key, they switched to the administrator session taken from the same server, re-added their SSH key and connected to the database again, without any measurable data transfer. All sessions of that account were revoked at 17:55.

Times marked ≈ are accurate to within a few minutes; all others come from system logs.

Personal data affected

The copy tool works through that database in a fixed order, so by comparing the ≈12 GB that left with the size of each table we can assess what was copied. The figures below cover personal data, including, for completeness, data held outside that database. Counts are approximate.

The IP-address records sit in two tables. The first (alt detection, ≈5.4 M) was copied in full. The second (verified users, ≈21.7 M) was being copied when we ended the session: from the volume transferred we estimate that 20% had left, and because we cannot tell which rows, we treat the whole set as exposed.

Not affected: our cold storage, a separate database of user data and IP addresses for ≈ 58 M users (including only ≈ 800k email addresses). It is used by some of our other processes but not by the main verification process, is kept outside the infrastructure involved in this incident, and was not affected. Our behavioural data database was stored elsewhere and is confirmed to be unaffected and not accessed. Discord passwords, which Double Counter never receives, and stored payment card details, which are held by our payment provider, were not in the affected database either. The payment account that processes Double Counter and Doogle subscriptions shows no unauthorised charges; the payment fraud described below hit a separate account.

Among the secrets the attacker could read in our cloud was the payment-provider (Stripe) key of a separate Tellter product, Atis. They used it to commit financial fraud on that account on 4 October, between 17:11 and 17:12:

A series of escalating test charges ($1, $10, $100, $1,000) against one of our own company cards, totalling $7,316 .

Two small charges, $3 and $15 , to two of that product’s customers. Both have been refunded in full.

Only three cards were charged in total — one of our own and two customers’ — and no other customers were affected. We revoked every payment-provider key at 17:14, rotated the credentials and secured the accounts. All customer funds are safe. No stored card numbers were exposed: the payment provider holds those, and the attacker acted through the account, not the card data.

Impact on Discord servers

Links to the attacker’s server. The bot posted invitations to the attacker’s Discord server in 50 large servers that use Double Counter, based on the reports we have received. These messages appeared as sent by Double Counter. The largest server targeted was “Steal a brainrot”. Substantially all of these messages have been deleted, by us or by each server’s moderation team. We are not linking to the attacker’s server here.

Our support server. Administrator rights and fifteen roles granted to the attacker’s account (Discord ID 931487207443804161 ), one unban, and invitations posted through two webhooks.

Messages sent with the stolen token went straight to Discord without passing through our systems, so we identified the affected servers from the reports we received and from the bot’s own message history.

Disabled, then deleted, the stolen service-account key, and stripped its account of every right.

Revoked all sessions of the administrator account whose saved login was on the server.

Removed the attacker’s SSH key, shut down the legacy OVH server, and removed its access to our source code.

Reset the bot token and deleted all ten Discord webhooks whose addresses could have been exposed.

Closed the affected database to the internet: it now accepts only authenticated connections from our own services.

Migrated the cache database off the third-party, internet-facing host it used onto a private network inside our own cloud, with no public address.

Disabled the over-privileged service account. No long-lived service-account key remains in our cloud project.

Replaced the credentials the attacker could have read: the bot token, the database and cache passwords, every session-signing key (which signed everyone out), our payment-provider keys and webhook secrets, our Discord application secrets and our AI provider keys. The keys of our remaining third-party providers are being rotated.

Signed every staff member out of our internal staff panel and started resetting staff credentials.

The bot token and the Discord webhooks now live in a dedicated secret store, never in our code.

Audited 14 cloud projects for persistence: no key, account, permission, machine, scheduled job or container image was left behind by the attacker.

Turned on logging of every read of our stored secrets, alerting on any sensitive change to our cloud, and real-time monitoring of the permissions the bot grants, with continuous monitoring since the service was restored.

Server administrators

Delete any message sent by Double Counter on 4 October between 12:00 and 16:30 UTC that invites people to another server.

Check your audit log for actions by Double Counter in that window.

Nothing to change on your Discord account.

Don’t join servers advertised in unexpected messages from Double Counter.

If you verified between 13:39 and 14:49 UTC without getting your role, verify again.

Doogle, Atis, advertiser and API customers

Doogle users, advertisers and API customers: your email address was exposed, so expect phishing attempts.

Atis customers: no action is needed. The two charges made during the incident have been refunded and your funds are safe.

We never ask for passwords, tokens or payment by email or private message.

Legal and notifications

We notified the French data protection authority (CNIL) on 5 October 2026, under reference FR2610050000001 .

We have engaged legal counsel and are pursuing those responsible in both France and the United States. A criminal complaint is being filed, and our lawyers are building the case on platform and Discord logs, direct-message screenshots, and technical indicators collected from our own systems.

For questions or personal-data requests, write to [email protected] , use the bot’s /privacy command, or reach us on our support server . We will update this page when the investigation concludes.

INC-2026-10-04 · Version 1.9 · Last updated 5 October 2026 · Tellter SAS, operator of Double Counter. This report reflects what we know at the time of writing and will be updated as the investigation progresses.