GitLab CVE-2026-97229: Rapid7 reproduces RCE, 19.3 fix is 19.3.5

📌 Later developments: GitLab CVE-2026-110264: LDAP injection and request smuggling too (October 22, 2026) · GitLab 19.5.1: new unauthenticated RCE, CVE-2026-110264 (October 22, 2026)

On 12 October ARX News covered CVE-2026-97229 (CVSS 10.0) in GitLab Community Edition (CE) and Enterprise Edition (EE), the integer overflow in the CI/CD regular expression compiler, based on the CERT-EU and CERT-FR advisories. In the hours that followed came GitLab’s bulletin as reported by the press, advisories from INCIBE-CERT, CERT.LV and Belgium’s CCB and, above all, a first analysis by Rapid7. The following changes the priorities.

On the 19.3 branch the fixed version is 19.3.5

The most practical point concerns the 19.3 branch. GitLab’s bulletin, titled “GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8” according to INCIBE-CERT, gives 19.3.5 as the fixed version. The same number appears in Help Net Security, CSO Online, Security Affairs and the CERT.LV advisory. CERT-EU, CERT-FR and BleepingComputer reported 19.3.4 instead, and that is the number in our first article.

The sources do not explain the difference. To be safe, on the 19.3 branch only treat 19.3.5 or later as fixed, even if you have already installed 19.3.4.

Affected versions according to GitLab, as reported by the press and INCIBE-CERT:

• from 19.2 before 19.2.8;
• from 19.3 before 19.3.5;
• from 19.4 before 19.4.2.

GitLab.com already runs the fixed version and GitLab Dedicated customers do not need to take action. According to CSO Online, GitLab specifies that when no deployment type (omnibus, source, Helm chart) is mentioned, all types are affected.

What Rapid7 verified

According to Help Net Security’s update of 13 October, the only source reporting it, Rapid7 researchers reproduced code execution on the unpatched official GitLab CE 19.4.1 image; the same input did not work against the 19.4.2 image.

Rapid7 also clarifies the conditions for exploitation. The vendor’s CVSS vector indicates a network attack, low complexity, no privileges and no user interaction. According to Rapid7, however, the attacker must first be able to commit a malicious .gitlab-ci.yml file, and a repository path containing UTF-8 characters, to a branch in a public project. On self-managed instances that allow users to create public projects, an ordinary account is enough.

Exposure therefore depends on who can get an account on the instance and create public projects. In MITRE ATT&CK terms this is still exploitation of a public-facing application (T1190), but with a valid account.

According to Rapid7, there is currently no confirmed in-the-wild exploitation; INCIBE-CERT also lists the vulnerability as not exploited. Rapid7 nevertheless recommends upgrading urgently, outside normal patch cycles. Belgium’s CCB and CERT.LV ask for immediate updates.

The vulnerability was reported through GitLab’s HackerOne bug bounty programme by the researcher “joaxcar” (Johan Carlsson, according to CSO Online). According to Help Net Security, the same researcher also reported CVE-2026-7767, a medium-severity open redirect in GitLab’s Kubernetes proxy that could send authentication tokens to an unintended server.

The other fixes in the release

According to INCIBE-CERT, the 24 fixed vulnerabilities break down as 1 critical, 5 high, 14 medium and 4 low. Compared with our first article, CSO Online links all five high-severity flaws to an identifier:

• CVE-2026-92883 (CVSS 8.7): cross-site scripting in syntax-highlighted output, due to insufficient sanitisation of HTML attributes;
• CVE-2026-16301 (CVSS 8.5): a user with the Developer role can run pipelines on protected branches without authorisation;
• CVE-2026-14814 (CVSS 8.2): the cache poisoning flaw already mentioned; it affects responses for raw repository files and can make targeted pipelines run malicious content, with access to protected environment variables;
• CVE-2026-81839 (CVSS 7.7): an authenticated user can run arbitrary pipelines in a transferred project with the new group’s privileges;
• CVE-2026-96893 (CVSS 7.3): in GitLab Duo, an authenticated user can inject crafted content into AI agent instructions, potentially causing unintended command execution attributed to other users.

The medium and low-severity flaws affect GitLab Pages, the Kubernetes proxy, GraphQL APIs, merge requests, custom roles, the package registry and repository and project imports. According to CSO Online, GitLab will publish the issue details 90 days after the release: do not wait for them before updating.

Impact for European and Italian companies

The conditions described by Rapid7 make GitLab instances shared with many users more exposed, including suppliers, consultants and external collaborators, especially if they allow public projects to be created. These are often the same instances that hold release pipelines and secrets.

Advisories from national CSIRTs in Belgium, Spain and Latvia, alongside those from CERT-EU and CERT-FR, confirm the attention across Europe. For NIS2 entities, what we wrote in the first article still applies: vulnerability management, software supply chain security and, in the event of a significant incident, notification to the national CSIRT, which in Italy is CSIRT Italia at ACN.

What to do right now

1. 19.3 branch: upgrade to 19.3.5 or later, even if you are already on 19.3.4. On the other branches: 19.4.2 or 19.2.8 or later. For the 19.1 branch our earlier advice stands: no fix has been indicated, so move to at least 19.2.8.
2. Priorities: start with instances reachable from the internet and those with open registration or where users can create public projects.
3. Check the settings: review who can sign up and who can create public projects, the precondition identified by Rapid7. This is not a mitigation provided by GitLab: the only fix is the upgrade.
4. Check the repositories: look for recent changes to .gitlab-ci.yml in public projects, especially from new or rarely used accounts, and for repository paths with non-ASCII characters. No source has published indicators of compromise.
5. If you find suspicious activity: treat the server as exposed, rotate the secrets used by the pipelines and assess your notification obligations.

How ARXDOME helps

ARX Expose identifies the services your company exposes on the internet and the products with known vulnerabilities: it helps you find out whether a GitLab instance is reachable from outside. ARX Shield lists the open vulnerabilities on monitored machines. ARX Sentry collects logs and events from the servers where the agent is installed and checks file integrity in the chosen folders. With ARX Horizon you can look up vulnerability details from the portal.

Last updated: 13 October 2026