GitLab critical patches include one for a bug that allows code execution by unauthenticated users
InfoWorld ·
GitLab on Wednesday published updated versions of its Community Edition (CE) and Enterprise Edition (EE) that address a dozen bugs and security issues, including some that allow various unauthenticated actions. The most serious of the security issues, labeled critical in severity, is CVE-2026-110264 , an integer overflow issue. “GitLab has remediated an issue that, under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server due to integer overflow when compiling a specially crafted regular expression,” GitLab said in its bulletin . “In addition to our standard patch releases, we have backported this fix to GitLab CE/EE versions 18.11.13, 19.0.10, 19.1.9, and 19.2.9.” Impacted versions of GitLab CE/EE include all versions from 7.0 before 18.11.13, 19.0 before 19.0.10, 19.1 before 19.1.9, 19.2 before 19.2.9, 19.3 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1. The patched releases are versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. The patches also fix a high severity flaw tracked as CVE-2026-15723 , an improper authentication issue in OmniAuth-to-LDAP auto-linking email lookup that impacts GitLab CE/EE, which is an issue, GitLab said, because “when OmniAuth SAML and LDAP auto-linking were both enabled, an authenticated user could have taken over an existing LDAP-backed account without any interaction from the targeted user, due to improper input sanitization in the LDAP email lookup path used during OmniAuth identity linking.” This is the fourth critical security issue that GitLab has experienced within two months. Earlier in October, it patched a maximum severity regex flaw , and in September, it fixed CVE-2026-85706 , also rated perfect 10 in severity. Another September report also revealed a concerning issue: a long-lived token that puts CI/CD security at risk . Immediate action needed Analysts and consultants agreed that the current holes are serious and merit immediate action. “What really stands out to me is the underlying source of the vulnerability,” said Noah Kenney , principal consultant at Digital 520. “The issue originates in an integer overflow within the regular expression compiler, rather than functionality developed specifically by GitLab.” He pointed out that this distinction is important because it highlights the risks associated with dependencies and shared software components. “Organizations can invest heavily in securing their own applications while remaining exposed to vulnerabilities introduced through underlying libraries and frameworks,” he said. “The fact that this issue potentially affects releases dating back to GitLab 7.0 demonstrates how long these vulnerabilities can persist before being identified and remediated.” Kenney added that CISOs should pay particular attention to one brief mention within the GitLab post. “Buried in the bug fixes, not even in the CVE list, is a line about stripping the trusted flag from client-supplied MCP tools in Workhorse,” he said. “In plain terms, GitLab found a path where an AI agent could be handed tools it should not have trusted and quietly closed it. This raises an important issue surrounding trust boundaries in AI-enabled systems.” Frank Dickson , principal analyst at Dickson Research, noted that the holes are especially troubling because of the highly-integrated nature of GitLab systems. “GitLab is not just a code repository. It holds the source code, the CI/CD pipelines, and very often the secrets those pipelines use to deploy to production,” he said. “Owning the GitLab server means owning the keys to the kingdom. An attacker does not need to break into production when the system that builds production will do it for them.” Dickson also flagged the fact that these fixes may need a lot of time to deploy. “Plan for downtime,” he said. “GitLab’s release notes say this patch includes database migrations, and single-node instances will be down while they run. Someone will ask to wait for the weekend. Waiting is a risk acceptance. That decision belongs to an executive, not to the DevOps team.” Additional risks In addition, he pointed out that the nature of these flaws is a strong heads-up that many other enterprise vendors might also suffer from similar issues. “The flaw sits in Ruby, not just in GitLab’s own code. GitLab’s release notes show the fix ships as a patch to Ruby’s regular expression handling, and one of its detections is named for Onigmo, Ruby’s regex engine,” Dickson said. “GitLab may not be the only Ruby application carrying this bug. CISOs should ask their other vendors.” As well, Ty Coffee , principal at advisory firm UHY, noted that the LDAP bug raises the risk that a post-breach investigation could accidentally point the finger at an innocent employee. “If an attacker takes over an LDAP-backed account, everything they do is logged under a legitimate employee’s name, and your audit trail then points at the wrong person,” Coffee said. “CISOs should also check for shadow and legacy GitLab servers such as team-run instances, old DR copies, acquired-company servers, [because] this affects versions back to 7.0 and that means forgotten boxes are in scope.”