CVE-2024-5435 - GitLab EE/CE Password Disclosure in Repository Mirror Configuration (Exclusive Deep Dive)

---

GitLab, the industry’s favorite DevOps tool, is again in the spotlight—not for innovative features, but for a severe security flaw: CVE-2024-5435. This vulnerability could allow attackers to steal plain-text user passwords stored in repository mirror settings, shaking the security foundation for teams worldwide. If your team or company uses GitLab for code hosting and CI/CD, understanding and mitigating this threat is absolutely critical.

In this guide, I’ll walk you through what CVE-2024-5435 is, how it works under the hood, proof-of-concept exploitation, and concrete steps to protect your environment.

What is CVE-2024-5435?

CVE-2024-5435 is a vulnerability found in both GitLab Community Edition (CE) and Enterprise Edition (EE). The bug discloses user-set passwords from repository mirror configurations in the GitLab web interface.

17.3.x before 17.3.2

Essentially, if you set up GitLab to mirror a repository (for example, syncing code automatically with GitHub or Bitbucket), the password you use can be exposed to certain users.

Official References:
- GitLab Advisory Page for CVE-2024-5435
- GitLab CVE Database Entry

How the Vulnerability Works

When setting up a repository mirror in GitLab, you supply credentials (including a password) so GitLab can pull from or push to another remote repository.

For affected versions, a flaw in the way GitLab renders the repository mirror configuration page fails to properly mask or secure the password field. Depending on access levels, an attacker (or even a less-privileged user) could access a page or API endpoint where the password appears in plain text.

Alice configures a private GitHub mirror with her personal password in a GitLab project.

2. Bob (a project member or possibly with less privilege) browses to the mirror settings page or queries certain API endpoints.
3. Bob now sees Alice’s GitHub password in clear text, potentially exposing her other accounts, corporate IP, or triggering further compromises.

Exploit Details: Proof of Concept

While we encourage only responsible, ethical testing (not illegal exploitation), here’s how a simple exploit might unfold on a vulnerable GitLab instance:

Step 1: Setup

- Have access as a developer or maintainer to a project with repository mirroring set up using a real password.

Navigate to the project:

https://<gitlab-instance>/<group>/<project>/-/settings/repository

Observe: The password field might be visible in plain text (see below).

A user can send an authenticated GET request to

GET /api/v4/projects/:id/remote_mirrors

Example Response (vulnerable versions)

[
  {
    "id": 42,
    "url": "https://github.com/example/repo.git";,
    "enabled": true,
    "user": "alice",
    "password": "supersecretpassword"
  }
]

> Note: In patched versions, the "password" field should be, at minimum, redacted or absent for non-owner users.

Real-World Impact

- Password reuse risk: Many users reuse passwords—stealing this password often gives access to other systems.
- Credentials stored in logs/backups: API responses could be picked up by log aggregation tools or browser history.
- Lateral movement: Attackers inside your network could pivot to connected systems (GitHub, Bitbucket, etc).

Timeline

Published on: 09/12/2024 17:15:05 UTC
Last modified on: 09/14/2024 15:05:50 UTC