Thank you for Making ZITADEL More Secure

Our Journey: Enhanced Security and Transparency

We are committed to transparency, and that is why we want to give a brief update on the recent security advisories that we issued for ZITADEL.

Let’s start with a couple of figures from this year. We started the year with around 2,000 GitHub stars and grew to more than 5,500 in the last 11 months. Our community on Discord had around 100 members, and now we have more than that online around the clock, with over 1,300 members in the channel. Container downloads grew to over 400,000 this month.

We’ve been growing as a community and open-source project, as a cloud service, and as an organization. With growth come more eyeballs; with more eyeballs on our software, we get better ideas for solving bugs, improving code quality, and enhancing security. It seems we might have reached a point where Linus's Law starts to kick in.

While we follow secure coding practices and also conduct regular penetration tests by third parties, we actively encourage people and researchers through our disclosure policy to test ZITADEL and disclose vulnerabilities responsibly. Following our disclosure process, we publish security advisories on GitHub and inform affected users and customers.

Besides application security, we have also enhanced our information security culture and practices over the last year to strengthen our operational security as well. Examples of this include clarifying the account lockout policy and successfully mitigating several notable (D)DoS attacks. We have recently updated our Trust Center to provide you with more information about our security practices.

In recent weeks, we mitigated vulnerabilities reported by different security researchers that could impact the security of systems using ZITADEL. Interestingly, some of the reporting parties conducted security research either on behalf of clients or as part of their due diligence process.

After reviewing and closely collaborating with the researchers, we promptly provided patched versions and issued security advisories, prompting affected users to upgrade to these patched versions. Since ZITADEL acts as a critical piece in protecting the confidentiality and integrity of applications, and moreover, could lead to systems becoming unavailable for users, most of the vulnerabilities receive a high severity rating.

Here is a short overview of the findings:

Password Reset Does Not Respect the "Ignoring Unknown Usernames" Setting (Moderate)

ZITADEL administrators can enable a setting called "Ignoring Unknown Usernames," which helps mitigate attacks that try to guess or enumerate usernames. While this setting was properly functioning during the authentication process, it did not work correctly in the password reset flow. This meant that even if this feature was active, an attacker could use the password reset function to verify if an account exists within ZITADEL. Security Advisory Link

XSS with User Avatar Image (High)

ZITADEL users can upload their own avatar images. Various image types are allowed, including SVG. SVG files can include scripts, such as JavaScript, which can be executed during rendering.

Due to a missing security header, an attacker could inject code into an SVG file to gain access to the victim’s account in certain scenarios. Please check out the details in the published advisory. You can also read the researcher’s blog post for more information.

Race Condition in Lockout Policy Execution (High)

ZITADEL provides administrators the ability to define a Lockout Policy with a maximum number of failed password check attempts. On every failed password check, the count of failed attempts is compared against the configured maximum. Exceeding this limit will lock the user out and prevent further authentication.

In the affected implementation, it was possible for an attacker to initiate multiple parallel password checks, thereby gaining the ability to try out more combinations than allowed by the Lockout Policy. We have published the following advisory, and the researchers have provided a write-up on their blog.

Account Takeover via Malicious Host Header Injection (High)

ZITADEL uses the notification triggering request's Forwarded or X-Forwarded-Host header to build the button link sent in emails for confirming a password reset with the emailed code. If this header is overwritten and a user clicks the link to a malicious site in the email, the secret code can be retrieved and used to reset the user's password, leading to account takeover.

Accounts with MFA, especially Passwordless (aka Passkeys), cannot be taken over by this attack.

You can find more information in our advisory.

Commitment to Continuous Security Improvement

We truly appreciate the time and effort that went into reporting and clarifying the vulnerabilities in ZITADEL. This work will not only better protect our customers, but our open-source community will also benefit from a more secure version of our product.

Pentests are one part of our security measures, and we will continue to commission security audits to third parties. Furthermore, we strongly encourage users to set up MFA, especially Passkeys, to protect their accounts in the best way possible. Although not all vulnerabilities can be compensated for by secure authentication, it still significantly reduces the attack surface. In terms of scope, we are planning to conclude a majority of the rework on our APIs, such as introducing a session API and switching from a service-based to a resource-based API, and subject those changes to a thorough review. However, we will not limit the scope only to new features but will continue to review existing features and our infrastructure.