GitLab Warns of High-Severity 2FA Bypass, Denial-of-Service Flaws

Why It Matters

The vulnerabilities expose millions of developers to credential theft and service outages, threatening the reliability of critical software pipelines. Prompt remediation is essential to protect Fortune‑100 customers and the broader DevSecOps ecosystem.

Key Takeaways

• CVE‑2026‑0723 enables 2FA bypass via account ID
• CVE‑2025‑13927/13928 cause unauthenticated DoS attacks
• Patches released in versions 18.8.2, 18.7.2, 18.6.4
• Over 45k GitLab instances exposed online per Shodan
• Upgrade recommended for all self‑managed installations immediately

Pulse Analysis

GitLab disclosed a high‑severity authentication flaw (CVE‑2026‑0723) that allows attackers who know a victim’s account identifier to bypass two‑factor authentication. The vulnerability originates from an unchecked return‑value in the authentication service, effectively rendering the second factor moot. Because 2FA is a cornerstone of modern DevSecOps security, the bypass could enable account takeover across both Community and Enterprise editions, exposing millions of users and critical code repositories. Exploiting the flaw requires only the numeric user ID, which is often discoverable through public APIs or repository metadata, making the attack vector low‑effort.

In the same release GitLab fixed two additional high‑severity flaws (CVE‑2025‑13927 and CVE‑2025‑13928) that permit unauthenticated denial‑of‑service attacks via malformed authentication payloads and improper API authorization checks. Shadowserver reports roughly 6,000 exposed self‑managed instances, while Shodan identified more than 45,000 devices bearing a GitLab fingerprint, underscoring the attack surface. The combined impact of credential bypass and service disruption could cripple development pipelines for enterprises that rely on GitLab’s integrated CI/CD environment. Enterprises that host private runners or expose internal APIs are particularly at risk, as a DoS event can halt automated testing and delay releases.

GitLab responded by issuing versions 18.8.2, 18.7.2 and 18.6.4 for both CE and EE, and it urged all self‑managed customers to upgrade immediately. While GitLab.com and Dedicated customers are already protected, the sheer scale of installations means many organizations remain vulnerable until they apply the patches. This episode reinforces the need for continuous vulnerability management, automated patch deployment, and regular security audits in DevSecOps workflows, especially for firms handling high‑value code and compliance‑sensitive projects. Adopting a staged rollout strategy with canary instances can further reduce exposure while validating compatibility across custom plugins and integrations.