GitLab has issued urgent updates for a critical remote code execution vulnerability in self-managed Community Edition and Enterprise Edition installations. Tracked as CVE-2026-110264, the issue has a CVSS score of 10.0 and can be reached over the network without authentication or user interaction, according to the vendor’s assessment.

The vulnerable code has been present since GitLab 7.0, released in 2014. That long exposure window does not mean attackers have exploited the flaw for 12 years, and GitLab has not reported attacks or a public proof of concept. It does mean that organizations running old or overlooked installations should not assume they fall outside the affected range.

Crafted regular expressions can trigger code execution

The vulnerability stems from an integer overflow while the server compiles a specially constructed regular expression. Under the right conditions, malformed input can corrupt memory and allow arbitrary code to run in the GitLab server’s security context. GitLab has withheld the full attack path, which is common while customers are being given time to patch.

The rating describes high potential impact to confidentiality, integrity and availability. A successful attacker could potentially steal repositories and stored secrets, alter code or pipeline configuration, and disrupt the service. GitLab often sits at the center of software delivery, so server compromise can also threaten build runners, deployment credentials and downstream production environments.

The company credited researcher joaxcar for reporting the issue through HackerOne. Release notes reference Ruby regular-expression fixes, offering some context about the affected layer without supplying an exploit recipe. Administrators should avoid making assumptions about which project feature exposes the vulnerable code unless GitLab provides a narrower condition.

Patched versions and affected deployments

Fixes are available in GitLab 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 and 19.5.1. Self-managed customers on an earlier release in those branches should upgrade immediately. GitLab extended the repair across several older branches to give operators more upgrade paths than its usual patch cadence.

GitLab.com is already patched. The vendor also says GitLab Dedicated tenants on 19.3.5-internal0, 19.4.2-internal0 or later already contain the correction. Organizations should still verify their exact deployment and version instead of assuming a hosted or specialized installation is safe.

This flaw is distinct from CVE-2026-97229, another regular-expression-related code execution bug fixed earlier in October. Installing the earlier update does not remediate CVE-2026-110264. Version inventory therefore matters more than relying on the fact that a recent GitLab maintenance window occurred.

Detection and response priorities

GitLab published detection guidance referring to “Onigmo native worker crash” and “Org mode render error burst” signals. These indicators can help defenders locate suspicious processing failures, but their presence is not by itself proof of compromise and their absence does not guarantee that exploitation never occurred.

• Upgrade to a fixed release and confirm the running version after restart.
• Review GitLab application, system and reverse-proxy logs for unusual errors or requests.
• Inspect administrator accounts, access tokens, SSH keys, webhooks and runner registrations.
• Rotate high-value CI/CD and deployment secrets if evidence suggests the server was compromised.
• Check repositories and protected-branch settings for unauthorized changes.

The same release train addresses 11 additional vulnerabilities, including an 8.2-rated account takeover scenario involving OmniAuth-to-LDAP linking and a 7.5-rated OAuth/OIDC discovery cache-poisoning issue. Those fixes add urgency even where teams believe the critical regular-expression path is not exposed.

Upgrades may require database migrations and downtime on single-node installations, while suitable multi-node environments can use GitLab’s zero-downtime procedure. Operational complexity should be planned, but it should not become a reason to defer remediation. With network reachability, no required account and a maximum severity rating, exposed self-managed GitLab servers deserve immediate attention.