Thousands of GitLab Instances Remain Exposed to Critical Remote Code Execution Flaw

Security researchers have identified more than 1,000 GitLab servers that are openly reachable on the Internet and still lack patches for a critical remote code execution (RCE) vulnerability that is currently being weaponized by attackers.

The flaw, classified as maximum severity by the Common Vulnerability Scoring System, allows an adversary to run arbitrary commands on the affected host simply by sending specially crafted requests to the GitLab web interface. While the exact CVE identifier was not disclosed in the initial report, the vulnerability carries a CVSS score of 10.0, indicating the highest level of risk.

GitLab is a widely adopted platform for source‑code management, continuous integration, and DevOps workflow automation. Many organizations host their own GitLab instances rather than using the cloud‑based service, often exposing the web UI to the public Internet to facilitate remote collaboration. This convenience can become a liability when critical patches are not applied promptly.

The numbers stem from a systematic scan conducted by the cybersecurity outlet that first reported the issue. Researchers queried public IP ranges for GitLab installations that responded to known version fingerprints and then cross‑referenced those versions against the vendor’s advisory list. Servers still running versions older than the latest security release were flagged as vulnerable, resulting in the count of over 1,000 exposed instances.

Exploitation of the vulnerability can give threat actors full control over the compromised server, including the ability to steal source code, inject malicious payloads into CI pipelines, and pivot laterally into connected systems. Given the central role GitLab plays in software development, a breach could cascade into supply‑chain attacks that affect downstream users of the compromised code.

Security experts urge administrators to prioritize the update to the patched GitLab release, enforce strict network segmentation, and consider placing the service behind a VPN or firewall that limits access to trusted IP ranges. Where immediate upgrading is not feasible, temporary mitigations such as disabling vulnerable endpoints and applying vendor‑provided workarounds can reduce exposure.

The GitLab development team has already issued a security advisory and made the necessary patches available. However, the persistence of unpatched instances underscores a broader challenge: keeping self‑hosted infrastructure up to date in a fast‑moving threat landscape. Ongoing monitoring, automated patch deployment, and regular vulnerability assessments are likely to become standard recommendations as organizations seek to close the gap before attackers can leverage the flaw further.