[GH-ISSUE #537] Security issue: Users can set their own arbitrary email addresses

kerem commented

2026-02-27 08:15:49 +03:00

Owner

Originally created by @marlon0 on GitHub (Apr 8, 2023).
Original GitHub issue: https://github.com/lldap/lldap/issues/537

Users are able to log in to lldap and change their own email address to anything.
This presents two security concerns:
1 - Since many applications use email address as a unique identifier, this can allow impersonating the application accounts of other users.
2 - An attacker could set their email to a target's address and then abuse the password reset feature to flood their inbox

The simplest, most secure fix is to add a config option to prevent users from modifying their own email address.

A more sophisticated fix would be to allow users to use a process similar to the password-reset flow to update their email, and to rate-limit the number of email updates which can be requested per-account.

Originally created by @marlon0 on GitHub (Apr 8, 2023). Original GitHub issue: https://github.com/lldap/lldap/issues/537 Users are able to log in to lldap and change their own email address to anything. This presents two security concerns: 1 - Since many applications use email address as a unique identifier, this can allow impersonating the application accounts of other users. 2 - An attacker could set their email to a target's address and then abuse the password reset feature to flood their inbox The simplest, most secure fix is to add a config option to prevent users from modifying their own email address. A more sophisticated fix would be to allow users to use a process similar to the password-reset flow to update their email, and to rate-limit the number of email updates which can be requested per-account.

kerem

2026-02-27 08:15:49 +03:00

closed this issue
added the
bug

backend
labels

kerem commented

2026-02-27 08:15:50 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 10, 2023):

I'm a bit curious of your threat model: who are your users? Usually LLDAP is meant for a self-hosted case where users are lovingly hand-created by the admin, with a certain amount of trust. At least, that's been the working model so far, without issues. The security features that involve non-user behavior have always been taken seriously, but so far not so much the ones involving user behavior.

(There is one exception to that, something I want to address: since any user can change their email to the email of someone else, they can get admin access to a system that identifies by email. But I'll make emails unique to prevent this)

Notes for future implementers: the email-reset flow is probably too complex, and I don't want to implement rate-limits in LLDAP (you can always do that at the proxy level in front), so if we implement something, it'd be a setting to disable changing your email without admin rights.

@nitnelave commented on GitHub (Apr 10, 2023): I'm a bit curious of your threat model: who are your users? Usually LLDAP is meant for a self-hosted case where users are lovingly hand-created by the admin, with a certain amount of trust. At least, that's been the working model so far, without issues. The security features that involve _non-user_ behavior have always been taken seriously, but so far not so much the ones involving _user_ behavior. (There is one exception to that, something I want to address: since any user can change their email to the email of someone else, they can get admin access to a system that identifies by email. But I'll make emails unique to prevent this) Notes for future implementers: the email-reset flow is probably too complex, and I don't want to implement rate-limits in LLDAP (you can always do that at the proxy level in front), so if we implement something, it'd be a setting to disable changing your email without admin rights.

kerem commented

2026-02-27 08:15:50 +03:00

Author

Owner

@marlon0 commented on GitHub (Apr 11, 2023):

Yes, it's really the exception you mentioned that is the serious practical problem:
Currently a user can change their email address to the same address as an app's admin account. Then when they log in to the app using their own account, they'll be identified as the admin and have admin access.

You're right that requiring emails to be unique would solve this security issue, that's probably a better fix!

@marlon0 commented on GitHub (Apr 11, 2023): Yes, it's really the exception you mentioned that is the serious practical problem: Currently a user can change their email address to the same address as an app's admin account. Then when they log in to the app using their own account, they'll be identified as the admin and have admin access. You're right that requiring emails to be unique would solve this security issue, that's probably a better fix!

kerem commented

2026-02-27 08:15:50 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 13, 2023):

(Note that it's a breaking change, so the server will not start if you have duplicate emails)

@nitnelave commented on GitHub (Apr 13, 2023): (Note that it's a breaking change, so the server will not start if you have duplicate emails)

kerem commented

2026-02-27 08:15:50 +03:00

Author

Owner

@hudac commented on GitHub (May 5, 2023):

I understand this issue has been closed already. But we ran into a similar, potential security issue.

Requiring emails to be unique within LLDAP definitely solves the issue here, but only if LLDAP is the only source for user authentication. But in our case, we are using ID federation (via Dex) which usually connects multiple ID providers. If I know the email of a user that uses Google for login, and I have an account on LLDAP, it is possible for me to "impersonate" the email of that user by just changing my email on LLDAP. And the solution we use relies on email for identifying users uniquely, regardless if they login via Google, or AD, or in this case LLDAP, same email means same user.

so if we implement something, it'd be a setting to disable changing your email without admin rights.

Is this already possible? Could not find anything in the config. That would at least reduce the risk above.

Another idea: Forced email verification (can be turned on/off via config).
This would apply to new users, as well as to changing the email of existing users. In order to become "active", means a login via LDAP can succeed, the new email must be always confirmed by the email owner first (a similar flow like the password reset). Otherwise, login should fail as if the credentials are wrong.

@hudac commented on GitHub (May 5, 2023): I understand this issue has been closed already. But we ran into a similar, potential security issue. Requiring emails to be unique within LLDAP definitely solves the issue here, but only if LLDAP is the only source for user authentication. But in our case, we are using ID federation (via Dex) which usually connects multiple ID providers. If I know the email of a user that uses Google for login, and I have an account on LLDAP, it is possible for me to "impersonate" the email of that user by just changing my email on LLDAP. And the solution we use relies on email for identifying users uniquely, regardless if they login via Google, or AD, or in this case LLDAP, same email means same user. > so if we implement something, it'd be a setting to disable changing your email without admin rights. Is this already possible? Could not find anything in the config. That would at least reduce the risk above. Another idea: Forced email verification (can be turned on/off via config). This would apply to new users, as well as to changing the email of existing users. In order to become "active", means a login via LDAP can succeed, the new email must be always confirmed by the email owner first (a similar flow like the password reset). Otherwise, login should fail as if the credentials are wrong.

kerem commented

2026-02-27 08:15:50 +03:00

Author

Owner

@nitnelave commented on GitHub (May 5, 2023):

It's not currently possible to lock a field. But you might be interested in this issue created today: https://github.com/lldap/lldap/issues/570

It'll have to wait until after #67 though, to benefit from the field-level control and modularity.

@nitnelave commented on GitHub (May 5, 2023): It's not currently possible to lock a field. But you might be interested in this issue created today: https://github.com/lldap/lldap/issues/570 It'll have to wait until after #67 though, to benefit from the field-level control and modularity.

kerem commented

2026-02-27 08:15:50 +03:00

Author

Owner

@kgfathur commented on GitHub (Jul 1, 2025):

Helo,

I am also concerned about users being able to change their emails arbitrarily, because when simply create user with email by admin, we expect the users cannot edit their own email address.

I am interested in how some fields can be made Editable = False.

The User-defined attributes can be set Editable, why it is not applicable to email address too?

@kgfathur commented on GitHub (Jul 1, 2025): Helo, I am also concerned about users being able to change their emails arbitrarily, because when simply create user with email by admin, we expect the users cannot edit their own email address. ![Image](https://github.com/user-attachments/assets/73b83403-de61-4581-94a9-b0da265d5ecc) I am interested in how some fields can be made `Editable` = `False`. ![Image](https://github.com/user-attachments/assets/e6ead6af-3e1e-45dc-a8ab-abd71ee6ced1) The `User-defined attributes` can be set Editable, why it is not applicable to email address too?

kerem commented

2026-02-27 08:15:50 +03:00

Author

Owner

@nitnelave commented on GitHub (Jul 1, 2025):

I am also concerned about users being able to change their emails arbitrarily,

What exactly are you concerned about? Can you provide a problematic scenario?

@nitnelave commented on GitHub (Jul 1, 2025): > I am also concerned about users being able to change their emails arbitrarily, What exactly are you concerned about? Can you provide a problematic scenario?

kerem commented

2026-02-27 08:15:50 +03:00

Author

Owner

@kgfathur commented on GitHub (Jul 1, 2025):

IT Admin: create LDAP user (either manually, or via automation workflow of employee onboarding process)
uid: user.name
email: user.name@example.com

IT Admin integrate Authentication for some Platform/Service (i.e: Gitlab, Jenkins, SonarQube, Nexus, etc), and as an alternatif to user name (uid), Admin also allow using email as authentication to login to particular services via LDAP. Even if the email is not used as id for authentication, it's still used as metadata by some services when integrated with LDAP.
User can login to some integrated Platform/Services using uid (username) or email that registered with LDAP
User can login to lldap dashboard ui to reset password by themself (self-service).

User also can modify their email addess when login to lldap dashboard ui.

Is it not security concern? In normal condition, there will be not possible to have same email address for multiple users in the integrated services. However, when users from LDAP is not login yet to the services, usually their user is not created yet until their first login. This can be a sample vulnerability when the impersonating user login first to claim the email.

PS: other than password and avatar, I think the rest of Hardcoded attributes should not be Editable by default (in centralized identity source managed by admin), since they also can impersonate someone name, it's also used by some of Platform/Services when integrated to LDAP. cmiiw

@kgfathur commented on GitHub (Jul 1, 2025): 1. IT Admin: create LDAP user (either manually, or via automation workflow of employee onboarding process) uid: user.name email: user.name@example.com ![Image](https://github.com/user-attachments/assets/5b14ffc1-ec8d-438c-a49c-ae1ee3443d50) ![Image](https://github.com/user-attachments/assets/745c5166-542e-47a1-a36d-cbc688736ca1) 2. IT Admin integrate Authentication for some Platform/Service (i.e: Gitlab, Jenkins, SonarQube, Nexus, etc), and as an alternatif to user name (uid), Admin also allow using email as authentication to login to particular services via LDAP. Even if the email is not used as id for authentication, it's still used as metadata by some services when integrated with LDAP. 3. User can login to some integrated Platform/Services using uid (username) or email that registered with LDAP 4. User can login to lldap dashboard ui to reset password by themself (self-service). ![Image](https://github.com/user-attachments/assets/ccb5a8ad-2786-492d-a078-9cef19ecc3a9) 5. User also can modify their email addess when login to lldap dashboard ui. ![Image](https://github.com/user-attachments/assets/77603510-a46b-401c-8f00-9e08f5b6a720) ![Image](https://github.com/user-attachments/assets/24989af4-aa39-448c-b5ed-8de7147e641a) 6. Is it not security concern? In normal condition, there will be not possible to have same email address for multiple users in the integrated services. However, when users from LDAP is not login yet to the services, usually their user is not created yet until their first login. This can be a sample vulnerability when the impersonating user login first to claim the email. ![Image](https://github.com/user-attachments/assets/d66c2f5b-3ab7-43aa-a600-1754500985c8) ![Image](https://github.com/user-attachments/assets/7ae9032b-f281-44ac-b787-59750810484c) PS: other than password and avatar, I think the rest of **Hardcoded attributes** should not be Editable by default (in centralized identity source managed by admin), since they also can impersonate someone name, it's also used by some of Platform/Services when integrated to LDAP. cmiiw

kerem commented

2026-02-27 08:15:50 +03:00

Author

Owner

@nitnelave commented on GitHub (Jul 1, 2025):

There's something I have trouble following:

the issue is if you have a service that doesn't create the user until you actually try to log in, since emails cannot be duplicated
but if that user doesn't exist yet, then surely it doesn't have any meaningful privileges, right? You would have to create it first to grant it privileges, in which case you can't duplicate the email
then the issue boils down to any user can claim a new user on that service with any non-registered email they want. Is it much of an issue? If you consider emails as "proof of identity" and they're not checked, then sure.

Small reminder on the scope of LLDAP: this is primarily meant for small self-hosted servers for friends/family/trusted group of users. For instance, I don't think it's very hard to DDoS. I would argue that your security concern falls outside of that scope.

That said, I'm open to a PR making the relevant hardcoded attributes possible to lock.

@nitnelave commented on GitHub (Jul 1, 2025): There's something I have trouble following: - the issue is if you have a service that doesn't create the user until you actually try to log in, since emails cannot be duplicated - but if that user doesn't exist yet, then surely it doesn't have any meaningful privileges, right? You would have to create it first to grant it privileges, in which case you can't duplicate the email - then the issue boils down to any user can claim a new user on that service with any non-registered email they want. Is it much of an issue? If you consider emails as "proof of identity" and they're not checked, then sure. Small reminder on the scope of LLDAP: this is primarily meant for small self-hosted servers for friends/family/trusted group of users. For instance, I don't think it's very hard to DDoS. I would argue that your security concern falls outside of that scope. That said, I'm open to a PR making the relevant hardcoded attributes possible to lock.

kerem commented

2026-02-27 08:15:50 +03:00

Author

Owner

@kgfathur commented on GitHub (Jul 1, 2025):

Thanks for the quick response to this concern and discussion, really appreciate it!

Small reminder on the scope of LLDAP: this is primarily meant for small self-hosted servers for friends/family/trusted group of users. For instance, I don't think it's very hard to DDoS. I would argue that your security concern falls outside of that scope.

Got it, that makes sense now. I realize this is out of scope for the LLDAP project goals — thanks for pointing it out and taking the time to respond!

That said, I'm open to a PR making the relevant hardcoded attributes possible to lock.

Thanks for being open to PRs! I’d love to help... unfortunately I’m more of a sysadmin than a coder, so unless it's written in bash or happens in a terminal, I might be out of my depth 😅

@kgfathur commented on GitHub (Jul 1, 2025): Thanks for the quick response to this concern and discussion, really appreciate it! > Small reminder on the scope of LLDAP: this is primarily meant for small self-hosted servers for friends/family/trusted group of users. For instance, I don't think it's very hard to DDoS. I would argue that your security concern falls outside of that scope. Got it, that makes sense now. I realize this is out of scope for the LLDAP project goals — thanks for pointing it out and taking the time to respond! > That said, I'm open to a PR making the relevant hardcoded attributes possible to lock. Thanks for being open to PRs! I’d love to help... unfortunately I’m more of a sysadmin than a coder, so unless it's written in bash or happens in a terminal, I might be out of my depth 😅

Rows
Columns

[GH-ISSUE #537] Security issue: Users can set their own arbitrary email addresses #196