CVE-2023-4002 - Deep Dive Into The GitLab EE Security Policy Linking Vulnerability

In August 2023, a new vulnerability—CVE-2023-4002—was disclosed in GitLab Enterprise Edition (EE), a popular self-hosted Git repository management tool. This flaw exposed organizations using GitLab EE to serious privacy and security risks by allowing certain users to link and potentially view security policies from projects they shouldn't have had access to. If your organization uses GitLab EE, it's critical to understand how the bug worked, the versions affected, and what you can do to remediate it.

This post will explain CVE-2023-4002 in simple terms, walk you through what happened under the hood, provide code snippets to illustrate, and reference official sources for further reading. You'll also find an outline of how attackers might have exploited this bug, and practical mitigation tips.

What Is CVE-2023-4002?

CVE-2023-4002 is a vulnerability in GitLab EE's security policies management. Any licensed user could link a Security Policy Project—by its internal ID—to nearly any project or group they had access to, even if they were not supposed to see the policy itself.

This could expose configuration details of sensitive security policies. In an enterprise context, this is a critical leak, as these policies often contain information about your organization's protection mechanisms and practices.

16.2 (and later) up to 16.2.2

If you are on any of these versions, you are at risk. Always update to the latest GitLab release for your deployment.

The Technical Problem: How Did It Work?

GitLab EE offers a feature called a "Security Policy Project," where admins can store policies affecting code quality, vulnerability scans, deploy approvals, etc. These are usually tightly controlled due to the sensitive strategies they hold.

The bug: Any EE-licensed user with project or group access could (via the UI or API) _link_ any security policy project by supplying its internal Project ID. GitLab would join the two, letting the user see the policy configs—regardless of that user's actual rights to the policy project.

security-policy-project-B: A policy project, very restricted.

Intended behavior: Only people with access to security-policy-project-B should be able to see its policies.

Actual behavior: Anyone with access to project-A could link it to security-policy-project-B (using the internal ID of B), and then see its policies as though they had full access.

Step 1: Find The Policy Project ID

Attackers don't need access to the policy project; they only need to guess or enumerate its internal ID. Usually, these are small integers (e.g., 23, 122, etc.).

Step 2: Link Security Policy Project via API

With their own project/group and a known EE license, the attacker can call the security policy project API:

curl --header "PRIVATE-TOKEN: <your_access_token>" \
  --request POST "https://gitlab.example.com/api/v4/projects/<projectA_id>/security/policy_project"; \
  --data "security_policy_project_id=<projectB_id>"

Step 3: Access and View Security Policies

After successfully linking, when visiting the Security & Compliance settings for project-A, the policies from policy-project-B are served—whether or not the user has entitlement.

Code Snippet (Ruby on Rails / Pseudocode)

def assign_policy_project(user, project_id, policy_project_id)
  project = Project.find(project_id)
  policy_project = Project.find(policy_project_id)
  if user.can_access?(project)
    # MISSING: Permission check for policy_project!
    project.security_policy = policy_project
    project.save
  end
end

> See the missing line? There should be a check that user is also authorized for policy_project—but the buggy implementation skipped it.

Real-World Impact

- Leak of sensitive info: Attackers could see secrets of security configurations, details on scanning rules, or specifics of blockers and exceptions.
- Reconnaissance: Malicious insiders or supply-chain actors could use this knowledge to plan further attacks.

Remediation & Fix

GitLab's Patch: Subsequent hotfixes (16..8, 16.1.3, and 16.2.2) ensure that proper authorization is enforced—users can no longer assign security policy projects unless already permitted to read those policies.

What You Should Do

1. Upgrade now to the latest GitLab EE release.

Official References

- GitLab Security Release Blog, August 2023
- GitLab CVE advisory
- NVD Details for CVE-2023-4002

Conclusion

CVE-2023-4002 is a serious reminder that access-control checks must be holistic—just validating user access on one resource (like their own project) isn't enough when linking to a sensitive one (like a policy store). While this bug is now patched, its exploitability and the simplicity of the attack mean it's vital to update your systems and revisit your permission audits.

Stay secure. Test your systems. And always keep your dependencies patched.

*If you found this write-up useful, please share it with your DevSecOps or SRE teams, and keep a close eye on future GitLab releases.*

Timeline

Published on: 08/04/2023 01:15:00 UTC
Last modified on: 08/08/2023 18:46:00 UTC