gitlab-org--gitlab-foss/doc/user/upgrade_email_bypass.md

# Updating to GitLab 13.2: Email confirmation issues

In the [GitLab 13.0.1 security release](https://about.gitlab.com/releases/2020/05/27/security-release-13-0-1-released/),
we described a security issue that allowed users to bypass the email verification process.
In that notice, we strongly recommended that you upgrade all affected installations to the
latest version as soon as possible.

There is a chance that users on a self-managed instance may be unable to commit code and
sign in. For more information, see the following resolved and closed
[security issue](https://gitlab.com/gitlab-org/gitlab/-/issues/121664).

This page can help you identify the users at risk, as well as potential issues of the update.

## The risk: users get emails that require confirmation

During the update process to GitLab 13.2, a background migration is run for accounts that meet the
conditions for the security issue. Such users are marked as _unconfirmed_.

An initial email is sent to _unconfirmed_ users to describe the issue. A second email is then
sent within five minutes, with a link for users to re-confirm the subject email address.

## Do the confirmation emails expire?

The links in these re-confirmation emails expire after one day by default. Users who click an expired link will be asked to request a new re-confirmation email. Any user can request a new re-confirmation email from `http://gitlab.example.com/users/confirmation/new`.

## Generate a list of affected users

You can generate this list before and after the upgrade using different methods.

### Before an upgrade to GitLab 13.2

Use the following code to search for users who:

- Are currently confirmed.
- Include identical `confirmed_at` times.
- Also have a secondary email address.

```ruby
emails_and_users_that_will_be_unconfirmed = Email.joins(:user).merge(User.active).where('emails.confirmed_at IS NOT NULL').where('emails.confirmed_at = users.confirmed_at').where('emails.email <> users.email')
```

### After an upgrade to GitLab 13.2

Use the following code to search for users who:

- Are currently **not** confirmed.
- Are also pending confirmation on or after the date of upgrade.

```ruby
users_apparently_pending_reconfirmation = User.where(confirmed_at: nil).where('confirmation_sent_at >= ?', date_of_upgrade_to_13_2)
```

## What does it look like when a user is blocked?

A regular user might receive a message that says "You have to confirm your email address before continuing". This message could includes a 404 or 422 error code, when the user tries to sign in.

NOTE: **Note:**
We hope to improve the [sign-in experience for an unverified user](https://gitlab.com/gitlab-org/gitlab/-/issues/29279) in a future release.

When an affected user commits code to a Git repository, that user may see the following message:

```shell
Your account has been blocked. Fatal: Could not read from remote repository
```

You can assure your users that they have not been [Blocked](admin_area/blocking_unblocking_users.md) by an administrator.
When affected users see this message, they must confirm their email address before they can commit code.

## What do I need to know as an administrator of a GitLab Self-Managed Instance?

You have the following options to help your users:

- They can confirm their address through the email that they received.
- They can confirm the subject email address themselves by navigating to `https://gitlab.example.com/users/confirmation/new`.

As an administrator, you may also confirm a user in the [Admin Area](admin_area/#administering-users).

## What do I do if I am an administrator and I am locked out?

If you are an administrator and cannot otherwise verify your email address, sign in to your GitLab
instance with a [Rails console session](../administration/troubleshooting/navigating_gitlab_via_rails_console.md#starting-a-rails-console-session).
Once connected, run the following commands to confirm your administrator account:

```ruby
admin = User.find_by_username "root" #replace with your admin username
admin.confirmed_at = Time.zone.now
admin.save!
```

## What about LDAP users?

LDAP users should NOT be affected.