CVE-2024-11828

What it actually does

A regression allows crafted API requests to trigger a denial-of-service condition that renders the GitLab instance unresponsive.

Why it matters to the business

Unexpected downtime disrupts development, code review, and CI/CD pipelines for organizations running affected GitLab versions, with stable but non-zero exploit probability requiring timely patching.

How an attack unfolds

An attacker locates a GitLab instance running an affected version and repeatedly submits specially crafted API calls that exploit the regression, exhausting resources and producing a sustained DoS state.

How to fix it

Upgrade GitLab CE/EE to 17.4.5, 17.5.3, or 17.6.1 (or apply commit 3ead12a16d7bd8f1c481504e03042aaf6e10f108). For heat on Ubuntu 16.04 LTS apply package version 1:6.1.2-0ubuntu1. Enable API rate limiting and authentication hardening as interim controls.

How to confirm the fix worked

Confirm the running version matches a fixed release, replay previously successful crafted requests to verify they no longer cause DoS, and review release notes for the regression fix.

Typical attack path

1. Scan for publicly reachable GitLab instances and identify version via banners or API responses
2. Craft and send malicious API requests targeting the vulnerable code path
3. Observe resource exhaustion or service unavailability confirming the DoS condition

How to detect it

Review GitLab access and application logs for repeated unusual API requests, spikes in CPU or memory usage uncorrelated with normal traffic, and service restart events following high-load periods.

What your security team should do

• Prioritize upgrade of all GitLab instances within the next maintenance window
• Monitor API traffic volume and error rates for anomalous patterns
• Apply network-level rate limiting on API endpoints until patches are deployed