If you are managing a GitLab server (especially GitLab Enterprise Edition), you probably rely on Single Sign-On (SSO) to control access to your company’s private code repositories. Unfortunately, a serious security issue was discovered in GitLab EE affecting versions from 11.11 up to 16.2.8, 16.3 up to 16.3.5, and 16.4 up to 16.4.1. This vulnerability, tracked as CVE-2023-3115, could let users bypass SSO restrictions under certain conditions. In this post, I’ll explain how this happened, what’s exploitable, and (most importantly) how to protect your organization.

What is CVE-2023-3115?

In short: Project access restrictions enforced by your SSO provider weren’t always honored by GitLab. If you had a repository set to “public (members-only)” and enforced SSO, indirect members (like people added via group membership) could access these even if your SSO rules should have kept them out.

GitLab EE 16.4 _up to_ 16.4.1

> This GitLab advisory provides their own writeup.

How the Vulnerability Works

In larger organizations, members often get indirect access to repos through group membership assignments. For instance:

“Secret Project” requires SSO for members

The bug:
If “Secret Project” was set to *public*, but GitLab “members-only,” and SSO was required, GitLab allowed indirect members (like Alice, by way of “Dev Team”) to access the repo, bypassing SSO requirements.

In simpler words:
If someone was an indirect member (through a group), the software wouldn’t double-check if they passed your organization’s SSO validation—they just got in.

The group is a member on a “members-only” project that requires SSO.

3. The attacker does NOT pass SSO validation, but GitLab still grants access due to faulty enforcement logic.

To visualize the error, here's what may have gone wrong inside the permission-checking code

# SSO enforcement (simplified)
def can_access_project?(user, project)
  # Check if they're a project member, even indirectly
  return false unless project.members.include?(user) || user.indirect_project_membership?(project)

  # SSO restriction - should enforce SSO for ALL members:
  if project.sso_enabled?
    return user.sso_authenticated? # <-- THIS IS THE BUGGY CHECK
  end

  true
end

# The bug: indirect members were not checked for SSO!

What the code should have done is enforce the SSO for anyone, direct or indirect, with access.

A company uses GitLab EE with SSO enforced on all important group projects.

2. They hire a freelance developer and add her to a general “Contractors” group (with no SSO access).
3. The “Contractors” group is added as a member to certain repos, believed to be fully SSO-guarded.
4. The contractor can now access private code in “members-only” repos without ever passing SSO, simply by being an indirect group member.

This is especially dangerous for companies relying on SSO for compliance, auditing, or regulatory reasons. Anyone who snuck into a group, even accidentally, could access things that should be much better protected.

Mitigation & Fixes

All users should upgrade immediately.

GitLab EE 16.4.1

If you use an older version, update _now_. You can read more in their security release notes.

While waiting for patching, here’s what you can do

- Audit your group memberships – Double-check all groups with project access, especially with “members-only” or “SSO required” repos.

References and Further Reading

- NVD CVE-2023-3115 Entry
- GitLab Security Release Blog
- GitLab Issue #421976 (may be restricted to disclosed users)

Conclusion

CVE-2023-3115 is one of those subtle, “gotcha”-style SSO bugs that can have big consequences if left unpatched. If your organization relies on GitLab EE and SSO, take this vulnerability seriously—update your servers and keep an eye on group memberships. Indirect access can be more dangerous than it looks.

Stay patched and stay safe!

*Do you maintain enterprise GitLab? What’s your upgrade policy? Let’s discuss below!*

Timeline

Published on: 09/29/2023 07:15:00 UTC
Last modified on: 10/02/2023 19:46:00 UTC