GitLab CVSS 10 Flaw Exploited: What Indian Teams Must Do

In short: A critical GitLab vulnerability, CVE-2026-97229, rated CVSS 10.0, is now being exploited in real attacks. CISA added it to its Known Exploited Vulnerabilities catalogue on 29 October 2026. Companies and departments running self-managed GitLab should upgrade to a fixed release now, check for signs of misuse and tighten who can create projects.

What Happened

On 12 October 2026, GitLab released patch versions 19.4.2, 19.3.5 and 19.2.8 for GitLab Community Edition (CE) and Enterprise Edition (EE). According to the GitLab patch release notes, the most serious fix was CVE-2026-97229, an integer overflow in the CI/CD regular expression compiler. GitLab says that under certain conditions an unauthenticated user could run arbitrary code on the GitLab server using a specially crafted regular expression in a CI/CD configuration.

On 29 October 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities catalogue, based on evidence of active exploitation, as reported by Rapid7 and other security outlets. BleepingComputer has reported that more than 1,000 internet-facing GitLab servers were still unpatched after exploitation began.

Who Is Affected

Per GitLab's advisory, the affected versions are:

GitLab branch	Affected	First fixed version
19.2	Before 19.2.8	19.2.8
19.3	Before 19.3.5	19.3.5
19.4	Before 19.4.2	19.4.2

This applies to self-managed installations of both CE and EE. GitLab states that GitLab.com and GitLab Dedicated are already patched, so customers on those services do not need to act on this issue.

Rapid7's analysis adds two useful details. First, the attacker needs to be able to commit a malicious .gitlab-ci.yml file to a branch in a public project. On servers that allow anyone to sign up and create projects, that barrier is very low. Second, the root cause lies in the regular expression engine built into Ruby (Onigmo), which GitLab uses. A report by PBX Science notes that GitLab's fix patches the Ruby bundled with its official Linux packages and container images, so installations that use their own separately installed Ruby may also need a Ruby update.

What It Means for Indian Organisations

Many Indian software companies, IT service providers, banks, startups and government IT cells run GitLab on their own servers to keep source code in-house. A GitLab server often holds more than code: CI/CD variables, deployment keys, cloud credentials and access to production systems. If an attacker runs code on that server, they may be able to reach all of these.

Organisations covered by CERT-In's April 2022 directions must also report specified cyber incidents to CERT-In within six hours of noticing them. If you find signs that this flaw was used against your server, treat it as a possible incident and follow your reporting process. Our CERT-In 6-hour incident reporting checklist explains the steps.

What to Do Now

1. Find every GitLab server: list all self-managed GitLab instances, including test, staging and old servers that teams may have forgotten.
2. Upgrade to a fixed release: move each server to at least 19.4.2, 19.3.5 or 19.2.8 on its branch, and check GitLab's releases page for any newer patch release, which should be preferred.
3. Check custom builds: if GitLab was compiled from source or runs in an image that installs its own Ruby, confirm with your team that Ruby has also been updated to a fixed version.
4. Limit sign-ups and public projects: turn off open self-registration, require admin approval for new users, and restrict who can create or push to public projects until patching is confirmed.
5. Look for signs of misuse: review the threat detections GitLab published with the patch, check recent changes to .gitlab-ci.yml files, unknown users or projects, and unexpected processes running as the git user.
6. Rotate secrets if in doubt: if there is any sign of compromise, rotate CI/CD variables, deploy keys, runner tokens and cloud credentials stored on or reachable from the server.
7. Report if required: if you confirm or strongly suspect a compromise, follow your CERT-In reporting process and inform affected clients as your contracts require.

Longer term, a written patch management process with fast timelines for internet-facing systems helps you act on alerts like this within hours, not weeks.

Frequently Asked Questions

We use GitLab.com. Do we need to do anything?

GitLab says GitLab.com and GitLab Dedicated are already patched for this issue. Self-hosted GitLab Runners are separate software, so keep them updated as part of normal patching.

Our GitLab server is only on the internal network. Is it safe?

The risk is lower but not zero. Anyone with an account who can push CI/CD configuration to a public project may be able to exploit it, including a compromised employee account. Upgrade internal servers too.

Is upgrading GitLab enough?

For official Linux packages and container images, the GitLab upgrade includes the fix. If your installation uses its own Ruby, confirm that Ruby has also been updated. If you see signs of misuse, upgrading does not remove an attacker who is already in, so investigate as well.

How Affix Center Can Help

Affix Center Softech Services, based in Mumbai, helps organisations patch and secure critical servers. Our cybersecurity team can check your GitLab and other internet-facing systems for known exploited flaws and signs of compromise, and our IT operations team can set up regular patching with clear timelines.

If you run self-managed GitLab and are unsure whether you are exposed, contact our team for a quick review.