More than 1,000 internet-exposed GitLab servers are reportedly still vulnerable to a maximum-severity security flaw that is being actively exploited in remote code execution attacks. For European businesses using self-managed GitLab instances, the development is a direct cybersecurity and operational risk because GitLab often sits close to source code, deployment pipelines, credentials and internal development workflows.

What happened

According to reporting by BleepingComputer, attackers are exploiting a critical GitLab flaw that can lead to remote code execution on exposed servers. Remote code execution means an attacker may be able to run commands on a vulnerable system from a distance, which can make this type of issue especially dangerous when the affected platform is connected to software repositories, CI/CD jobs, secrets or production infrastructure.

The report says that more than 1,000 GitLab servers exposed to the internet remain unpatched. While the exact number can change quickly as organisations update systems or take instances offline, the core issue is that a significant number of self-hosted deployments may still be at risk while exploitation is ongoing.

Why it matters for European businesses

GitLab is not just a developer tool. In many organisations it is part of the delivery chain for websites, applications, e-commerce systems, APIs and internal business software. If a self-managed GitLab instance is compromised, the impact can extend beyond one server.

• Source code exposure: attackers may gain access to proprietary code, internal documentation or configuration files.
• Pipeline compromise: CI/CD workflows can become a route into staging or production environments.
• Credential theft: tokens, keys and stored secrets may be exposed depending on configuration.
• Operational disruption: software delivery, bug fixing and release schedules can be interrupted.
• Supply chain risk: compromised development tooling can affect customer-facing services and downstream systems.

For SMEs, the practical risk is often higher than it appears. Smaller teams may self-host GitLab for cost, control or compliance reasons but may not have round-the-clock monitoring or a mature patching process for development infrastructure. That can leave critical internal systems exposed for longer than expected.

Who may be affected

• Companies running self-managed GitLab instances on public cloud, private infrastructure or colocated servers.
• Software vendors and SaaS providers whose engineering teams use GitLab for repositories and deployment automation.
• E-commerce businesses with in-house development teams managing storefronts, integrations or custom applications.
• Digital agencies and IT service providers hosting GitLab for internal teams or client projects.
• Regulated businesses where a compromise could create wider security, audit or incident-reporting consequences.

Businesses using GitLab-managed services rather than self-hosted deployments may have a different exposure profile, but organisations should verify which GitLab model they use and whether any self-managed components are connected to public networks.

What companies should consider

• Confirm exposure: identify whether your organisation runs any self-managed GitLab instances and whether they are reachable from the public internet.
• Apply vendor patches: review GitLab security advisories and update affected systems as a priority.
• Limit access: if immediate patching is not possible, reduce external exposure through VPN, IP allowlisting, reverse proxy restrictions or temporary isolation where feasible.
• Review secrets and tokens: assess whether access tokens, SSH keys, CI/CD variables or other credentials stored in or used by GitLab should be rotated.
• Inspect logs and activity: look for unusual admin actions, new users, unexpected pipeline behaviour or suspicious outbound connections.
• Check downstream systems: review deployment servers, cloud accounts and connected environments that GitLab pipelines can access.
• Strengthen DevSecOps hygiene: ensure development platforms are covered by the same vulnerability management, asset inventory and incident response processes as production systems.

Because the flaw is reportedly being actively exploited, organisations should treat this as an urgent patching and exposure-management issue rather than routine maintenance. Businesses without in-house security or platform teams may want to involve their hosting provider, managed service partner or incident response specialists to verify whether any vulnerable GitLab systems are exposed.