GitLab is one of the most popular tools for collaborative software development. But sometimes, even big names get things wrong. Today, we’ll dive into a recently discovered vulnerability—CVE-2024-12380—found in GitLab EE (Enterprise Edition) and CE (Community Edition) that could let attackers get hold of sensitive authentication details from repository mirroring settings.

Read on—whether you’re a developer, DevOps, or sysadmin, this is need-to-know stuff. We’ll break it down in simple language, show working examples, and explain how you can defend against real-world exploit attempts.

All versions from 17.9 up to but not including 17.9.2

The bug lets certain user inputs in the repository mirroring settings expose sensitive authentication information, like passwords or tokens, to users who shouldn’t see them.

What is Repository Mirroring in GitLab?

Repository mirroring is a feature where your GitLab project automatically stays in sync with another repository—either as a push (to another repo) or pull (from another repo).

Admins and project owners usually need to enter URLs, usernames, and passwords or deploy keys to make this happen.

Here’s what the typical mirroring settings interface looks like

Mirror repository URL: https://myRepoAdmin:mySecretPassword@github.com/org/repo.git
Mirror direction: Push
Update credentials: [username/password/token]

Normally, secrets like mySecretPassword are hidden or stored safely.

What Went Wrong? (The Vulnerability)

The crux of CVE-2024-12380 is that when some user inputs are provided in the repository mirroring settings, GitLab could accidentally display these secrets on the web interface—or even include them in logs, responses, or error messages—where other unauthorized users might see them.

For teams with many users—some with limited project permissions—this could mean a leak of access tokens, private keys, or account passwords in plain text.

Imagine you set up a mirror with this input

Mirror URL: https://username:SuperSecretPassword@git.example.com/group/project.git

If the UI or an API response fails to mask the credentials, it could display

Current mirror: https://username:SuperSecretPassword@git.example.com/group/project.git

Or worse, if error logs aren’t cleaned

2024-01-25T16:23:42Z Mirror failed: could not authenticate to https://username:SuperSecretPassword@git.example.com/group/project.git

Anyone with access to this part of the interface—or error logs—can now steal the SuperSecretPassword.

Authorized but low-privilege project users (for example: Guests, Reporters)

- Anyone with access to mirroring logs or project settings where the sensitive fields are not properly masked

Attacker gets access to a project (could be a lower-permission user)

2. Attacker triggers a repo mirroring error, for example, by using a bad target repository or malformed URL
3. In some UI screens or logs, GitLab exposes the full mirror URL with credentials in clear text
4. Attacker copies the secret and uses it to access other services, private repos, or perform further attacks

Why is this dangerous?

- Exposed secrets might give access to private codebases, deployment tokens, or third-party repositories

How was this fixed?

The GitLab team issued patched releases where sensitive fields are now masked or never exposed in user-facing interfaces or logs.

What Should You Do Right Now?

1. Update your GitLab instance to a safe version immediately (see official GitLab release notes).
2. Rotate all passwords/tokens used in your mirrored repositories, especially if they were ever visible in logs or the UI.
3. Review access permissions: Make sure only trusted people can view repository settings and error logs.
4. Check your project logs: Look for any signs of suspicious access to repository mirrors, especially failed login attempts containing secret data.

References

- CVE Record at NVD
- GitLab Security Advisory

See the "Repository Mirroring could expose authentication information" section

- GitLab Issue Tracker (for context)

Final Thoughts

Even simple features can hide major security flaws. In this case, something as routine as mirroring a repo threatened to leak your project's keys to anyone poking around.

Patch your GitLab. Rotate your secrets. Think about who can see what.

Stay sharp, keep your secrets secret, and watch those upgrade notes!

Timeline

Published on: 03/13/2025 06:15:35 UTC