CVE-2024-4011 - GitLab Non-Member Key Results Promotion Vulnerability Explained

If you’re running GitLab in your organization, it’s always crucial to stay up-to-date on security issues that could impact your code and workflow. In this exclusive deep dive, we explore CVE-2024-4011 – a recent vulnerability impacting GitLab Community Edition (CE) and Enterprise Edition (EE). This flaw could let non-project members gain unintended influence by promoting Key Results to Objectives inside OKRs, a feature that's supposed to be limited to project members only. Read on to understand what went wrong, how it can be exploited, and what you should do about it.

What is CVE-2024-4011?

*CVE-2024-4011* allows an attacker, who is not a member of a GitLab project, to *promote Key Results to Objectives* in the "Objectives and Key Results" (OKR) feature. In simpler terms, outsiders could alter your project's goals tracking, potentially causing confusion, damage, or even information leaks in an agile environment where OKRs might reflect sensitive milestones or targets.

Impacted Versions

- GitLab CE/EE:

17.1. and up (up to but not including 17.1.1)

*If your GitLab isn’t at one of these latest patch releases, your instance may be vulnerable.*

Reference

- Official Advisory: GitLab Security Release: 16.11.5, 17..3, and 17.1.1
- CVE Record: CVE-2024-4011 at NVD

The Vulnerability — What Actually Happened?

The GitLab OKR feature allows project members to track Objectives (big picture goals) and Key Results (smaller, measurable steps). By design, promoting a Key Result to an Objective should require project membership rights.

Due to a missing or flawed authorization check, non-members (including unauthenticated users, if the project allowed public access) could directly call the endpoint that handles the promotion. This left space for attackers to move or escalate OKR items they should never be able to touch.

How It Works Internally

When you click to "promote" a Key Result in GitLab, the frontend sends an HTTP request (typically POST/PUT) to a controller endpoint, likely something like:

POST /api/v4/projects/:id/objectives/:objective_id/key_results/:key_result_id/promote

Normally, this would check that your session is valid and you are a project member with the right role (e.g., Developer). But in these vulnerable versions, *the server did not properly enforce these restrictions* on that endpoint.

Code Snippet: Simulated Exploit Path

Here’s a simplified version of what might be happening under the hood. (Note: For illustration, not literal GitLab source code.)

# Vulnerable endpoint
def promote_key_result
  # BAD: No check for current_user membership in the project
  key_result = KeyResult.find(params[:key_result_id])
  objective = Objective.find(params[:objective_id])

  key_result.promote_to_objective! # Promotes regardless of user role
  render json: { success: true }
end

A fixed version would look like

def promote_key_result
  unless project.members.include?(current_user)
    render json: { error: "Unauthorized" }, status: :forbidden
    return
  end

  key_result = KeyResult.find(params[:key_result_id])
  key_result.promote_to_objective!
  render json: { success: true }
end

An attacker learns the GitLab instance is publicly available.

- The attacker can see Objectives and Key Results of a public project (or even an internal one, if not careful).

Using tools like curl or Burp Suite, send a crafted HTTP request

curl -X POST \
  "https://gitlab.example.com/api/v4/projects/101/objectives/75/key_results/120/promote"; \
  -H "Content-Type: application/json"

Step 3: Observe Results

- The Key Result is now promoted to an Objective, even though the attacker isn't (and shouldn’t be) allowed to do this.

Why Does This Matter?

- Confusion for Team Members: OKRs can be pivotal to teams. Suddenly seeing key results swapped with objectives can wreck planning and tracking.
- Potential for Sabotage: An attacker can downgrade or upgrade priorities or milestones—imagine the confusion and lost productivity.
- Trust Erosion: Stakeholders trust project metrics. If these are manipulated, the whole OKR system loses credibility.

17.1.1

GitLab upgrade guide

Conclusion

CVE-2024-4011 is a clear reminder that access control bugs can slip through even in major, mature codebases. Scrutinize your project’s GitLab version, restrict visibility where possible, and make sure to always update to the latest security release.

Stay secure, and keep your teams on track!

Author: [Your Name]
Date: June 2024

Timeline

Published on: 06/27/2024 00:15:11 UTC
Last modified on: 06/28/2024 13:21:27 UTC