Security and transparency

What happened

On 9 June 2025, security researcher Eric Daigle found a vulnerability in our service. One of our API endpoints accepted unauthenticated requests and did not sanitise one of its parameters, which allowed data to be extracted from the database through SQL injection.

What was extracted was, above all, the accounts table: email addresses and passwords stored in plain text. The dump also reached other tables linking accounts to devices, plus internal statistics.

The published figures differ depending on the source, so we give both: Have I Been Pwned recorded 61,641 accounts; the researcher and the press reported 62,050. We have no documented explanation for that difference. The records included accounts created as far back as 2018.

Two things here have no mitigating explanation and are our responsibility: those passwords should never have been stored in plain text, and that endpoint should never have been reachable without authentication.

What was exposed, and what was not

What was exposed: the panel email address and password for each customer account, in plain text, along with internal identifiers and creation and last-activity timestamps.

The captured content from supervised devices — messages, photos, audio, location — was not in the affected system: it was held on separate infrastructure, and what leaked was the user-management backend. But the other half has to be said plainly: the leaked password for each account is the panel password. Anyone holding those credentials could sign in to that account and see, from there, the content of the devices linked to it. That is why the incident is serious even though the content was not in the affected database — and why the password change should have been forced, not merely recommended.

On the figures in circulation: Have I Been Pwned lists the compromised data as "email addresses" and "passwords", which is the accounts table; TechCrunch described the database as also holding data from 26,000 devices. Both are compatible: alongside the accounts table, the dump reached tables linking accounts to devices. What was not in that database was the captured content.

What we did, and what we did too late

On 27 June 2025 the exploitation path was blocked with a web application firewall. Three days later the system was migrated: the endpoint began requiring authentication and passwords were no longer stored in plain text — they are hashed today.

Account holders were notified of the incident from within the control panel, with a recommendation to change their password.

And there are three things we did not do well. The notice was inside the panel: anyone who never logged back in never saw it, and an incident involving plain-text passwords called for an email to every account holder, not a message you have to go and find. The password change was recommended rather than forced, when the right move was to invalidate all of them. And we did not respond to the press: in July 2025 TechCrunch wrote to us in English and in Spanish, asking among other things whether we would tell our customers about the incident, and we did not answer. That silence was worse than any answer we could have given, and it is the reason this page exists.

If you had an account before July 2025

Your password at the time was exposed in plain text. Even though storage works differently now, treat that password as compromised.

Change it on CatWatchful from your panel. And change it on any other service where you reused it: that is the real risk of a plain-text password leak, and it is not your account here — it is your email or your bank if you repeated the same password.

You can check your address on Have I Been Pwned. Our incident is listed as a sensitive breach, so it can only be looked up by verifying that you own that email address.

If you think your phone was monitored without your knowledge

CatWatchful is a parental control tool and our terms prohibit using it on an adult without their consent. That does not change the fact that someone may have done so.

To check whether the app is installed on an Android phone: dial 543210 on the phone's keypad and press call. If it is installed, its settings screen opens.

Before uninstalling it, read this. If you suspect that whoever installed it may react with violence, removing the app can signal that you found out and increase the risk. Specialists in intimate partner violence recommend, in that situation, not uninstalling it immediately and seeking support first from a safe device — not the monitored phone.

If you want us to delete the data associated with your device, write to admin@catwatchful.com from a safe device.

How data is stored and deleted today

Passwords are stored hashed, not in plain text. The endpoint that was exploited requires authentication, and there is a web application firewall in front of it as well.

You can delete your account at any time from your own control panel. And captured device data is deleted automatically after 3 months, without you having to ask.

Timeline

1. 9 June 2025 — Eric Daigle finds the vulnerability.
2. 23 June 2025 — Google is notified.
3. 25 June 2025 — The hosting provider and the service operator are notified. The site goes down that same day.
4. 26 June 2025 — The service is restored on another domain, still vulnerable.
5. 27 June 2025 — Exploitation is blocked with a web application firewall.
6. 30 June 2025 — System migration: authentication on the endpoint and hashed passwords.
7. 2 July 2025 — Daigle publishes his write-up and TechCrunch its article.
8. 3 July 2025 — Have I Been Pwned records the breach and marks it sensitive.
9. 25 July 2025 — Google suspends the associated Firebase infrastructure.