GitLab has shipped out-of-band security updates to address a critical two-factor authentication (2FA) bypass and several denial-of-service (DoS) vulnerabilities in GitLab Community Edition (CE) and Enterprise Edition (EE). Administrators of self-managed GitLab instances are strongly advised to deploy the patches without delay to reduce account takeover and service disruption risks.
Critical GitLab 2FA bypass vulnerability (CVE-2026-0723)
The most severe issue, tracked as CVE-2026-0723, affects both GitLab CE and EE. The flaw stems from improper handling of return values in GitLab’s authentication services. If an attacker knows or can determine a victim’s account identifier, it becomes possible to spoof the response from a 2FA device and successfully bypass two-factor verification.
In practice, this turns any valid or compromised username–password pair into full account access, even where 2FA is configured as mandatory. For GitLab, which often serves as a central DevSecOps platform for source code hosting, CI/CD pipelines, secrets, and build artifacts, such account compromise can directly enable code tampering, backdoor insertion, and artifact substitution in the software delivery process.
Why a 2FA bypass is critical for DevSecOps and CI/CD environments
2FA is designed as a second security layer that still protects accounts when passwords are leaked, reused, or brute-forced. A reliable 2FA implementation is therefore a key control against phishing and credential stuffing. When this layer can be bypassed, stolen credentials immediately translate into unauthorized access, even in environments with formally strict authentication policies.
Within a software supply chain, the compromise of a single developer or DevOps account can be enough to inject malicious code into repositories, CI/CD jobs, or container images. Such changes may then propagate silently into production systems and customer environments. GitLab’s widespread use in large enterprises makes a 2FA bypass particularly significant from a systemic risk perspective.
Multiple GitLab DoS vulnerabilities enable service disruption
Critical unauthenticated DoS vulnerabilities (CVE-2025-13927, CVE-2025-13928)
Alongside the 2FA issue, GitLab has fixed two critical DoS vulnerabilities that can be exploited by unauthenticated attackers.
The first flaw, CVE-2025-13927, allows a remote attacker to trigger a denial of service by sending specially crafted requests containing malformed authentication data. GitLab servers may consume excessive CPU and memory while processing these requests, resulting in resource exhaustion and temporary unavailability of the service.
The second issue, CVE-2025-13928, is caused by insufficient access control validation for certain API requests. An attacker without any GitLab account can construct a sequence of API calls that leads to DoS conditions. For organizations that rely on GitLab for continuous integration and delivery, such outages can disrupt builds, delay releases, and directly impact development productivity.
Medium-severity DoS vectors via Wiki and SSH (CVE-2025-13335, CVE-2026-1102)
GitLab has also addressed two medium-severity vulnerabilities that can still be used to degrade or interrupt service availability.
The Wiki-related issue, CVE-2025-13335, is linked to the processing of Wiki documents. Specially crafted Wiki content could bypass cyclic dependency checks and trigger expensive rendering or processing operations, leading to a DoS condition. Because Wiki pages can often be edited by users with limited permissions, this creates an internal attack vector within collaborative projects.
The SSH vulnerability, CVE-2026-1102, affects GitLab’s SSH authentication subsystem. By repeatedly sending invalid SSH authentication requests, an attacker can consume server and potentially network resources, again producing denial-of-service effects. This can impact not only Git operations over SSH but also the stability of the underlying infrastructure.
Patched GitLab versions and who needs to update
To remediate all of the above vulnerabilities, GitLab has released security updates for the following branches: 18.8.2, 18.7.2, and 18.6.4 for both Community and Enterprise Editions. Any organization running a self-managed GitLab instance should plan a maintenance window, create full backups, and upgrade to one of these versions as soon as possible.
The GitLab.com SaaS platform has already been updated, so no action is required from users of the hosted service. Customers using GitLab Dedicated are also covered, as patches are deployed automatically by the managed service provider.
Exposure of internet-facing GitLab instances and systemic risk
Data from the Shadowserver Foundation indicates that roughly 6,000 GitLab CE instances are directly reachable from the public internet. Search engine Shodan reports more than 45,000 internet-exposed devices related to GitLab, some of which may be vulnerable if not yet patched.
According to GitLab’s own figures, the DevSecOps platform has over 30 million registered users, and more than half of Fortune 100 companies rely on it, including major players in technology, aerospace, telecoms, and finance. This scale means that security flaws in GitLab can have far-reaching implications for global software supply chain security and operational resilience.
Key security recommendations for GitLab administrators
Apply security updates immediately. Verify your current GitLab version and upgrade to 18.8.2, 18.7.2, or 18.6.4, depending on your deployment branch. Always back up configuration, repositories, and databases prior to patching.
Limit direct internet exposure. Where possible, place GitLab behind VPNs, reverse proxies, or web application firewalls (WAFs), and use IP allowlists for administrative interfaces and SSH access. Reducing the public attack surface significantly lowers the risk of opportunistic exploitation.
Harden authentication and access control. Keep 2FA enabled and, where feasible, integrate GitLab with a corporate identity provider (IdP) for SSO and centralized policy enforcement. Enforce strong password policies and monitor for unusual login patterns, especially from new locations or devices.
Enable logging, monitoring, and alerting. Collect and retain logs from GitLab, SSH, and front-end web servers. Configure alerts for spikes in authentication failures, sudden increases in request volume, and abnormal resource utilization, which can indicate ongoing DoS attempts or brute-force activity.
Integrate vulnerability management into DevSecOps. Subscribe to GitLab’s security advisories and incorporate timely patching into your CI/CD and change management processes. Treat platform-level vulnerabilities, such as CVE-2026-0723, with the same urgency as critical flaws in production application code.
Recent GitLab vulnerabilities around 2FA bypass and denial-of-service once again highlight that DevSecOps platforms themselves are high-value targets. Organizations that update rapidly, minimize exposure, and invest in monitoring and strong authentication substantially reduce the likelihood of repository compromise and development outages. For any team that depends on GitLab as a core component of its software delivery pipeline, now is the time to confirm your version, apply the latest security updates, and review baseline security controls around your GitLab environment.
