TL;DR
Get privacy and security gear delivered free with Prime
- Fast, free delivery on millions of items
- Prime Video, Amazon Music and more included
- Member-only deals all year
GitLab released patched versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13 on Oct. 21, 2026. The release fixes a critical flaw that could allow unauthenticated arbitrary code execution under certain conditions, along with vulnerabilities rated high, medium and low; GitLab urges affected self-managed installations to upgrade promptly.
GitLab released seven patched versions of its Community Edition and Enterprise Edition software on Oct. 21, 2026, addressing a critical regular-expression compiler vulnerability that could allow an unauthenticated user to execute code on a server under certain conditions. The company strongly recommends that operators of affected self-managed installations upgrade immediately; GitLab says GitLab.com is already running a patched version.
The releases are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. GitLab says they contain important bug and security fixes. The most severe listed issue, CVE-2026-110264, is rated critical with a CVSS 3.1 score of 10.0. A specially crafted regular expression could trigger an integer overflow during compilation and, in certain conditions, permit arbitrary code execution without authentication.
GitLab also lists vulnerabilities rated high, medium and low. The high-severity issues include possible account takeover when OmniAuth SAML and LDAP auto-linking are both enabled, and cache poisoning involving OAuth/OpenID Connect discovery endpoints. Other reported issues concern access controls, membership restrictions, response headers, merge request rendering and security findings. GitLab says the fixes apply across CE and EE where specified; some listed issues affect Enterprise Edition only.
The company says GitLab Dedicated tenants running 19.3.5-internal0 or 19.4.2-internal0, or later, already include the fixes and need not act. The release notice also says security fixes are backported to the listed maintenance versions, including 18.11.13, 19.0.10, 19.1.9 and 19.2.9 for the critical regular-expression issue.
The Risk to Self-Managed Servers
The critical flaw matters because GitLab describes a path to server-side code execution without authentication. If exploited, that could put the confidentiality, integrity and availability of an affected GitLab server at risk. The published CVSS vector assigns high impact across those three areas, though the supplied notice does not state that exploitation has been observed.
GitLab’s immediate upgrade recommendation is directed at customers operating their own instances, who must apply the appropriate fixed release. That makes identifying the installed version and deployment type a practical security task for administrators. GitLab says that when a security item does not name a specific deployment type, all types are affected. The notice also says GitLab.com is patched, reducing the need for its users to perform a server upgrade themselves.
The other vulnerabilities show that the release is not limited to one defect: identity linking, cached authentication discovery data and authorization boundaries are among the affected areas. Their relevance depends on configuration and edition, so administrators should consult the full advisory rather than assume every listed issue applies to every installation.
software security patch management tools
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
How GitLab Ships Security Fixes
GitLab says it publishes fixes in both scheduled patch releases and ad hoc critical patches for high-severity vulnerabilities. Its regular releases are scheduled twice a month, on the second and fourth Wednesdays. The Oct. 21 release includes fixes across several supported version branches rather than requiring every installation to move to the newest major version.
The company states that details of security issues are made public on its issue tracker 90 days after the release in which they were patched. The Oct. 21 notice itself provides summaries, affected-version ranges and severity information for a number of issues. For CVE-2026-110264, GitLab credits reporter joaxcar through its HackerOne bug bounty program; it says a GitLab team member discovered the OAuth/OIDC cache-poisoning issue.
For customers on GitLab-managed infrastructure, the release notice says GitLab.com is already patched and qualifying GitLab Dedicated tenants already include the fixes. The main action in the advisory is therefore for operators of affected self-managed systems to move to the corresponding fixed patch version.
“We strongly recommend that all self-managed GitLab installations be upgraded to one of these versions immediately.”
— GitLab
GitLab server security upgrade kit
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Exploitation and Exposure Details
The release notice describes the critical flaw as exploitable under certain conditions, but the supplied material does not identify those conditions in enough detail to determine which configurations are exposed. It also does not report whether CVE-2026-110264 or the other vulnerabilities have been exploited in the wild, or provide evidence of attacks against customers.
The full impact for an individual installation depends on its version, edition and, for some issues, enabled features or configuration. The notice provides affected-version ranges for several vulnerabilities, but the supplied source excerpt ends during the entry for the GraphQL work-item issue. It does not include the full affected-version details for that item or the complete descriptions for every listed medium- and low-severity issue.
GitLab says it has released two threat detections for self-managed customers to help identify possible attempts to exploit CVE-2026-110264: “Onigmo native worker crash” and “Org mode render error burst.” The notice does not give detection performance, observed incident counts or evidence that a detected event necessarily confirms successful exploitation.
enterprise software vulnerability scanner
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Upgrade and Review the Advisory
Administrators should identify the GitLab version and deployment they operate, then apply the corresponding fixed release if the installation falls within an affected range. GitLab’s stated advice is to upgrade as soon as possible. Self-managed customers can also review the company’s threat detections for the critical vulnerability as part of their investigation and response.
GitLab Dedicated tenants should check whether their systems meet the stated internal-version thresholds: 19.3.5-internal0 or 19.4.2-internal0, or later. GitLab says tenants at those levels already have the fixes. GitLab.com users do not need to apply a server patch, according to the release notice.
Further vulnerability details are expected to appear on GitLab’s issue tracker under its stated 90-day disclosure policy. Until then, operators should use the published release notes and affected-version information to guide patching, while treating the presence or absence of the named detection signals as supporting information rather than a complete measure of exposure.
As an affiliate, we earn on qualifying purchases.
Key Questions
Which GitLab versions contain the fixes?
GitLab lists 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13 for Community Edition and Enterprise Edition. Administrators should match their installed branch to the corresponding fixed release.
What is the critical vulnerability?
CVE-2026-110264 is an integer overflow in the regular-expression compiler. GitLab says a specially crafted expression could, under certain conditions, allow an unauthenticated user to execute arbitrary code on a GitLab server. It gives the issue a CVSS 3.1 score of 10.0.
Do GitLab.com users need to install a patch?
No server-side action is indicated for GitLab.com users: GitLab says its hosted service is already running a patched version. Operators of self-managed instances are urged to upgrade if their versions are affected.
Do GitLab Dedicated tenants need to take action?
GitLab says Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0, or later, already include the fixes and do not need to act. Tenants should verify their version against that guidance.
Has GitLab confirmed active exploitation?
The supplied release notice does not confirm exploitation in the wild. It describes the vulnerability and names two threat detections for self-managed customers, but gives no incident count or confirmation of successful attacks.
Source: hn
Halloween Picks
halloween
As an affiliate, we earn on qualifying purchases.
