CVE-2023-0632 - How a Crafted Regex Brought Down GitLab’s Harbor Registry Search

When it comes to securing modern DevOps tools, even small bugs can have devastating effects. In early 2023, security researchers discovered a flaw in GitLab—one of the world’s most widely used source code platforms—that allowed an attacker to take down an important feature with a simple trick. Here’s everything you need to know about CVE-2023-0632: how it worked, which systems were affected, and why it matters.

What is CVE-2023-0632?

CVE-2023-0632 is the official tracking identifier for a security issue in GitLab’s integration with the Harbor container registry. Specifically, a poorly-coded regular expression (regex) made it possible for a remote attacker to cause a Denial of Service (DoS) by sending specially crafted "search" requests.

GitLab 16.2 _before 16.2.2_

If you’re running any of these, you should patch immediately.

> References:
> - GitLab Official Advisory
> - NVD Entry for CVE-2023-0632
> - Harbor Registry

The Problem: Inefficient Regex Search

Regular expressions are helpful for searching or filtering text—they let you specify patterns instead of exact text. But some patterns, when applied to certain inputs, can take a _very_ long time to process. If your code accepts user input in a regex, you risk "Regular Expression Denial of Service" (ReDoS).

In GitLab, the user’s input was passed directly to a regex that matched against Harbor registry objects. Attackers found they could submit a _maliciously crafted regex pattern_ that caused the Harbor service (within GitLab) to hang for a very long time, tying up CPU and memory until the process crashed or became unresponsive.

Example Code (Illustrative Snippet)

def search_harbor_registry(query)
  # BAD: User input passed directly into regex
  images = HarborRegistry.list_all_images
  images.select { |img| img.name =~ /#{query}/ }
end

# An attacker could submit:
attack_query = '(a+)+$'
# Or something even nastier targeting catastrophic backtracking, like:
attack_query = '((a|a?)+)+b'

search_harbor_registry(attack_query)

The regex /((a|a?)+)+b/ is particularly nasty. If you feed it a string of thousands of 'a's, the engine takes exponentially longer to decide there's _no_ match.

Realistic Example of an Exploit Request (cURL)

curl -u "USERNAME:TOKEN" \
  "https://gitlab.example.com/api/v4/harbor/registry/search?query=((a|a?)+)+b";

Why Is This Serious?

- Easy Exploit – No special access needed; just a legitimate user account or even a compromised token.

Wide Impact – All Docker images and container registries via Harbor could be targeted.

- Resource Exhaustion – Enough requests could bring an entire GitLab/Harbor cluster to its knees.

How Was It Fixed?

GitLab resolved the vulnerability by properly sanitizing user input and ensuring regex patterns either _cannot_ be user-controlled or _only_ accept safe, validated patterns.

Lessons Learned

This bug is a textbook case of why you should _never_ pass user input directly into a regex, especially in production software. It’s not only open to DoS—but also a sign that further input validation might be lacking in other places.

Conclusion

CVE-2023-0632 is a warning to all developers: beware of the power of regular expressions in the wrong hands. Even seemingly innocent user search functions can open the door to service outages. Stay up-to-date, escape your input, and always keep an eye on your logs—because the next crafted packet might just be the one that takes you down.

Timeline

Published on: 08/02/2023 00:15:00 UTC
Last modified on: 08/04/2023 19:02:00 UTC