A critical two-factor authentication bypass vulnerability in the Community and Enterprise editions of the GitLab application development platform has to be patched immediately, say experts.

The hole is one of five vulnerabilities patched Wednesday as part of new versions of GitLab. Three are ranked High in severity, including the 2FA bypass issue, while the other two are ranked Medium in severity.

GitLab says the 2FA hole, CVE-2026-0723, if exploited on an unpatched system, could allow an individual with knowledge of a victim’s ID credentials to bypass two-factor authentication by submitting forged device responses.

It’s this hole that has drawn the attention of experts, because of the implications.

The goal of multifactor authentication is to protect login accounts with an extra verification step in case usernames and passwords are stolen. If a threat actor can access an account, they can do almost unlimited damage to IT systems.

In the case of GitLab, if critical code is sitting in a developer’s account, a threat actor could compromise it, notes David Shipley, head of Canadian-based security awareness training firm Beauceron Security. If that code is to be used in software that can be downloaded or sold to other organizations, then inserted malware could be spread in a supply chain attack. The latest example, Shipley said, is the Shai-Hulud worm, which is spreading because a developer’s account in the npm registry was hacked.

If the code contains cloud secrets, he added, the threat actor could gain access to cloud platforms like Azure, Amazon Web Service, or Google Cloud Platform.

Discovery of the 2FA bypass hole “is a reminder that these [security] controls are important,” Shipley said in an interview. “They absolutely help reduce a number of risks: Brute force attacks, password spraying, and so forth. But they will never be infallible.

“This is not the first time someone has found a clever way to get around 2FA challenges. We have a whole series of attacks around session cookie capture which are also designed to defeat 2FA. So it’s important to remember this when someone drops some Silver Bullet thinking that ‘This magic solution solves it [authentication]’ or ‘That’s the bad MFA. Here’s the new MFA.’ And I include [trusting only] Yubikeys,” he said. “Yubikeys are amazing. They’re the next generation of 2FA. But because they are made for humans, eventually they will have some flaws.”

Even if there weren’t flaws in these controls, employees might be tricked into giving up credentials through social engineering, he added.

It would be easier for an attacker to use techniques like phishing to collect user credentials rather than forge a device credential to exploit this particular 2FA bypass, said Johannes Ullrich, dean of research at the SANS Institute. But, he added, once the attacker has access to valid passwords, they can log in to the GitLab server and perform actions on the source code — download it, alter it or delete it — just as a legitimate user would.

What infosec leaders need to do

This is why Cybersecurity 101 — layered defense — is vital for identity and access management, Shipley said. That includes forcing employees to have long, unique login passwords, monitoring the network for unusual activity (for example, if someone gets in without an MFA challenge recorded) and, in case all fails, an incident response plan.

MFA bypass vulnerabilities are very common, noted Ullrich. “The core problem is usually that MFA was added later to an existing product,” he said, “and some features may not properly check if MFA was successfully completed.”

When testing a multifactor authentication solution, infosec leaders should always verify that an application has not marked authentication as completed after the username and password were verified. Enabling MFA should not relax password requirements, he asserted. Users must still pick unique, secure passwords and use password managers to manage them. Secure passwords will mostly mitigate any MFA failures, Ullrich said.

Any vulnerability found in GitLab is significant, he added. GitLab is typically used by organizations concerned enough about the confidentiality of their code that they want to run the platform on premises. 

GitLab ‘strongly’ recommends upgrades

In describing the patches released Wednesday, GitLab said it “strongly” recommends all self managed GitLab installations be upgraded to one of the three new versions (18.8.2, 18.7.2, 18.6.4) for GitLab Community Edition (CE) and Enterprise Edition (EE). Those using GitLab.com or GitLab Dedicated –  a single tenant software-as-a-service version –  don’t have to take any action.

The other vulnerabilities fixed in Wednesday’s updates are:

• CVE-2025-13927, a denial of service issue in Jira Connect integration. If exploited on an unpatched system, it could allow an unauthenticated user to create a denial of service condition by sending crafted requests with malformed authentication data. It carries a CVSS severity score of 7.5;
• CVE-2025-13928, an incorrect authorization issue. If exploited on an unpatched system, it could allow an unauthenticated user to cause a denial of service condition by exploiting incorrect authorization validation in API endpoints.  It carries a CVSS severity score of 7.5;
• CVE-2025-13335, an infinite loop issue in Wiki redirects. Under certain circumstances, this hole could allow an authenticated user to create a denial of service condition by configuring malformed Wiki documents that bypass cycle detection. It has a CVSS score of 6.5;
• CVE-2026-1102 – a denial of service issue in an API endpoint that could allow an unauthenticated user to create a denial of service condition by sending repeated malformed SSH authentication requests. It has a CVSS score of 5.3.

In keeping with standard GitLab practice, details of the security vulnerabilities will be made public on an issue tracker 30 days after the release in which they were patched. 

The new versions also include bug fixes, some of which, GitLab said, may include database migrations. In cases of single-node instances, a patch will cause downtime during the upgrade. In the case of multi-node instances, admins who follow proper GitLab zero-downtime upgrade procedures can apply a patch without downtime.

This article originally appeared on CSOonline.