Attackers are now exploiting a critical GitLab vulnerability in real-world attacks, according to the US Cybersecurity and Infrastructure Security Agency (CISA). The issue had already been patched earlier this month, but CISA’s update indicates the flaw has moved from a theoretical risk to an active threat.
For European businesses, the development is especially relevant where GitLab is used to manage source code, CI/CD pipelines, internal development workflows or deployment infrastructure. If affected systems are internet-accessible and not fully updated, they may now face a significantly higher risk of compromise.
What happened
CISA has added the GitLab flaw to its catalog of vulnerabilities known to be exploited in the wild. The source report describes the issue as a maximum-severity vulnerability and says attackers have started using it in attacks after a patch was released earlier in the month.
At a practical level, this means organisations should not treat the issue as a routine software update. Once exploitation is public and observed, unpatched systems can become priority targets for opportunistic scanning as well as more focused attacks.
Why it matters for European businesses
GitLab is widely used beyond large software companies. Many SMEs, e-commerce businesses, agencies and internal IT teams rely on it for code repositories, deployment pipelines, issue tracking and collaboration. A compromise of such a platform can create broader business risk than a normal server breach.
If attackers gain access to a development platform, the impact may include:
- access to proprietary source code and internal documentation
- exposure of credentials, tokens or deployment secrets stored in projects or pipelines
- tampering with software builds or website deployment workflows
- disruption to development operations and release schedules
- potential downstream risk to production websites, apps or customer-facing services
For companies working under customer security requirements, ISO-aligned controls or sector-specific obligations, an exploited weakness in development infrastructure can also trigger contractual, governance and incident-response consequences.
Who may be affected
The highest-risk group is organisations running self-managed GitLab, especially where instances are exposed to the internet and patching has been delayed. Businesses with hybrid environments should also verify whether development, staging and disaster-recovery systems have been updated, not only primary production instances.
Likely affected groups include:
- software teams hosting their own GitLab environment
- digital agencies managing client code and deployments
- e-commerce businesses with in-house development pipelines
- IT departments using GitLab for internal automation or infrastructure-as-code workflows
- companies with third-party providers operating GitLab on their behalf
Organisations using a hosted service model should still confirm their exposure and ask suppliers what remediation steps have been taken, but the immediate operational urgency is typically greater for self-managed deployments.
What companies should consider
- Check whether you run a self-managed GitLab instance and identify all internet-facing environments, including forgotten test or backup systems.
- Apply the vendor patch without delay if it has not already been installed.
- Review administrative access, tokens and stored secrets in case exposure occurred before patching.
- Inspect logs and alerts for unusual authentication activity, configuration changes or suspicious access to repositories and pipelines.
- Verify CI/CD integrity by checking recent pipeline changes, runners, deployment scripts and protected branches.
- Ask managed service providers or hosting partners for confirmation if GitLab is operated by a third party.
- Update incident-response plans for development-platform compromise, especially where code repositories connect to production environments.
The key point for businesses is that this is no longer just a severe published flaw. CISA says exploitation is already happening, which increases the need for immediate patching and verification of development system security.