CVE-2024-2434

What it actually does

Path traversal flaw permits authenticated users to supply crafted paths that escape intended directories, enabling read access to restricted files and triggering resource exhaustion leading to denial of service.

Why it matters to the business

Organizations running affected GitLab instances risk exposure of sensitive configuration or source code files and unplanned service outages that disrupt development workflows and collaboration.

How an attack unfolds

An attacker with a low-privilege account on a vulnerable GitLab instance crafts HTTP requests containing directory traversal sequences targeting specific endpoints; successful traversal grants access to files outside the expected repository scope or consumes excessive resources causing service degradation.

How to fix it

Upgrade GitLab CE/EE to 16.9.6, 16.10.4, or 16.11.1 or later; the fixes are included in commit 37be6ae4d071c237cf140e2b206ad4062adefcd1. Apply patches immediately given the high CVSS and moderate EPSS.

How to confirm the fix worked

Confirm instance version meets or exceeds 16.9.6/16.10.4/16.11.1; retest affected endpoints with previously successful traversal payloads to verify requests are now rejected or sanitized.

Typical attack path

1. Obtain low-privileged authenticated session on GitLab instance
2. Identify endpoints accepting user-controlled path parameters
3. Inject traversal sequences such as ../ to escape directory boundaries
4. Request restricted file paths or trigger resource-intensive operations
5. Observe successful file disclosure or service unavailability

How to detect it

Inspect GitLab access and application logs for repeated requests containing sequences such as ../ or ..\ targeting file-serving or repository endpoints; correlate with authentication events from low-privilege accounts and look for spikes in 5xx responses or file-read operations outside normal repository paths.

• ../
• ..\
• GET.*repository.*file.*\..*\..*
• path traversal pattern in rails or workhorse logs

What your security team should do

• Prioritize upgrade of all GitLab instances to the fixed releases within the next maintenance window
• Review and restrict low-privilege user access to sensitive project and file endpoints until patched
• Enable enhanced logging of path parameters in GitLab access logs for ongoing monitoring
• Scan internal repositories for any custom integrations that might bypass standard path handling