GitLab RCE: CVE-2021-22205 Explained

A file upload feature does not have to contain complicated application code to become a serious security problem.
The 2021 GitLab ExifTool vulnerability is a great example. A seemingly normal image upload could reach a third-party metadata parser, and a specially crafted file could ultimately lead to remote code execution.

The interesting part is that the vulnerability was not caused by some huge, complicated exploit chain. The key was understanding how GitLab identified and processed uploaded files, then finding a dangerous interaction between GitLab and ExifTool.
⚠️ This article explains the vulnerability and exploit chain at a high level for security research and defensive learning. The original weaponized reverse-shell payload is intentionally omitted.

---

The Vulnerability Chain​

The attack can be understood as a simple chain:

1. GitLab accepts an uploaded file.
2. GitLab processes the file with ExifTool to handle image metadata.
3. ExifTool identifies the file based on its content rather than simply trusting the filename extension.
4. A crafted DjVu file can reach vulnerable parsing logic in affected ExifTool versions.
5. The vulnerable DjVu processing could result in Perl code execution.
6. In GitLab, this could ultimately become unauthenticated remote code execution.

GitLab classified CVE-2021-22205 as a critical vulnerability with a CVSS 3.1 score of 10.0. GitLab described the issue as improper validation of image files passed to a file parser, resulting in remote command execution.

---

Why the File Extension Was Not the Important Part​

One of the interesting lessons from this vulnerability is the difference between a filename and the actual format of a file.
For example, an uploaded file might be called: image.jpg
But its actual contents do not necessarily represent a JPEG image.
File identification can use magic bytes or other content-based signatures. These are bytes near the beginning of a file that help software determine what type of file it is.
That means changing:
image.djvu
to:
image.jpg
does not necessarily make the file a JPEG.

This distinction is important when analyzing file-upload vulnerabilities:

• The filename extension may be controlled by the attacker.
• The application may inspect the file contents.
• A third-party parser may identify the real format.
• Security controls that only check the extension can therefore be bypassed.

In the GitLab case, the interaction between file validation and ExifTool's format detection was an important part of the vulnerability chain.

---

Why DjVu Was Important​

The researcher looked beyond common image formats and found that ExifTool supported the older DjVu format.
This mattered because the vulnerable ExifTool component contained a problem in its DjVu processing.
CVE-2021-22204 describes improper neutralization of user-controlled data in the DjVu format in affected ExifTool versions, allowing arbitrary code execution when a malicious image was parsed. The affected range was ExifTool versions from 7.44 up to, but not including, 12.24.
ExifTool released version 12.24 with a security update for the DjVu reader on April 13, 2021.

---

The Dangerous eval Behavior​

The core technical problem involved Perl code being evaluated while processing specially crafted DjVu metadata.
The important concept is not simply that a function was called eval. The security issue came from attacker-controlled data reaching a code-evaluation path.

Conceptually, the vulnerable flow looked like this:

Untrusted file
↓
DjVu metadata
↓
ExifTool parser
↓
Perl evaluation
↓
Attacker-controlled code execution

A malicious researcher could therefore construct metadata that was interpreted as Perl code instead of being treated as ordinary text.
For a safe demonstration, the idea can be represented with a harmless marker rather than an executable payload:

my $metadata = 'SECURITY_TEST';
my $result = eval $metadata;

The important security lesson is that eval becomes dangerous when untrusted input can reach it as executable code.

---

From ExifTool to GitLab RCE​

The ExifTool vulnerability alone and the GitLab vulnerability should not be treated as exactly the same issue.
CVE-2021-22204 describes the underlying ExifTool arbitrary code execution vulnerability in the DjVu parser.
CVE-2021-22205 describes the resulting GitLab vulnerability caused by improper validation of files passed to ExifTool. GitLab's CNA record describes it as remote command execution and assigns a CVSS 3.1 base score of 10.0.

This distinction is important:

CVE	Affected Component	Problem
CVE-2021-22204	ExifTool	Arbitrary code execution through malicious DjVu data
CVE-2021-22205	GitLab	Remote code execution through malicious uploaded files processed by ExifTool

So the vulnerability chain was essentially:
GitLab file upload → ExifTool → vulnerable DjVu parser → code execution

---

Why This Bug Was So Interesting​

🔥 The most valuable lesson here is not the specific payload.
It is the methodology.
A researcher looking at an image upload feature might initially think:

"This is just an image upload. What could possibly go wrong?"

But a better question is:
"What happens to this file after the server receives it?"
For example:

• Is metadata extracted?
• Is the image resized?
• Is the file converted?
• Is a third-party parser used?
• Does the application identify files using magic bytes?
• Can an unexpected file format reach the parser?
• Does any parser evaluate user-controlled data?

These questions can reveal vulnerabilities that are invisible when looking only at the upload form itself.

---

The Third-Party Parser Problem​

This vulnerability also demonstrates why third-party software is an important part of an application's attack surface.
GitLab was not simply processing the uploaded file itself. It passed image data to ExifTool.
That means the security boundary looked more like:

User Input
↓
GitLab
↓
ExifTool
↓
File Parser
↓
Operating System

Every component in that chain matters.
If the application accepts untrusted input and sends it to a parser with a serious vulnerability, the application can inherit the consequences.

---

What Developers Can Learn From This​

The first lesson is simple: never assume that an uploaded file is safe because its extension looks harmless.
A stronger file-upload design should consider:

• Validate file types using multiple independent checks.
• Do not rely only on filename extensions.
• Keep image and document parsers updated.
• Run parsers with minimal operating-system privileges.
• Isolate risky file-processing components where practical.
• Avoid passing attacker-controlled data into interpreters or evaluators.
• Restrict unnecessary file formats.
• Monitor unexpected parser behavior.
• Treat third-party parsing libraries as part of the application's attack surface.

GitLab later patched the issue in versions 13.8.8, 13.9.6, and 13.10.3. GitLab also stated that confirmed exploitation had occurred against public-facing self-managed instances, while GitLab.com users were not affected.

---

The Bigger Bug Bounty Lesson​

💡 A critical vulnerability does not always begin with complicated code.
Sometimes the important discovery is simply understanding the application's assumptions.
In this case, the interesting assumptions were roughly:
The application expects an image → the parser decides what the file really is → the parser processes attacker-controlled metadata.
Once those assumptions were understood, the researcher could investigate whether an unexpected file format could reach dangerous parser functionality.

That is a useful mindset for security testing:

1. Understand the complete data flow.
2. Identify trust boundaries.
3. Find third-party components.
4. Study how they identify and parse input.
5. Look for dangerous interpretation of attacker-controlled data.
6. Validate the impact safely within the authorized testing scope.

The GitLab incident is a strong example of why understanding how a feature works internally can be more valuable than simply throwing large numbers of automated tools at it. 🔍

---

Frequently Asked Questions​

------------------

What was CVE-2021-22205?​

CVE-2021-22205 was a critical GitLab vulnerability involving improper validation of uploaded image files before they were processed by ExifTool, which could result in remote command execution.

What was CVE-2021-22204?​

CVE-2021-22204 was the underlying ExifTool vulnerability involving malicious DjVu data and arbitrary code execution during parsing.

Was the vulnerability caused by GitLab alone?​

No. The GitLab vulnerability involved the way GitLab handled uploaded files and passed them to ExifTool, while the underlying code-execution flaw was in ExifTool's DjVu processing.

Why was DjVu important?​

DjVu was important because the vulnerable ExifTool parsing path could process attacker-controlled data in a way that resulted in Perl code execution.

What is the main lesson for developers?​

Do not treat file uploads as simple filename-validation problems. The entire processing pipeline-including image converters, metadata extractors, document parsers, and other third-party libraries-must be considered part of the application's security boundary.