Skip to content
Menu

GitLab Vulnerability: CERT-EU Warns of Critical Unauthenticated RCE

CERT-EU is telling organizations to patch self-managed GitLab CE and EE instances against a critical unauthenticated remote code execution flaw that is now being exploited in the wild.

  • Critical
  • Actively Exploited
  • Breaking

Reported Oct 30, 2026 · Updated Nov 2, 2026 · 8 sources

What Happened

The GitLab vulnerability tracked as CVE-2026-97229 is a critical, unauthenticated remote code execution flaw in self-managed GitLab Community Edition (CE) and Enterprise Edition (EE). GitLab released versions 19.4.2, 19.3.4 and 19.2.8 on 12 October 2026, fixing 24 security issues including this one. CERT-EU recommends upgrading self-managed GitLab CE/EE instances as soon as possible, starting with internet-facing instances.

The flaw is not sitting on a slide. CISA added CVE-2026-97229 to its Known Exploited Vulnerabilities catalog on 30 October 2026, citing active exploitation. Alpine Linux said on 28 October that an attacker tried to exploit the flaw on its own GitLab server about a week after the fix was released. Alpine found no evidence the attack worked, but the attempt is a sign that this vulnerability is on attacker radar.

As of 2 November 2026, more than 1,000 internet-exposed GitLab servers were still unpatched, according to BleepingComputer. That is a snapshot, not a complete census, but it shows how many instances are reachable and unpatched.

Timeline

  1. 12 October 2026: GitLab released versions 19.4.2, 19.3.4 and 19.2.8 of GitLab CE and EE, fixing 24 security issues including a critical vulnerability.
  2. 28 October 2026: Alpine Linux said an attacker tried to exploit the flaw on its GitLab server about a week after the fix was released. Alpine found no evidence the attack worked.
  3. 30 October 2026: CISA added CVE-2026-97229 to its Known Exploited Vulnerabilities catalog, citing evidence of active exploitation.
  4. 2 November 2026: More than 1,000 internet-exposed GitLab servers remained unpatched, according to BleepingComputer.

Who Is Affected

Any MSP running self-managed GitLab CE or EE is in scope. The advisory covers both Community Edition and Enterprise Edition. If you host GitLab for your own team, for internal tools, or for client projects, you have a patch to plan.

Internet-facing instances are the priority. CERT-EU says to prioritize internet-facing assets, and the public scan showing over 1,000 unpatched servers confirms that a large number of GitLab instances are reachable from the internet.

Your clients are affected if they run their own GitLab server, or if you run one on their behalf. This is a source code and CI/CD platform, so a successful exploit can mean access to code, secrets, and build pipelines.

Why This Matters for MSPs

A GitLab server is not just another application. It holds source code, CI/CD pipelines, environment variables and often production secrets. A remote code execution bug on that server can give an attacker the same access as a developer with admin rights.

For an MSP, this is a support burden and a liability question. You may manage GitLab for several clients, and each one needs the same patch, the same verification and the same log review. The work is repetitive, but skipping one instance can leave a client exposed.

The good news is that fixed versions exist and the patch is straightforward. The hard part is knowing where every instance lives and making sure none of them are forgotten.

Technical Details

Tracked as CVE-2026-97229, the vulnerability carries a CVSS score of 10.0. It is an integer overflow or wraparound vulnerability in GitLab Community Edition and Enterprise Edition. The flaw allows an unauthenticated attacker to execute arbitrary code on the server. The attack vector is a crafted regular expression in a CI configuration. GitLab fixed it in versions 19.4.2, 19.3.4 and 19.2.8. CERT-EU describes the issue as critical and recommends upgrading self-managed GitLab CE/EE instances as soon as possible, starting with internet-facing ones.

What to Do This Week: GitLab Vulnerability Response

Treat this as a patch this week, not a ticket for later. The vulnerability is critical, it is unauthenticated, and it is being actively exploited. Here is the order of operations.

  1. Inventory every self-managed GitLab CE/EE instance you operate or monitor. Include test instances, internal tools and client environments.
  2. Upgrade to a fixed version: 19.4.2, 19.3.4 or 19.2.8. Start with internet-facing instances, as CERT-EU recommends.
  3. Run an assessment to identify compromised assets. CERT-EU recommends this, and it is the right step after a vulnerability with active exploitation.
  4. If you cannot patch immediately, restrict access to your GitLab instance. Put it behind a VPN or firewall rule until the upgrade is done.
  5. Review CI/CD configuration and authentication logs for unexpected changes. This is standing practice for a platform that holds source code and pipeline secrets.
  6. Confirm the upgraded version is running and the service is healthy before moving to the next instance.

What to Tell Clients

Here is language you can adapt for an email or a client update.

GitLab has released fixes for a critical vulnerability that is being actively exploited. The flaw could let an attacker run code on a GitLab server without logging in. We are checking any self-managed GitLab instances in your environment and will patch them to a fixed version.

Because this vulnerability affects source code and build pipelines, we are treating it as high priority. We will start with any instance exposed to the internet, then verify the rest.

After patching, we will review access logs for signs of unauthorized activity. If we find anything, we will let you know and walk through the next steps.

Frequently Asked Questions

What Is CVE-2026-97229?

It is a critical vulnerability in GitLab Community Edition and Enterprise Edition with a CVSS score of 10.0. It is an integer overflow or wraparound bug that lets an unauthenticated attacker execute arbitrary code on the server through a crafted regular expression in a CI configuration.

Is the GitLab Vulnerability Being Actively Exploited?

Yes. CISA added CVE-2026-97229 to its Known Exploited Vulnerabilities catalog on 30 October 2026, citing active exploitation. Alpine Linux also said an attacker tried to exploit the flaw on its own GitLab server, though it found no evidence the attack worked.

Which Versions Fix CVE-2026-97229?

GitLab fixed it in versions 19.4.2, 19.3.4 and 19.2.8 of Community Edition and Enterprise Edition. Upgrade to one of these versions as soon as possible, starting with internet-facing instances.

How Do I Know If My GitLab Server Is Vulnerable?

Check the version on your self-managed GitLab CE or EE instance. If it is not one of the fixed versions, treat it as needing review and patch it.

Should I Prioritize Internet-Facing GitLab Instances?

Yes. CERT-EU recommends prioritizing internet-facing assets because they are reachable by anyone. More than 1,000 internet-exposed servers were still unpatched as of 2 November 2026, according to BleepingComputer.

What Should I Do If I Cannot Patch Right Away?

Restrict access to your GitLab instance as much as possible, ideally to trusted networks or VPN users. Then patch as soon as you can and run an assessment to check for signs of compromise.

Sources

Welcome Back

Sign in to your MSP Outpost account.