GitLab has remediated an issue in GitLab CE/EE affecting all versions from 19.2 before 19.2.7

CVE-2026-93577 is an integer overflow (CWE-190) in the regular expression compiler that GitLab CE/EE uses to parse CI/CD pipeline configurations. An authenticated user — anyone who can push a .gitlab-ci.yml file or open a merge request against a repo with CI enabled — can craft a regex pattern that triggers the overflow during compilation. The overflow corrupts memory in a way that yields arbitrary code execution on the GitLab application server process. Affected versions span every release from 19.2 through 19.2.6, 19.3 through 19.3.2, and 19.4.0. It shares the same regex-engine attack surface with companion bug CVE-2026-89078 (a double-free in the same parser). Fixed in 19.2.7, 19.3.3, and 19.4.1, released 2026-09-23.

The vendor CVSS of 9.9 is *justified and, if anything, generous only in the decimal*. The vector — AV:N/AC:L/PR:L/UI:N/S:C — accurately captures the low bar: network-reachable, trivial complexity, low-privilege auth, no user interaction, scope-change to the underlying server. GitLab is not a commodity workstation app; it is the CI/CD platform, the artifact store, the container registry, and the source-code repository for most organizations that deploy it. RCE on this host is tantamount to supply-chain compromise. The only friction is the authentication gate, and GitLab instances routinely allow self-registration, external contributors, or broad internal user bases — making that gate thinner than the CVSS PR:L label implies. No public PoC or wild exploitation is confirmed yet, which shaves a hair off urgency but does not change the blast radius.

1. CRITICAL 9.6→CRITICAL 9.2
   Disable open user registration immediately — Navigate to Admin Area → Settings → General → Sign-up restrictions and uncheck *Sign-up enabled*. This eliminates the easiest path for external attackers to obtain the required authenticated session. Enforce SSO/SAML as the sole authentication method if possible. Deploy within the noisgate mitigation SLA of 3 days for CRITICAL findings — ideally within hours given the low effort required.
2. CRITICAL 9.6→HIGH 8.2
   Restrict CI/CD pipeline creation from forks and unprotected branches — Set Settings → CI/CD → General pipelines → CI/CD configuration fetch strategy to limit pipeline triggers to protected branches only. Enable merge request approval policies that require maintainer approval before CI runs on MR pipelines from forks. This breaks step 3 of the attack path for external contributors and low-privilege users. Deploy within 3 days.
3. CRITICAL 9.6→CRITICAL 9.0
   Deploy host-based monitoring on the GitLab server — Install or verify EDR/agent coverage on the GitLab application server. Alert on: (a) unexpected child processes spawned by Puma or Sidekiq workers, (b) execve calls from the git user that are not standard Git operations, (c) crash dumps or segfaults in /var/log/gitlab/. This does not prevent exploitation but enables rapid detection and response. Deploy within 3 days.
4. CRITICAL 9.6→CRITICAL 9.0
   Place GitLab behind a WAF or reverse proxy with authentication hardening — If GitLab is internet-facing, ensure it sits behind a WAF (Cloudflare, AWS WAF, Imperva) or reverse proxy that can rate-limit and log API/Git push requests. Enforce MFA for all users via the IdP. While a WAF cannot inspect .gitlab-ci.yml content for malicious regexes, MFA and rate-limiting raise the cost of credential abuse. Deploy within 3 days.
5. CRITICAL 9.6→IGNORE 0.0
   Apply the vendor patch (19.2.7, 19.3.3, or 19.4.1) — This is the definitive fix. Upgrade your GitLab self-managed instance to the patched version corresponding to your release train. Single-node instances will experience brief downtime for database migrations; multi-node deployments can use zero-downtime upgrade procedures. This is the only control that fully eliminates the vulnerability. Per the noisgate remediation SLA for CRITICAL, complete within 90 days — but given the supply-chain blast radius and imminent PoC likelihood, aim for <7 days.

Run this script on the GitLab server itself (or any host that can reach the GitLab API) as any user with curl access. Invoke with: bash check_cve_2026_93577.sh https://gitlab.example.com <PRIVATE_TOKEN>. The private token needs only read_api scope (any user). No root/sudo required.

#!/usr/bin/env bash
# check_cve_2026_93577.sh — Verify GitLab is patched against CVE-2026-93577
# Usage: bash check_cve_2026_93577.sh <GITLAB_URL> <API_TOKEN>
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

GITLAB_URL="${1:-}"
TOKEN="${2:-}"

if [[ -z "$GITLAB_URL" || -z "$TOKEN" ]]; then
  echo "Usage: $0 <GITLAB_URL> <API_TOKEN>"
  echo "UNKNOWN — missing arguments"
  exit 2
fi

# Strip trailing slash
GITLAB_URL="${GITLAB_URL%/}"

# Query GitLab version API
RESPONSE=$(curl -sf --max-time 10 \
  -H "PRIVATE-TOKEN: $TOKEN" \
  "${GITLAB_URL}/api/v4/version" 2>/dev/null) || {
  echo "UNKNOWN — could not reach GitLab API at ${GITLAB_URL}"
  exit 2
}

VERSION=$(echo "$RESPONSE" | grep -oP '"version"\s*:\s*"\K[^"]+' 2>/dev/null) || {
  echo "UNKNOWN — could not parse version from API response"
  exit 2
}

echo "Detected GitLab version: $VERSION"

# Parse major.minor.patch
IFS='.' read -r MAJOR MINOR PATCH <<< "$(echo "$VERSION" | grep -oP '^[0-9]+\.[0-9]+\.[0-9]+')"

if [[ -z "$MAJOR" || -z "$MINOR" || -z "$PATCH" ]]; then
  echo "UNKNOWN — could not parse version components from '$VERSION'"
  exit 2
fi

# Vulnerable ranges:
#   19.2.0 - 19.2.6  (fixed in 19.2.7)
#   19.3.0 - 19.3.2  (fixed in 19.3.3)
#   19.4.0           (fixed in 19.4.1)
# Versions < 19.2 are NOT affected.

if (( MAJOR < 19 )); then
  echo "PATCHED — version $VERSION predates the vulnerable code (introduced in 19.2)"
  exit 0
fi

if (( MAJOR > 19 )); then
  echo "PATCHED — version $VERSION is beyond the affected major release"
  exit 0
fi

# MAJOR == 19
if (( MINOR < 2 )); then
  echo "PATCHED — version $VERSION predates the vulnerable code (introduced in 19.2)"
  exit 0
fi

if (( MINOR == 2 )); then
  if (( PATCH >= 7 )); then
    echo "PATCHED — version $VERSION contains the fix (19.2.7+)"
    exit 0
  else
    echo "VULNERABLE — version $VERSION is in the affected range (19.2.0–19.2.6)"
    exit 1
  fi
fi

if (( MINOR == 3 )); then
  if (( PATCH >= 3 )); then
    echo "PATCHED — version $VERSION contains the fix (19.3.3+)"
    exit 0
  else
    echo "VULNERABLE — version $VERSION is in the affected range (19.3.0–19.3.2)"
    exit 1
  fi
fi

if (( MINOR == 4 )); then
  if (( PATCH >= 1 )); then
    echo "PATCHED — version $VERSION contains the fix (19.4.1+)"
    exit 0
  else
    echo "VULNERABLE — version $VERSION is in the affected range (19.4.0)"
    exit 1
  fi
fi

# MINOR > 4 on major 19 — should be safe
echo "PATCHED — version $VERSION is beyond all known affected minor releases"
exit 0

1. GitLab Critical Patch Release 19.4.1, 19.3.3, 19.2.7
2. SecurityOnline — GitLab Critical Patch Release Fixes Severe RCE Flaws
3. Strix AI — CVE-2026-93577 Analysis
4. CVEMon — CVE-2026-93577 Overview & Trends
5. ThreatInt — CVE-2026-93577
6. DEV Community — Sizing Self-Managed GitLab Exposure (Shodan/Censys)
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS — Exploit Prediction Scoring System