Ultimate-licensed GitLab EE versions starting 13.12 to 16.2.8, 16.3. to 16.3.5, and 16.4. to 16.4.1 are vulnerable to a dangerous issue (CVE-2023-5106). This bug can allow an attacker to impersonate other users during CI pipeline runs just by abusing group transfers using direct imports. In this post, I will break down in simple terms how the issue happens, show code snippets, walk through an exploitation scenario, and end with links to original references for more details.

What Is the CVE-2023-5106 Vulnerability?

The vulnerability lies in the group import feature of GitLab Enterprise Edition (EE) Ultimate, which allows groups to be directly imported with user data. Under certain circumstances, the software does not properly check or sanitize user identities in the imported data, especially during group "direct transfer" imports. As a result, an attacker can manipulate these imports and create situations where they are treated as different users in CI/CD pipelines.

Why does this matter?  
CI/CD (Continuous Integration and Continuous Deployment) pipelines often run with different user permissions or tokens. If an attacker can trick GitLab into thinking that their pipeline job is running as an actual collaborator, they might gain unauthorized permissions: accessing sensitive data, launching code with unwanted privileges, or simply confusing audit logs.

Who Is Affected?

This exploit impacts Ultimate licensed instances of GitLab Enterprise Edition (EE) in these version ranges:

Versions from 16.4. up to, but not including, 16.4.1

GitLab CE (Community Edition) is not affected. If you’re running a vulnerable version and allow users to import groups, you should update as soon as practical.

How Does The Vulnerability Work?

Scenario:  
An attacker with permission to import groups into their GitLab instance can craft a JSON payload representing a group, which also contains fake user IDs or user references. When GitLab processes this import, it links certain pipeline actions with attacker-controlled accounts, but marks them as if they are the real users.

Why group imports?  
GitLab allows users to export entire groups (with users, projects, pipelines, etc.) as a JSON archive, and later import them elsewhere—a handy feature for migrations. If this importer does not correctly confirm the authenticity of user identity data in the archive, it becomes possible for attackers to "map" themselves to other users specific to their needs.

Exports a benign group and inspects the JSON export.

2. Edits the export to change user references, so that pipeline stages appear to run as a different user (e.g., an admin or a known developer).
3. Re-imports this modified group into a GitLab EE Ultimate instance using the direct transfer group import feature.
4. Sets up a project and triggers CI pipelines. The new (fake) relationship makes pipeline jobs appear as if run by the impersonated user.

Sample of a Manipulated JSON Payload

{
  "version": ".2.7",
  "groups": [
    {
      "name": "example",
      "members": [
        {
          "user_id": 42,                // attacker chooses ID of target user
          "user": {
            "id": 42,
            "username": "victim_user",  // attacker can set this to any target
            "email": "victim@example.com"
          },
          "access_level": 50
        }
      ]
    }
  ],
  "projects": [
    // ... project data ...
  ]
}

When this is imported, GitLab should ideally check if "user_id":42 matches a legit user, and not let the attacker link themselves to it. Earlier versions failed to do this robustly in some cases.

Triggering the Vulnerability

After import, any pipeline started in this group may show in the UI or logs as executed by victim_user, not the attacker, which may allow for social engineering attacks, privilege checks to pass, or audit log fraud.

Using API

curl --header "PRIVATE-TOKEN: <your_access_token>" \
     --form "file=@modified_export.tar.gz" \
     "https://your.gitlab.example/api/v4/groups/import";


Then create a pipeline and check the job details: the “user” will be wrongly attributed.

Impact

- Privilege Escalation: Under some configurations, the attacker can trigger CI jobs as higher-privileged users.

Audit Log Tampering: Activities could be logged under another (possibly admin) user.

- Data Exposure: Jobs run as another user could access secrets/env variables they aren’t supposed to.

How GitLab Fixed It

The patched versions now ensure that during group import, user identities in the archive are not blindly accepted. They perform checks to ensure that imported users must exist and match on critical fields (like email and user ID), or they create new ones but with no association to actual privileged users. This stops attackers from impersonating existing users in pipelines.

Official References & Further Reading

- GitLab Security Advisory for CVE-2023-5106
- NVD Entry for CVE-2023-5106
- GitLab Docs: Importing and exporting groups

Conclusion

CVE-2023-5106 demonstrates how flexible features—like group import/export—can turn into dangerous attack surfaces when user identities aren't properly validated. While only GitLab EE Ultimate users with import privileges are at risk, the potential to hijack identities in CI pipelines is serious. If you use GitLab at work, double-check your version and upgrade if needed, especially if group imports are enabled.

*Always verify who’s really running your code—don’t trust, verify!*


Disclaimer:  
All technical details are published for educational and defensive research purposes. Do not use this information to attack systems without explicit authorization. Always test on your own instances and stay within the law.

Timeline

Published on: 10/02/2023 12:15:00 UTC
Last modified on: 10/04/2023 12:25:00 UTC