CVE-2024-9623 - GitLab Deploy Key Flaw Lets Attackers Push to Archived Repositories

In June 2024, a critical security vulnerability, CVE-2024-9623, was found in GitLab Community Edition (CE) and Enterprise Edition (EE). This bug affects multiple versions and allows attackers to push code to archived repositories using deploy keys. Below, we’ll explain the flaw in simple language, how it can be exploited, provide helpful links, and share code snippets showing the issue.

From 17.4 up to (not including) 17.4.2

This means if you’re not running at least one of these fixed versions (or newer), your instance is at risk!

What’s the Problem?

GitLab repositories can be archived to mark them as read-only. Archived repositories should *not* accept any new commits or pushes—even via deploy keys, which are SSH keys intended for CI/CD or automation.

CVE-2024-9623 is a bug where, despite a repo being archived, attackers can still push commits using a deploy key. The main danger is that it breaks the expected *immutability* of archived repos—allowing unauthorized changes, tampering, or backdoors in supposedly “frozen” code.

Archiving: A repo gets archived, assuming it’s safe and read-only.

2. Leaked/valid Deploy Key: Someone with access to a deploy key (maybe a CI/CD system, or old script credential) tries to push after archiving.
3. Bypass: Due to the bug, GitLab does not block the push. The attacker’s code lands in the archived repo.
4. Impact: The integrity of the archived code is lost. Anyone relying on that repo (for auditing, compliance, production, etc.) could be compromised.

Example Scenario

Suppose your company archives a repo containing legacy production code. Months later, an attacker who finds a deploy key can still push a malicious commit:

# Example: push to an archived GitLab repo using a deploy key
GIT_SSH_COMMAND='ssh -i /path/to/deploy_key' git push git@gitlab.com:company/archived-repo.git main

Expected: GitLab should reject the push with an error about the repo being archived.

Actual (with vulnerable versions): The push succeeds, modifying the archived code.

Pseudocode simulating the vulnerable logic

# simplified logic in GitLab that checks for readonly on archived repos
if repo.archived? && !user.has_push_rights?
  reject! # Proper behavior
end
# But: deploy_key is mistakenly treated as superuser
if deploy_key.present?
  allow_push! # Vulnerable behavior
end

In vulnerable versions, the code failed to combine both checks, allowing deploy keys to bypass the archive restriction.

Links to Official Sources & Fixes

- GitLab Security Release Blog
- GitLab CVE Advisory: CVE-2024-9623
- Patch/Release Notes for 17.2.9, 17.3.5, 17.4.2

Upgrade Now: Update to 17.2.9, 17.3.5, 17.4.2 or later.

Proof-of-Concept “Exploit”

If you still have a deploy key on an archived repo and haven’t patched, you can “exploit” this by simply pushing with that key:

# Using SSH deploy key to push a new commit
git clone git@gitlab.com:company/archived-repo.git
cd archived-repo
echo "# Malicious change" >> README.md
git add README.md
git commit -m "Add backdoor code"
GIT_SSH_COMMAND='ssh -i /path/to/deploy_key' git push origin main

If you see this push succeed and you’re on a vulnerable version, your instance is affected!

Audit Archived Repos: Check for suspicious commits after the time of archiving.

4. Watch for Announcements: Always monitor GitLab Security for critical updates.

Conclusion

CVE-2024-9623 is a powerful reminder that “archived” isn’t always safe—particularly if automation credentials like deploy keys aren’t strictly handled. Upgrading immediately is the only sure way to protect your codebase. Stay vigilant, and don’t assume archived means untouchable!


Like, share, and spread the word to help protect the open-source community from threats like CVE-2024-9623.


*References:*
- GitLab Release Notes
- NVD CVE-2024-9623
- GitLab Security Contacts

Timeline

Published on: 10/10/2024 10:15:08 UTC
Last modified on: 10/10/2024 12:51:56 UTC