Critical Gitlab vulnerability exposes 2FA-less users to account takeovers

Am I missing something or does the security release recommend updating to the latest version without saying what that latest version is (at time of writing)?

Come to think of it, how can you find what version of Gitlab is being run? (through the web interface on a CE instance)

How does the attacker introduce the controlled email as secondary email of the user they want to take over?

...that do not use LDAP.

Isn’t the point of resetting a password that you don’t know the password?

Isn't that a usability vs security trade-off? Asking naively as a non-expert here.

In some systems, a password reset lets you bypass MFA. On Gitlab, however, you might be able to reset the password, but it will not let you bypass MFA (which was a nice mitigation for this CVE).

I often wonder about this, because people's email should have fairly good security (MFA, detect new devices, suspicious IPs, alerts, etc), and MFA on the other service lets them have similar protections. Both services might not be bullet-proof, but an attacker will likely generate alerts in one or the other.

Most of my users are very non-technical, and might not have access to their MFA (MFA reset requests are fairly frequent), so to be able to access using a one-time-secret sent by email seems like an acceptable compromise, especially if it means that more users will enable MFA. In systems I administer, less than 20% of users tend to enable MFA (it depends on org policy, and it's often optional).

Speaking of, I wish services would do auth by: login -> MFA -> pass, instead of login -> reCaptcha -> pass -> MFA. Especially for scenarios where MFA is mandatory. Having reCaptcha is really annoying considering I went the extra step of enabling MFA (ex: Stripe, Quickbooks).

I guess that a service like GitLab might need to take this seriously, but ones with a lesser attack surface, might not care.

This is the case for the service that I am about to release. It makes it very convenient for users that forget their passwords. I know many instances of users not using services, because they forgot the passwords, and the services make it difficult to reclaim their accounts (Google, for instance).

Too much security can be a killer, for many applications. We don't need Fort Knox security for many apps.

In our case, we make sure that we don't require any user data, beyond a simple email address (and have Apple's private relay enabled, for those that want a bit more security). For many app developers, keeping so little user data is anathema, as they are actually PID harvesters.

> Any user with control of the designated email address could reset the password on an account without knowing that password.

Do you mean without having the MFA code? Because literally every password reset implementation operates without you knowing the password; that’s the entire point of it.

This seems pretty normal? If you've forgotten the password, you reset it via a reset email. If you had MFA set up, you still need the MFA with the new password. To reset the MFA, you either log in with a recovery code or you contact support.

Most services I use operate this way.