I don't think we consider this a security issue. We even provide API methods for users with view access to check if a specific userLogin or userEmail exists.

users with view access have indeed the ability to check whether an account exists,

but wondering about anonymous user (thanks for reporting this issue @fadi-assaad), is it currently the only place where one can check whether a given username/email account exists?

I suppose there are couple more places... I wouldn't be surprised if UsersManager.getTokenAuth exposes it, and lots of other places.

Hello, do you still consider user enumeration as a non-security issue? If yes, could you please take an official stance and close this issue? And if not, could you please fix it? Thank you for your answer.

FYI, OWASP seems to consider it as security issue.

In my opinion, this is also a small security gap. A generic message is also displayed when logging in, and not whether the password or the email address is wrong: Wrong username and/or password.

The same behavior should happen with a password reset. A generic message like Password reset mail was sent if account exists, or something like that.

So what do you think @tsteur / @mattab about this approach?

We could change the error message for password reset and instead show a success message at all times and mention the email will be only received if entered correctly.

FYI quickly checking few providers and they are also showing an error message similar to us. Some other systems show the success message.

This issue was picked up during a recent network penetration test, which included a public-facing server with Matomo 5.0.0 installed. After a bit of digging I found this 5-year-old issue :-)

The penetration tester noted:

• Vulnerability "Password Reset Message User Enumeration" for the Change/Lost Password dialog
• In common with other comments here, suggested: "the behaviour should be similar to the primary Sign In dialog which does not have this issue"
• CVSSv3 score of 4.5 and severity MEDIUM; the real world applicability of that will depend on context, as always.