CVE-2026-110264: Critical GitLab RCE Flaw Affects 12 Years of Releases

GitLab has released urgent security updates addressing CVE-2026-110264, a maximum-severity vulnerability that could allow an unauthenticated attacker to execute arbitrary code on vulnerable self-managed GitLab servers. The flaw carries a CVSS score of 10.0 and affects both GitLab Community Edition (CE) and Enterprise Edition (EE).

The vulnerability is particularly notable because the affected code dates back to GitLab 7.0, released in 2014. This leaves roughly 12 years of GitLab releases within the vulnerable range, although there is currently no evidence that attackers have been exploiting the weakness throughout that period. GitLab disclosed the issue and released patched versions on October 21, 2026.

The vulnerability originates from an integer overflow triggered while GitLab compiles a specially crafted regular expression. Under certain conditions, an unauthenticated attacker could use that condition to execute arbitrary code on the underlying GitLab server. GitLab has intentionally withheld the complete exploitation path and specific prerequisites while administrators deploy patches.

For organizations running self-managed GitLab infrastructure, the potential impact is severe. GitLab repositories frequently contain source code, CI/CD configuration, deployment secrets, access tokens, infrastructure definitions, and connections to production environments. Server-level compromise could therefore create opportunities for credential theft, repository manipulation, supply chain attacks, persistence, or lateral movement.

Security teams looking for CVE-2026-110264 detection opportunities can leverage SOC Prime’s AI-Native Detection Intelligence Platform to strengthen visibility into vulnerability exploitation and related post-compromise behavior across SIEM, EDR, and Data Lake environments.

Click Explore Detections to access relevant detection content and hunting logic. To Detect CVE-2026-110264 exploitation attempts, defenders should correlate GitLab application telemetry with process execution, abnormal server behavior, and GitLab’s newly released threat-detection logic.

Security practitioners can also use Prime Architect to transform emerging vulnerability intelligence into Sigma rules and hunting queries, validate detection logic, generate relevant Attack Flows, and translate detection content across supported security platforms.

Contact Sales

CVE-2026-110264 analysis

GitLab describes the vulnerability as an integer overflow in its regular expression compiler. Under certain conditions, compiling a specially crafted regular expression can lead to arbitrary code execution on the GitLab server without authentication.

GitLab assigned the vulnerability the maximum CVSS v3.1 score of 10.0, with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. This reflects a network-accessible vulnerability with low attack complexity, no required privileges, and no user interaction, with potentially high impact on confidentiality, integrity, and availability.

Security researcher joaxcar discovered and reported the vulnerability through GitLab’s HackerOne bug bounty program. GitLab’s release notes also reference patches to Ruby regular-expression handling, while reporting indicates that the underlying affected engine is Onigmo, Ruby’s regular-expression implementation bundled into GitLab packages.

CVE-2026-110264 affects GitLab CE and EE across an unusually broad range:

• GitLab 7.0 through versions before 18.11.13
• GitLab 19.0 before 19.0.10
• GitLab 19.1 before 19.1.9
• GitLab 19.2 before 19.2.9
• GitLab 19.3 before 19.3.6
• GitLab 19.4 before 19.4.3
• GitLab 19.5 before 19.5.1

GitLab backported the fix to 18.11.13, 19.0.10, 19.1.9, and 19.2.9 in addition to its normal supported patch branches because of the severity and unusually broad exposure.

The long vulnerable window does not mean the flaw has been actively exploited since 2014. Rather, the vulnerable regular-expression functionality existed throughout releases dating back to GitLab 7.0. Neither GitLab nor the two supplied reports has confirmed exploitation in real-world attacks as of October 22, 2026.

This vulnerability should also not be confused with CVE-2026-97229, another critical GitLab remote code execution flaw related to regular-expression processing that was patched earlier in October. That issue affected a narrower range of more recent releases. Installing the October 12 fixes for that vulnerability does not automatically protect systems from this newly disclosed flaw.

Administrators who recently updated GitLab therefore need to verify their exact installed build rather than assuming a previous October security release provides sufficient protection.

The currently available details for CVE-2026-110264 do not disclose the precise attacker-controlled input, endpoint, feature, or conditions required to reach the vulnerable regular-expression compiler. GitLab generally makes detailed security issues public 90 days after the release containing a fix, reducing the immediate availability of weaponizable technical information while customers patch.

No public CVE-2026-110264 PoC has been disclosed in the supplied reports or GitLab advisory. Cybersecurity News specifically notes that GitLab has not published a public exploit, while the company has limited disclosure of the complete attack path.

At the same time, the absence of a public proof of concept should not be interpreted as low risk. A remotely reachable, unauthenticated vulnerability with a CVSS 10.0 rating presents an attractive target, particularly because self-managed GitLab servers are frequently exposed to the internet.

There are currently no campaign-specific CVE-2026-110264 IOCs such as malicious IP addresses, domains, payload hashes, or confirmed exploit request patterns because neither GitLab nor the cited security researchers have reported active exploitation.

GitLab has, however, published two threat detections intended to identify possible exploitation attempts on self-managed installations:

• Onigmo native worker crash
• Org mode render error burst

These detections are designed to identify suspicious behavior related to attempts to trigger the vulnerability. Their presence does not by itself confirm successful compromise and should be correlated with broader application and endpoint telemetry.

Security teams should investigate unexpected GitLab application crashes, bursts of rendering errors, anomalous processes originating from GitLab or Ruby components, unexpected shell execution, newly created persistence mechanisms, and outbound connections from GitLab servers that deviate from normal operational patterns.

CVE-2026-110264 mitigation

GitLab strongly recommends that all organizations operating affected self-managed installations upgrade immediately. The fixed versions are:

GitLab.com has already been updated. GitLab Dedicated tenants running internal versions 19.3.5-internal0, 19.4.2-internal0, or later already contain the necessary fixes and do not need to take action for this vulnerability.

Self-managed customers should not delay remediation while waiting for additional exploitation details. GitLab has not published an alternative workaround that provides equivalent protection, making installation of the fixed release the reliable remediation path.

Before upgrading, administrators should review GitLab’s upgrade documentation and account for database migrations. GitLab warns that single-node deployments may experience downtime while migrations complete, whereas properly configured multi-node environments can follow the vendor’s zero-downtime upgrade process. Versions 19.3.6 and 19.4.3 contain regular migrations, and 19.4.3 also includes a post-deploy migration.

After patching, security teams should perform retrospective analysis rather than treating the update itself as proof that a server was never targeted. Review GitLab application logs for the two exploitation indicators published by GitLab and investigate suspicious activity preceding the upgrade.

Defenders should also examine operating-system telemetry for:

• Unexpected child processes originating from GitLab, Ruby, or associated workers
• Shell or scripting interpreter execution under GitLab service accounts
• New SSH keys or administrative accounts
• Unexpected modifications to repositories or CI/CD pipelines
• Newly created scheduled jobs or persistence mechanisms
• Changes to runners, deploy tokens, personal access tokens, and project access tokens
• Unusual outbound connections from the GitLab server
• Unauthorized access to secrets stored in CI/CD variables
• Unexpected package, release, or repository modifications

If compromise is suspected, organizations should isolate the server, preserve logs and forensic artifacts, rotate potentially exposed credentials and tokens, and validate the integrity of repositories and CI/CD workflows before returning the instance to production.

Because GitLab installations often act as trusted infrastructure within software development pipelines, responders should also determine whether an attacker could have modified source code, artifacts, container images, infrastructure-as-code templates, or deployment workflows. A compromised GitLab server can create downstream supply chain risk even after the original server is remediated.

SOC Prime’s AI-Native Detection Intelligence Platform can help organizations strengthen their detection posture against emerging vulnerability exploitation by providing continuously updated behavior-based detection content mapped to MITRE ATT&CK®.

Disclaimer: Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not available yet, check back as new threat intelligence and detection content are continuously added.