---

GitLab is the backbone for many developers, teams, and companies, providing a place to store code, manage CI/CD, and organize projects. Security is a top concern—which is why issues like CVE-2024-13041 matter so much. This vulnerability, discovered in GitLab CE/EE, exposes a gap in how GitLab integrates with SAML authentication. It could allow some users unintended access to sensitive internal projects and data.

In this post, we’ll break down this CVE, walk through a possible attack, show real code samples, and share actionable advice for mitigating the vulnerability.

What is CVE-2024-13041?

CVE-2024-13041 is a security issue in GitLab Community Edition (CE) and Enterprise Edition (EE) in these versions:

From 17.7 up to (but not including) 17.7.1

When a user accounts is created or signed in through a SAML (Security Assertion Markup Language) provider, there’s a logic bug: the external groups attribute will overwrite the intended configuration for how “external” users are marked in GitLab. Because of this, users might not be considered “external” even when they should be, and therefore, they can access internal projects or groups that are supposed to stay private.

Why “External” Matters

Marking users as “external” in GitLab restricts what they see—internal groups and projects are hidden. If someone can slip through without this flag, they’re suddenly much deeper in your organization’s code and conversations than they should be.

References

- GitLab security release notes
- CVE Record – NVD
- GitLab SAML Docs

The Flaw In Detail

Let’s break down the issue. When a user signs in via SAML, GitLab processes group membership and user attributes it receives. One of these flags is whether the user is “external.”

Let’s imagine this logic in a simplified way (not the actual code, but close to what happens)

# Hypothetical code that runs when a user logs in via SAML

user = User.find_or_create_by(email: saml_data["email"])
 
# Set external status based on provider config
user.external = saml_provider_config["mark_user_as_external"]

# SAML assertion can also specify group memberships
if saml_data["groups"].present?
  user.external = determine_external_from_groups(saml_data["groups"])
end

user.save

In vulnerable versions, if the SAML assertion has a groups attribute, it overrides whatever the admin set in the SAML provider config. This means the external/internal status can flip, possibly unintentionally, depending on how the “groups” mapping is set up on your SAML side.

Exploit Scenario: From SAML to Internal Project Access

Suppose your company has set “external” as the default for all SAML-provisioned vendor accounts, using the SAML provider config. But, there’s a misconfiguration or ambiguity in how group membership is mapped in the SAML response.

An attacker or an unintended user is provisioned through your SAML IdP (Identity Provider).

2. The IdP sends a SAML assertion with group information that conflicts with the external groups mapping in GitLab.

The user can now see internal projects, including potentially sensitive repos and conversations.

Suppose you run a contractor onboarding group called contractors and map it on your SAML IdP. But in the SAML response, your IdP accidentally includes users in an “employees” group. Instead of being restricted, they’re now treated as employees—with a much wider access than intended.

Minimal Exploit Snippet

To simulate how a SAML response could abuse this, here’s a (hypothetical) SAML snippet that’d overload the groups claim:

<saml:Attribute Name="groups">
  <saml:AttributeValue>gitlab-internal-staff</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="email">
  <saml:AttributeValue>evil.contractor@example.com</saml:AttributeValue>
</saml:Attribute>

This leads to the user _not_ being marked as “external” in GitLab, depending on your group mappings—circumventing protections.

Leaked source code: Internal documentation, product code, or CI secrets may be exposed.

- Potential lateral movement: Attackers with newfound access might escalate privileges or collect more information about your teams.
- Audit trail confusion: External users “masquerading” as internal may muddy your logs and incident response.

17.7.1 or later

See GitLab’s release notes for details.

3. Monitor for Strange Access Patterns

Set up logging and alerting for new users accessing internal projects.

4. Perform Regular User Reviews

Make user reviews part of your security routine—especially for SAML-provisioned users.

- GitLab security release notes
- National Vulnerability Database – CVE-2024-13041
- GitLab SAML Omniauth Docs
- GitLab User Types Explained

Conclusion

CVE-2024-13041 highlights how small bugs in authentication flows can become big risks to your private code and company secrets, especially with third-party integrations like SAML. Keep your GitLab up to date, triple-check your SAML mappings, and always assume even “trusted” integrations can go wrong.

If you’re responsible for GitLab security, run not walk to close this gap—and keep your internal projects truly internal.

Timeline

Published on: 01/09/2025 07:15:26 UTC