In late 2023, security researchers disclosed a critical business logic flaw in GitLab EE (Enterprise Edition) tracked as CVE-2023-3914. This vulnerability affects all GitLab EE versions before 16.2.8, 16.3 prior to 16.3.5, and 16.4 prior to 16.4.1. The problem is rooted in the way GitLab deletes namespaces (groups or project containers) but fails to delete *service accounts* associated with those namespaces. This oversight allows unauthorized access to internal GitLab projects via these lingering service accounts.

This post breaks down the issue in simple American language, shows code and exploitation snippets, and links to the original advisories. Everything you read is explained in a clear, step-by-step manner.

What Exactly Is the Problem?

- When you delete a namespace (like a group of projects) in GitLab EE, service accounts linked to that namespace are supposed to be deleted too.
- Due to CVE-2023-3914, those service accounts sometimes stick around even after the namespace (and its projects) are gone.
- These orphaned accounts can still have access permissions—including to new internal projects created under the same namespace name, or projects migrated into its place.
- That means someone with credentials for such a service account could access internal repositories they shouldn’t be able to see.

Impacted GitLab Versions

* GitLab EE < 16.2.8
* GitLab EE 16.3.x < 16.3.5
* GitLab EE 16.4.x < 16.4.1

> Note: GitLab Community Edition (CE) is not affected.

Company A creates a namespace (e.g. company-group) and some internal projects.

2. A service account is created for CI/CD or automation.

An attacker obtains the credentials for the lingering service account (by accident or intent).

6. The attacker accesses internal repos in that (now supposedly gone) namespace—possibly even after the group or some projects have been recreated with old names.

Here's a simple illustration in pseudo-Ruby (the language GitLab is written in)

class Namespace
  def destroy
    # Remove all projects
    projects.each(&:destroy)
    # Oops, forgot to remove service accounts!
    # old code: service_accounts.each(&:destroy)
  end
end

What should happen

class Namespace
  def destroy
    projects.each(&:destroy)
    service_accounts.each(&:destroy) # This line ensures service accounts go too!
  end
end

But before the patch, this second step was missing or faulty.

Testing and Confirming the Exploit

Proof-of-concept steps: (You need at least “Maintainer” permissions to try this on your installation)

curl --header "PRIVATE-TOKEN:" \

https://gitlab.example.com/api/v4/projects

Let’s imagine widgets-company had a CI service account called ci-bot

# Before namespace deletion
curl --header "PRIVATE-TOKEN: $CI_BOT_TOKEN" \
  https://gitlab.widgets.com/api/v4/projects

# After Widgets group deleted, but service account not purged
curl --header "PRIVATE-TOKEN: $CI_BOT_TOKEN" \
  https://gitlab.widgets.com/api/v4/projects

Both times, ci-bot could access anything the Widgets group had, even after deletion!

Why Is This Serious?

- Internal projects are meant only for company insiders. Exposure via old service accounts could leak proprietary code, credentials, or sensitive automation workflows.

- Patch immediately! The fix is in

- 16.2.8
- 16.3.5
- 16.4.1
- GitLab official advisory
- Manually audit service accounts: Check if any service accounts seem orphaned or unused, especially after recent namespace deletions.

How to list service accounts

# You may need admin rights to run this
curl --header "PRIVATE-TOKEN: <ADMIN_TOKEN>" \
  https://gitlab.example.com/api/v4/users?bot=true

Scan for accounts that shouldn’t exist!

Rotate service account tokens regularly.

- Set clear expiration dates for CI/CD and bot accounts.

References

- GitLab Critical Security Advisory: CVE-2023-3914
- NIST NVD Entry for CVE-2023-3914
- GitLab Documentation: Service Accounts

Final Words

CVE-2023-3914 is a classic example of a business logic error: not every bug needs to be a code execution flaw to be dangerous. Make sure you’re patched, review your bot/service accounts, and always remember deletion doesn't always mean deletion—even in 2024!

*Got questions or want to share your own exploit stories? Leave a comment!*

Timeline

Published on: 09/29/2023 07:15:00 UTC
Last modified on: 10/03/2023 15:31:00 UTC