GitLab CVE-2026-97229: CVSS 10 RCE Now Exploited, Patch Now

The key challenge is that this flaw combines the two traits attackers value most: no authentication and full code execution, and it has already been tried against a real target. According to reporting by The Hacker News, the CISA listing is tied to an incident disclosed by Alpine Linux. An unknown threat actor attempted to exploit the flaw against Alpine's GitLab instance on October 20 and 21, 2026, sending crafted CI configurations that made GitLab worker processes crash eight times. In four of those crashes the exploit failed at the following step. The attacker also downloaded Alpine's GitLab container image.

Later attempts on October 25 and 26 were blocked. Alpine's maintainers said the attack came close to working, that they found no evidence it succeeded but could not rule it out, and that they therefore treated the instance as compromised and rebuilt it from scratch. They also reported that their package repository and the October 21 releases were not tampered with. No threat actor has been named.

Three lessons stand out for enterprise teams:

• The patch window was real. The fix was published on October 12, and the attempts began eight days later. Exploitation followed patch availability closely, which is the normal pattern for critical flaws.
• Crashes are evidence. Repeated worker crashes were how Alpine noticed the activity. Many organizations do not alert on application-level crashes in developer tooling.
• Rebuilding is sometimes the right answer. When you cannot prove a server was not compromised, a clean rebuild with rotated secrets is safer than hoping.

GitLab also notes that the full technical details will be made public 90 days after the release, which means not before January 10, 2027. Until then, public exploit code is less likely, but the Alpine incident shows that capable attackers did not wait.

The response to CVE-2026-97229 is to identify every self-managed GitLab instance, upgrade to a fixed version, hunt for signs of exploitation, and rotate the secrets the server could reach. Work through these steps in order.

1. Inventory every instance. Include the obvious production server and the forgotten ones: test servers, instances run by individual business units, and servers inherited through acquisitions. You cannot patch what you do not know exists.
2. Check the version. GitLab lists the affected releases as all versions from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2, for both CE and EE. The fixed versions are 19.2.8, 19.3.5 and 19.4.2. GitLab's advisory lists no workaround, so upgrading is the remedy.
3. Upgrade now, then confirm. Schedule an emergency window, upgrade, and verify the running version afterwards. Test your pipelines, because GitLab patch releases of this size include many other fixes. The same release addresses roughly two dozen vulnerabilities, including CVE-2026-92883 (cross-site scripting, CVSS 8.7), CVE-2026-16301 (improper authorization in downstream pipelines, CVSS 8.5) and CVE-2026-14814 (CVSS 8.2).
4. Hunt for exploitation. GitLab published six threat detections for self-managed instances, covering signals such as Onigmo worker crashes, hostile regular expressions sent to the GraphQL CI lint path, oversized non-ASCII paths, regex guard rejections, CI lint worker crashes and bursts of CI lint client errors. Search your logs back to at least October 12. Pay attention to unexpected container image downloads.
5. Treat suspicious findings as a compromise. If you find indicators, follow Alpine's example: isolate the server, rebuild it from a clean image, and restore data from a known-good backup.
6. Rotate secrets. CI/CD variables, deploy keys, runner registration tokens and cloud credentials stored in GitLab should be rotated if there is any doubt.
7. Reduce exposure. A code platform rarely needs to be open to the whole internet. Put it behind a private, segmented path such as a multi-operator managed network with VPN or zero trust access, and restrict who can reach CI lint and API endpoints.

Forward the logs to a central SIEM, so that a crash pattern on a development server becomes an alert rather than a footnote.

Treating developer platforms with the same rigor as production systems protects the software you ship and the customers who depend on it. Responding well to this flaw delivers practical benefits.

• Lower supply chain risk. A clean, patched, monitored GitLab server reduces the chance that an attacker inserts code into your builds or steals the secrets used to deploy them.
• Faster, cheaper incident response. Centralized logs and a tested rebuild procedure turn a possible compromise into a controlled exercise. Alpine's rebuild from scratch is a useful model, because it removes doubt.
• Better audit and contractual posture. Customers, insurers and auditors increasingly ask how quickly actively exploited vulnerabilities are corrected. A KEV-driven patch process with documented dates answers that question.
• Visibility into shadow infrastructure. The inventory step often finds unmanaged servers. Finding them during a calm week costs far less than finding them after a breach.
• A repeatable playbook. The same steps apply to the next critical flaw in a CI/CD tool, a hypervisor or an edge appliance, so the effort pays back every time.

CISA's November 1 deadline applies to U.S. federal civilian agencies, but it is a sensible benchmark for any enterprise. If your self-managed GitLab is still on an affected version today, you are already behind the public timeline.

HIT Communications helps enterprises keep critical platforms patched, monitored and recoverable, so a vendor advisory does not turn into a long incident. With more than 30 years of experience across Latin America, the United States and Europe, we bring networks, security and IT operations together in one team.

Our cybersecurity services include a 24/7 SOC, SIEM and managed detection and response that ingest logs from developer platforms, firewalls and identity systems, and alert on crashes and anomalies as well as known attack signatures. Our IT managed services cover patch planning, operation of on-premises and cloud infrastructure, and backup, so emergency upgrades are scheduled, tested and documented instead of improvised.

If you run self-managed GitLab and are unsure which version you have, who can reach it, or which secrets it holds, we can help you inventory the instances, plan the upgrade with minimal downtime, and put monitoring in place for the signals GitLab has published.

CVE-2026-97229 is a reminder that the systems that build your software deserve the same protection as the systems that run it. A CVSS 10.0 flaw needing no login has a fix since October 12, an attack attempt on a well-known project, and a CISA warning that the federal deadline has already passed.

Start with three actions today: list every self-managed GitLab instance and its version, upgrade to 19.4.2, 19.3.5 or 19.2.8 or later, and search your logs for the crash and CI lint signals GitLab published. If you want help with the inventory, the maintenance window or ongoing monitoring, contact the HIT Communications team.