As always, when we at Kolab Now has experienced an incident with some severity, we reveal what has happened in an incident report like this. We do that in the name of Transparency.

On Sunday 2026-10-11 in the afternoon CEST the Kolab Now team was alerted by monitoring on a few security controls being touched. A few rate-limitations were broken and some jobs were repeated a few times too much. Checking into the issue it was found that malicious actors (human or alien) made a large amount of password reset requests.

The password reset feature (a link at the login in page) was created to make it easier for users who forgot their password to get it reset in a (relatively) fast and safe operation. In big lines it looks like this:

* Link (“forgot password”) is clicked, a new page is asking for the account to reset password for

* A mail with a short code is sent to the recovery address together with a link to the password change page

* The password change page address (the underlying API) contains a long code and the user has the short code from the email to enter.

* If the two codes match, the user is allowed to change the password

A lot of attention was paid to the user comfort, as the previous system was requiring a lot of interaction with Support, and users found that it was jumping through inconvenient loops.

The  actors (human or alien) were on Sunday making an effort to request password reset links to the password reset APIs, then guess the short codes, and finally change the passwords.  This was obviously not the intention with the process, and Operations immediately took actions to halt the activities. Access to the password reset feature was blocked.

When it was clear that the activities had stopped, and no more guessing was happening, the systems were evaluated and logs trawled. It was found that 16 user accounts had their password changed during the activities. Operations right away changed the password for those user accounts to make sure that there was no access to those; not even for the correct owners. The team also contacted the users on the recovery email addresses (‘External Email Address’) to let them know what had happened.

During the activities, the malicious actors hit several security controls like rate-limitations, and monitoring alarmed about the irregular traffic. To mitigate the situation, the Kolab Now team implemented more controls, made monitoring more stringent and increased the length and size of secrets. They added extra API request rate-limit, introduced password-reset code verification limit (auto-lock), and the codes was made longer.  This made it secure to reopen the reset password feature so that users who had been contacted could reset their passwords themselves in a safe manner.

Where as we created the password reset feature to be as easy and comfortable to use as possible within the frames of secure operation, we also realize, that just increasing values and numbers to be guessed is not enough. We are redesigning the feature from the bottom up so that it, as the rest of Kolab, can be designed and built for security rather than comfort. More details about that will be revealed in a follow up post here on this blog at a later time.

Should you have any questions or concerns in this context, then please contact support.