Summary
- Shadowserver identified more than 1,000 exposed GitLab instances.
- The CVE-2026-97229 code execution flaw has a maximum CVSS score.
- Exposure persists despite patches and confirmed exploitation.
More than 1,000 internet-facing GitLab servers remain exposed to a critical code execution vulnerability despite emergency security fixes and evidence that attackers are exploiting the weakness.
New measurements by the Shadowserver Foundation identified installations affected by CVE-2026-97229. The finding provides a fresh assessment of vulnerable deployment levels, rather than another report on the October patch release.
GitLab issued security updates on 12 October for affected Community Edition and Enterprise Edition servers. The vulnerability concerns regular expression processing used in continuous integration configuration and can permit unauthenticated code execution under specified conditions.
The weakness has a maximum CVSS severity rating of 10.0. The US Cybersecurity and Infrastructure Security Agency subsequently added it to its Known Exploited Vulnerabilities catalogue after exploitation was confirmed.
The Shadowserver figure describes systems identified as vulnerable through internet measurements. It is not a count of confirmed compromises, nor does it include every possible internal installation that cannot be reached by public scanning.
The distinction between a vulnerable system and an infected one affects incident response. Administrators must determine whether the relevant software is installed, whether an attacker can reach it, and whether logs or other evidence indicate exploitation.
GitLab can be central to enterprise software production. Its servers may store source code, manage development permissions, run automated pipelines, and distribute packages or deployment instructions to other parts of an organisation.
A successful compromise could therefore expose more than the availability of the collaboration platform. Depending on configuration, it may give an attacker opportunities to access code, interfere with build processes, or use credentials associated with automation.
The actual damage would depend on the permissions and connections available to the affected server. An isolated test environment presents different consequences from a GitLab instance whose runners can deploy software to production systems.
The exposure measurements underline a persistent problem with self-managed platforms. The vendor can issue a fix promptly, but the customer remains responsible for identifying affected servers, validating the update, and putting it into service.
Organisations sometimes maintain multiple code-hosting systems acquired through mergers, development projects, or departmental purchases. Servers outside central inventories can remain accessible after the team that originally deployed them has changed.
Public network access may be necessary for distributed developers, contractors, or open-source projects. That convenience can also allow attackers to probe vulnerable services without first gaining access to a private enterprise network.
The recent Alpine Linux incident illustrates the recovery problem. The project rebuilt its GitLab environment and reset credentials after attempted exploitation because it could not completely rule out access. It reported no evidence that official packages or releases had been tampered with.
That event has been covered separately by Cyber Insider. The latest Shadowserver study instead establishes the continuing exposed population after disclosure, patch availability, and government warnings increased pressure to update.
Security teams must also consider credentials and infrastructure linked to affected GitLab instances. A compromised development server may have access to deployment tokens, repositories, or automated jobs even where the host machine itself can be replaced.
Remediation may therefore involve updating the software, assessing logs, replacing exposed secrets, and examining the integrity of connected build and release processes when compromise is suspected.
Not every vulnerable server will have been exploited, and the scanning results do not establish that a particular organisation lost source code or development credentials. They indicate where a known and exploited weakness remains accessible.
The combination of confirmed exploitation and a substantial remaining exposure count makes the patching interval particularly consequential for self-managed software delivery environments.
The latest measurements show that hundreds of organisations may still have work to do after the initial advisory, although the precise ownership and compromise status of the exposed installations remain unknown.
