GitLab Discloses 12-Year-Old CVSS 10.0 Vulnerability Enabling Unauthenticated Remote Code Execution

GitLab has published a critical security advisory for CVE-2026-110264, a CVSS 10.0 flaw that permits unauthenticated remote code execution on both Community and Enterprise self-hosted instances. The vulnerability has existed in the codebase since 2014 and affects every version up to the latest release prior to the October 2026 patch. Exploitation requires no credentials or special conditions, allowing attackers to run arbitrary commands, exfiltrate source code, deploy backdoors, or move laterally. The issue remained undetected through multiple code iterations, security audits, and version updates due to its hidden trigger conditions within the large, complex application. Organizations are urged to immediately verify their version, review access logs for anomalies, and apply the official fix, while temporary mitigations include network restrictions and enhanced monitoring.

安全客Translated from Chinese

Read at source

GitLab has disclosed a CVSS 10.0 vulnerability, CVE-2026-110264, that enables unauthenticated remote code execution on self-hosted instances. The flaw has remained present in both Community and Enterprise editions for twelve years, dating back to the platform’s early releases in 2014.

Impact and Exploitation

The maximum CVSS score reflects an extremely low attack threshold: an adversary needs only network access to the GitLab server to execute arbitrary commands. Attackers can download repositories, implant persistent backdoors, perform lateral movement, or deploy ransomware without any authentication.

Comparisons with prior critical issues highlight the severity. The 2021 Log4Shell vulnerability also scored 10.0 but required log interaction, while the 2024 MOVEit Transfer flaw scored 9.8 and needed additional preconditions. In contrast, the GitLab issue needs no special steps beyond reaching the server.

Why the Vulnerability Persisted

GitLab’s extensive codebase, exceeding one million lines and encompassing code hosting, CI/CD pipelines, issue tracking, wikis, and container registries, makes comprehensive auditing difficult. The flaw arises from subtle logic errors across multiple modules rather than an obvious coding mistake, evading routine testing and security reviews.

Resource constraints on open-source projects further limit deep historical code analysis, allowing the defect to survive repeated updates until the October 2026 patch.

Immediate Actions for Administrators

  • Verify the current GitLab version against the advisory and upgrade to the patched release.
  • Examine access logs for suspicious IP addresses, off-hour activity, and unauthorized API calls.
  • Inspect administrator accounts, repository commits, and CI/CD pipelines for signs of compromise.

Self-hosted deployments often contain proprietary source code, configuration files, and secrets, making rapid response essential.

Temporary Mitigations

When immediate upgrades are impractical, organizations should restrict access via firewalls or WAF rules to approved internal or whitelisted IPs, deploy additional process and network monitoring, maintain verified backups, and enforce least-privilege access with mandatory multi-factor authentication for administrators.

Industry Implications

The incident underscores that security in large, long-lived software projects is an ongoing process rather than a one-time task. Regular vulnerability management, continuous code auditing, and timely patch application remain critical responsibilities for any organization running self-hosted GitLab instances.

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Vulnerabilities & Exploits

Telegram for Android Patches Voice Call Vulnerability Enabling Code Execution
Yandex Patches Millions of Stations After eMudhra Certificate Keys Compromised
Cisco ASA and FTD Face DoS Vulnerability in SSL VPN Already Exploited in the Wild