An issue has been discovered in GitLab CE/EE affecting all versions starting from 11

CVE-2021-22205 is GitLab CE/EE remote code execution caused by GitLab Workhorse handing uploaded jpg|jpeg|tiff files to a vulnerable ExifTool parser. GitLab and NVD track affected self-managed versions as >=11.9,<13.8.8, >=13.9,<13.9.6, and >=13.10,<13.10.3; the April 14, 2021 fixes landed in 13.8.8, 13.9.6, and 13.10.3. The root cause is the bundled ExifTool path behind image processing, so a crafted image can become code execution as the git service account.

The vendor's CRITICAL 10.0 is mostly justified in practice because this became an unauthenticated internet-reachable RCE, public exploits exist, and CISA KEV confirms real-world exploitation. The only meaningful downward pressure is population: this hits self-managed GitLab, not GitLab.com, and private/VPN-only instances are much safer. But for any internet-facing unpatched instance, this is still an edge compromise of a CI/source-code platform, which is exactly the kind of foothold attackers monetize.

Why this verdict

• Baseline stays brutal: vendor score 10.0 is anchored in an unauthenticated network RCE with no user interaction.
• KEV and exploitation keep it at the top: CISA KEV plus GitLab/Rapid7 reporting means this is not theoretical and not waiting for an attacker to innovate.
• Public-edge precondition is common enough: internet-facing GitLab is a realistic enterprise pattern, and exposed source-control platforms are high-value targets.
• Blast radius is worse than host-only RCE: compromise of GitLab can expose repositories, CI/CD secrets, deploy keys, runners, and downstream software supply chain trust.
• Slight downward pressure exists: this is not every GitLab deployment, GitLab.com is unaffected, and private/VPN-only instances remove the unauthenticated internet path.

Why not higher?

There is no practical bucket above CRITICAL, and that is exactly why this lands here. The only reason the score is not a clean 10.0 is environmental narrowing: self-managed only, reduced risk on non-internet-facing deployments, and initial execution is typically as git rather than immediate root.

Why not lower?

A lower severity would ignore the most important facts: no auth required, public exploit availability, and KEV-confirmed exploitation. This is not a post-initial-access bug or a narrow admin-only feature flaw; it is an edge RCE against a platform that often contains crown-jewel developer secrets.

1. Pull public GitLab behind VPN or IP allowlists — Remove the unauthenticated internet path first. Because this CVE is KEV-listed, treat this as patch / mitigate immediately, within hours; if the UI does not need to be public, make it non-public before you finish normal patch change control.
2. Apply the GitLab hotpatch if upgrade is blocked — GitLab published a hotpatch specifically for customers who could not move to fixed versions immediately. Use it only as an emergency bridge and deploy it within hours on exposed systems while you prepare the full vendor upgrade.
3. Upgrade to 13.8.8 / 13.9.6 / 13.10.3 or later supported releases — The permanent fix is the vendor release, not a compensating story. For exposed or internet-reachable instances, do this immediately, within hours because active exploitation overrides the usual critical-window pacing.
4. Hunt for post-exploit persistence — GitLab's own incident guidance warns that scripts and crontab persistence may remain even after patching. Start this review within hours on any system that was public-facing and vulnerable, because patching alone does not evict a prior compromise.
5. Rotate GitLab-adjacent secrets after suspected exposure — If a vulnerable internet-facing instance was exposed, assume repo access, CI variables, tokens, deploy keys, and webhook secrets may have been read. Begin rotation within hours for any suspected-compromise system to reduce supply-chain follow-on risk.

Run this on the target GitLab host as root or with sudo, because it reads local install paths and may call gitlab-rake. Save as verify-cve-2021-22205.sh and run sudo bash verify-cve-2021-22205.sh for auto-detect, or sudo bash verify-cve-2021-22205.sh 13.10.2 to test a specific version string. It outputs VULNERABLE, PATCHED, or UNKNOWN and exits 1, 0, or 2 respectively.

#!/usr/bin/env bash
# verify-cve-2021-22205.sh
# Best-effort local checker for GitLab CE/EE CVE-2021-22205.
# Exit codes:
#   0 = PATCHED / not affected
#   1 = VULNERABLE
#   2 = UNKNOWN / unable to determine

set -u

normalize_version() {
  local v="$1"
  v="${v#v}"
  v="${v%%-*}"
  printf '%s' "$v"
}

is_semver_like() {
  [[ "$1" =~ ^[0-9]+\.[0-9]+(\.[0-9]+)?$ ]]
}

ver_lt() {
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ] && [ "$1" != "$2" ]
}

ver_ge() {
  [ "$1" = "$2" ] || ! ver_lt "$1" "$2"
}

get_version() {
  local v=""

  if [ $# -ge 1 ] && [ -n "$1" ]; then
    printf '%s' "$1"
    return 0
  fi

  if command -v gitlab-rake >/dev/null 2>&1; then
    v=$(gitlab-rake gitlab:env:info 2>/dev/null | awk -F': ' '/GitLab version/ {print $2; exit}')
    if [ -n "$v" ]; then
      printf '%s' "$v"
      return 0
    fi
  fi

  if [ -r /opt/gitlab/embedded/service/gitlab-rails/VERSION ]; then
    v=$(head -n1 /opt/gitlab/embedded/service/gitlab-rails/VERSION 2>/dev/null || true)
    if [ -n "$v" ]; then
      printf '%s' "$v"
      return 0
    fi
  fi

  if [ -r /home/git/gitlab/VERSION ]; then
    v=$(head -n1 /home/git/gitlab/VERSION 2>/dev/null || true)
    if [ -n "$v" ]; then
      printf '%s' "$v"
      return 0
    fi
  fi

  return 1
}

main() {
  local raw_version version

  if ! raw_version=$(get_version "${1-}"); then
    echo "UNKNOWN - could not determine local GitLab version"
    exit 2
  fi

  version=$(normalize_version "$raw_version")

  if ! is_semver_like "$version"; then
    echo "UNKNOWN - detected version '$raw_version' is not a simple upstream semver; check distro backports/package changelog manually"
    exit 2
  fi

  # Affected ranges from GitLab/NVD:
  #   >=11.9,<13.8.8
  #   >=13.9,<13.9.6
  #   >=13.10,<13.10.3

  if ver_ge "$version" "13.10" && ver_lt "$version" "13.10.3"; then
    echo "VULNERABLE - GitLab version $version is in affected range >=13.10,<13.10.3"
    exit 1
  fi

  if ver_ge "$version" "13.9" && ver_lt "$version" "13.9.6"; then
    echo "VULNERABLE - GitLab version $version is in affected range >=13.9,<13.9.6"
    exit 1
  fi

  if ver_ge "$version" "11.9" && ver_lt "$version" "13.8.8"; then
    echo "VULNERABLE - GitLab version $version is in affected range >=11.9,<13.8.8"
    exit 1
  fi

  if ver_lt "$version" "11.9"; then
    echo "PATCHED - GitLab version $version is below the affected floor (not affected by CVE-2021-22205)"
    exit 0
  fi

  echo "PATCHED - GitLab version $version is outside the published affected ranges"
  exit 0
}

main "$@"

Sources

1. GitLab critical security release (fixed versions)
2. GitLab action needed blog (confirmed exploitation, hotpatch)
3. NVD CVE-2021-22205
4. CISA KEV catalog print entry
5. Rapid7 exploited-in-the-wild analysis
6. Censys exposure analysis
7. CVE record at CVE.org
8. FIRST EPSS documentation