In early 2024, a new vulnerability was found in GitLab Enterprise Edition (EE): CVE-2024-12244. This issue let users peek at restricted project information—even if certain features were turned off. If you use GitLab EE, *especially* a version released before April 2024, you need to know about this.

Let’s break down what happened, who is affected, how this bug worked, and what you should do. I’ll show you code snippets, links to the fix, and even hints on how an attacker could have used it.

What is CVE-2024-12244?

CVE-2024-12244 is a flaw in GitLab EE’s access controls. Because of it, users could view details about restricted projects even when project features (like issues, merge requests, or wikis) were turned off for them. The problem affected:

GitLab EE 17.11 (before 17.11.1)

In other words: if you use GitLab EE, and haven’t updated since April 2024, your sensitive info may have been exposed.

Who is affected?

Only GitLab Enterprise Edition (not Community Edition). All organizations running the above versions could have their restricted project information leaked to some users.

And others

The Bug: Even with these disabled, users could sometimes still access data linked to them. For example, a user could craft a direct URL or API request to grab info that *should* have been blocked.

Let’s say the Wiki feature is disabled on a project

# project.rb (simplified)
def wiki_accessible_by?(user)
  # Should check both user and feature flag
  feature_enabled?(:wiki) && user.can_access?(self)
end

But: in some API endpoints, the check was missing or incomplete.

Suppose you hit an endpoint like /projects/:id/wikis/pages

# bad_wiki_controller.rb
def show
  # Missing a proper check!
  @wiki = @project.wiki
  render json: @wiki.pages
end

Even though the wiki is disabled, the controller skips the check and returns the info!

An attacker could find the project ID for a private project and issue an API call

curl -H "PRIVATE-TOKEN: usertoken123" \
  "https://gitlab.example.com/api/v4/projects/42/wikis/pages";

Expected: You’d get “404 Not Found” or “Access Denied”.

Bugged: You actually get a list of pages (sometimes with contents)!

Regular users to fetch private issue titles, comments, or wikis.

- CI/CD robots or scripts to harvest restricted data by calling API endpoints directly.
- Insider threats—someone with *some* access to snoop on projects where features are supposed to be off.

This is a leak of confidential and sensitive information.

How Was It Fixed?

GitLab issued security releases in April 2024. They audited and updated their code to ensure permission checks *always* matched feature flags.

Here’s what a fixed endpoint now looks like

def show
  unless @project.feature_enabled?(:wiki)
    render status: :not_found, json: {error: "Feature disabled"}
    return
  end

  if current_user.can_access?(@project)
    @wiki = @project.wiki
    render json: @wiki.pages
  else
    render status: :forbidden, json: {error: "Not allowed"}
  end
end

After the patch, *all* endpoints, not just the UI, are aligned with access controls.

Download the latest version here

- GitLab Downloads
- Security Release Notes

2. Review Access Logs

Check for suspicious API calls to disabled project features since your last upgrade.

3. Audit Project Settings

Double-check your project and group feature flags. Consider tightening access controls if you can’t upgrade right away.

4. Educate Users

Admins and developers should review how feature flags and permissions interact, especially when building custom tools.

Conclusion

CVE-2024-12244 is a reminder that hiding features is *not* enough—you must enforce restrictions everywhere: UI, API, and backend logic. Make sure you’re running the latest GitLab EE. Security is only as strong as your weakest check!

References

- Original Security Advisory
- CVE Record
- GitLab Update Guide

Timeline

Published on: 04/24/2025 08:15:14 UTC