Key points
- GitLab patched CVE-2026-110264, an integer overflow in regular expression compilation affecting versions back to 7.0.
- The flaw allows unauthenticated remote code execution on self-managed servers under specific conditions.
- Fixes are available in versions 19.5.1, 19.4.3, 19.3.6 and several backported releases.
Unauthenticated attackers can execute arbitrary code on self-managed GitLab servers by exploiting a maximum-severity integer overflow flaw. The vulnerability exists in the regular expression compilation process and affects releases dating back twelve years to version 7.0. GitLab has issued patches for multiple versions and strongly recommends immediate upgrades for all organisations running vulnerable software.
In plain English
The bug occurs when the system processes specially crafted regular expressions. An integer overflow during this compilation allows an attacker to run code on the server without logging in. This bypasses authentication entirely. The issue impacts both Community and Enterprise Editions. Because the flaw is present in versions as old as 2014, many self-managed instances remain exposed. GitLab’s managed infrastructure, including GitLab.com, is already patched and secure.
The background
Johan Carlsson reported the vulnerability via GitLab’s HackerOne bug bounty programme. SOC Prime warned that self-managed GitLab repositories often hold source code, deployment secrets and access tokens. Compromise of the server could lead to credential theft, repository manipulation or supply chain attacks. While there is no confirmed in-the-wild exploitation yet, criminals are expected to scan for vulnerable instances soon. GitLab released two threat detections for customers with self-managed instances.
What changes now
GitLab released fixes in versions 19.5.1, 19.4.3 and 19.3.6. Patches were also backported to versions 19.2.9, 19.1.9, 19.0.10 and 18.11.13. The vendor urges all users to upgrade to a fixed version as soon as possible. Organisations should verify their current version and apply the update immediately. Monitoring for unusual activity remains essential while upgrades are deployed across the environment.
The attacker's path
Teams usually assess exposure by identifying unpatched legacy software versions that remain in production. This type of flaw serves the initial access stage of an intrusion, allowing attackers to bypass authentication entirely. The weakness relies on improper input validation during complex processing tasks. Security operations should monitor for unusual process execution or network connections originating from application servers, as these often indicate successful exploitation of remote code execution vulnerabilities.
Background: Integer overflow vulnerabilities
Use fixed-width integer types and explicit range validation before every arithmetic operation. Compile with warnings enabled and treat all inputs as untrusted. Verify that addition, subtraction, and multiplication results stay within expected bounds. This prevents buffer overflows and logic errors in financial or access control systems.
Read the full guide: Integer Overflow Prevention Checklist for Secure Software Development
What to do and how to stay safe: GitLab
- Inventory all self-managed GitLab instances and verify their current version numbers against the list of patched releases.
- Prioritise upgrading any instance running versions prior to 19.5.1, 19.4.3 or 19.3.6 to mitigate the integer overflow risk.
- Review server logs for signs of unauthenticated access or unusual code execution attempts that may indicate exploitation.
- Deploy the threat detections released by GitLab to identify potential compromise indicators on self-managed infrastructure.
Step-by-step guide: Emergency Patching: Correcting Five Common Operational Errors
General security guidance from the RedTeam Log newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Is GitLab.com affected by this vulnerability?
No, GitLab-managed infrastructure including GitLab.com and GitLab Dedicated remains patched and secure.
What versions of GitLab are vulnerable?
Versions dating back to GitLab 7.0 released in June 2014 are affected, including Community and Enterprise Editions.
Has this bug been exploited in the wild?
There is no indication yet of any in-the-wild exploitation attempts, though scanning is expected.
