CVE-2024-8124

What it actually does

A large glm_source parameter triggers excessive resource consumption in request processing, resulting in denial of service.

Why it matters to the business

GitLab instances become unavailable, halting code reviews, merges, and CI/CD pipelines until the service is restored.

How an attack unfolds

An attacker crafts an HTTP request containing an oversized glm_source value and sends it to an exposed GitLab endpoint; the server allocates disproportionate memory or CPU while parsing the parameter, causing the application or worker processes to crash or become unresponsive.

How to fix it

Upgrade GitLab to 17.1.7, 17.2.5, or 17.3.2 (or later) which contain the fix in commit 84cf95d60d2691201b17bb4d41a95987ded847fb. Apply the upgrade through the standard GitLab update process and restart services.

How to confirm the fix worked

After upgrade, confirm the running version matches one of the fixed releases and test that requests with large glm_source parameters are rejected or handled without resource exhaustion.

Typical attack path

1. Identify a reachable GitLab instance running an affected version
2. Construct a request with an abnormally large glm_source parameter
3. Transmit the request to the vulnerable endpoint
4. Observe service degradation or crash confirming successful DoS

How to detect it

Inspect web server and application logs for unusually large request bodies or glm_source parameters; correlate with spikes in memory or CPU usage on GitLab workers and Puma/Unicorn processes.

What your security team should do

• Immediately schedule upgrade to a fixed release
• Monitor request sizes and resource utilization on GitLab hosts until patched
• Review and tighten any public-facing endpoint rate limits as a temporary control