Cloudanix VulnDB

CVE-2021-39913

Medium · 4.4

CVSS

4.4

EPSS

0.3%

Published

Nov 5, 2021

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in GitLab wrote the main server password into a file that anyone who can read the server's logs could see and use to take over the entire machine.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Low
Impact
Privilege Gain
Component
Application
Class
Information Disclosure
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The vulnerability causes the system root password to be written in plaintext to migration logs during upgrade processes on affected GitLab instances.

Why it matters to the business

Attackers who already have access to server files can obtain full administrative control of the underlying system, potentially leading to complete data exposure, service disruption, or further lateral movement within the environment.

How an attack unfolds

An attacker with existing local file system access locates the migration log files created during GitLab upgrades, extracts the logged root password, and uses it to authenticate as root on the host system.

How to fix it

Upgrade GitLab CE/EE to version 14.2.6 or later, 14.3.4 or later, or 14.4.1 or later. After upgrading, review and rotate any credentials that may have been exposed in existing migration logs and delete or sanitize historical log files containing sensitive data.

How to confirm the fix worked

Confirm upgrade to a fixed version by checking the running GitLab release, then inspect migration logs for absence of password strings and verify that future migrations no longer log credentials.

Typical attack path

  1. Obtain local file system access to the GitLab server host
  2. Navigate to migration log directories created during version upgrades
  3. Search log contents for plaintext root password entries
  4. Authenticate to the host operating system using the recovered credentials
  5. Perform privileged actions or establish persistence as root

How to detect it

Examine migration log files for entries containing password strings, review authentication logs for unexpected root logins around the time of GitLab upgrades, and search file system access logs for unauthorized reads of log directories.

  • /var/log/gitlab/migrate*.log
  • root password
  • gitlab-ctl reconfigure
  • password=.*root

What your security team should do

  • Immediately upgrade all GitLab instances to a patched release
  • Audit migration logs across all hosts for any historical password exposure and rotate affected credentials
  • Restrict local file system access to GitLab servers to only necessary administrators
  • Implement log scanning to detect sensitive data patterns before logs are archived

The record

Accidental logging of system root password in the migration log in all versions of GitLab CE/EE before 14.2.6, all versions starting from 14.3 before 14.3.4, and all versions starting from 14.4 before 14.4.1 allows an attacker with local file system access to obtain system root-level privileges

Affected packages

Ecosystem Package Introduced Fixed
Bitnami gitlab 0 14.2.6
Bitnami gitlab 14.4.0 No fix
Ubuntu:16.04:LTS gitlab 0 No fix
Ubuntu:Pro:16.04:LTS gitlab 0 No fix

Related vulnerabilities