Security incident: 4–6 October 2026
Last updated: 6 October 2026
Between 4 and 6 October 2026 an attacker got into our servers and could read our database
and the files stored on them. We have closed the hole they used, cut off their access and
replaced the keys and passwords our service relies on. This page explains what happened,
what information was involved and what you should do. All times are UTC.
What happened
The attacker exploited a flaw in how our website read one of its browser cookies. It let them
run commands on our web server. From there they found the login details of our other servers
and used them to sign in to those servers as an administrator. The database outage on
5 October was part of this: the attacker restarted our database.
- 4 October: automated probing of our website from the attacker's address begins.
- 5 October, about 01:30: the attacker first runs commands on our web server, then signs in to our other servers.
- 6 October, 03:25: the flaw is fixed on all our servers.
- 6 October: the attacker's access is removed, servers are switched to key-only logins, and the site's keys and passwords are replaced.
What information was involved
The attacker could read our database and the files on our servers, so we are treating all of it as exposed:
- Account details: name, email address, how you sign in (password, Google or GitHub), plan, credit balance and account settings.
- Passwords: we never store them in readable form, only as salted bcrypt hashes. A hash cannot be turned back into the password, but a short or common password can still be guessed by trying candidates against it.
- API keys: these were stored as they are, so anyone holding a copy can use your key until you replace it.
- Processing history: names of the files you uploaded, the models and settings you chose, transcriptions, the IP addresses jobs came from and API webhook URLs.
- Audio files: uploads and results that were on our servers at the time. We normally delete them after about three days.
- Payment records: amounts, dates, credits bought and the payment provider's transaction ID. Card details are entered on Paddle's and YooKassa's own payment pages and never reach our servers.
- Support tickets and the messages in them.
- Google Drive and Yandex Disk connections: the tokens that let us save results to your cloud storage. We have replaced the credentials those tokens depend on, so a copy of them no longer works.
What we have done
- Fixed the flaw on all our servers.
- Removed the attacker's access and switched our servers to key-only logins.
- Replaced the site's encryption key, our database passwords, our payment-provider keys and our Google, GitHub, Google Drive and Yandex Disk credentials.
- Signed out every saved "Remember me" login, so you may need to sign in again.
- We are still reviewing logs and hardening our systems, and will update this page if we learn more.
What you should do
- If you used your MVSEP password on any other site, change it there. You can also change it in your profile, or with a reset link.
- If you use the API, create a new key on the API page and update your scripts. Your old key keeps working until you do.
- If you connected Yandex Disk, you may need to connect it again. You can review which apps can reach your files in your Google and Yandex account settings.
- Be careful with emails that claim to be from MVSEP and ask for your password or a payment. We never ask for your password.
Questions
Write to us through support.
We are sorry this happened.
