Unpatched holes could allow takeover of GitLab accounts – Source: www.csoonline.com

A new vulnerability in GitLab’s Ultimate Enterprise Edition used for managing source code is “dangerous” and needs to be quickly patched, says an expert.

The vulnerability, CVE-2025-5121, is one of 10 described Wednesday by GitLab as it released bug and security fixes for self-managed installations.

“We strongly recommend that all self-managed GitLab installations be upgraded to one of these [patched] versions [18.0.2, 17.11.4, 17.10.8] immediately,” the platform said. GitLab.com is already running the patched version, so GitLab Dedicated customers do not need to take action.

Four of the vulnerabilities are rated as High severity.

Johannes Ullrich, dean of research at the SANS Institute, was particularly worried about CVE-2025-5121, a missing authorization issue. He described it as “dangerous.” If not patched, under certain conditions it can allow a successful attacker with authenticated access to a GitLab instance with a GitLab Ultimate license applied (paid customer or trial) to inject a malicious CI/CD job into all future CI/CD pipelines of any project.

“By injecting a malicious job, an attacker would be able to compromise how software is built,” Ullrich told CSO. “This could likely include adding backdoors to the software or skipping certain validation steps. The code will likely also have access to secrets used during the build process.”

Impacted versions are GitLab Ultimate EE 17.11 prior to 17.11.4, and 18.0 before 18.0.2. This vulnerability has been given a CVSS score of 8.5.

The other vulnerability Ullrich drew attention to is CVE-2025-4278, an HTML injection hole. He described it as essentially a cross site scripting vulnerability, but with more limited impact. GitLab gives it a CVSS score of 8.7.

“The impact of these vulnerabilities is often difficult to assess,” Ullrich said, “but creative attackers are often able to leverage them to trick users into performing dangerous actions on behalf of the attacker.”

GitLab says that, unless patched, under certain conditions the flaw would allow a successful attacker to take over an account by injecting code into the search page. 

All version 18.0 instances prior to 18.0.2 of Community and Enterprise editions are impacted.

The other two vulnerabilities rated as High are:

• CVE-2025-2254, a cross-site scripting issue, which, under certain conditions, could allow an attacker to act like a legitimate user by injecting a malicious script into the snippet viewer.
  All GitLab CE/EE versions from 17.9 before 17.10.8, 17.11 before 17.11.4, and 18.0 before 18.0.2 are impacted;
• CVE-2025-0673, a vulnerability that can cause a denial of service by triggering an infinite redirect loop, which would cause memory exhaustion on the GitLab server. Impacted versions of GitLab CE/EE are 17.7 before 17.10.8, 17.11 before 17.11.4, and 18.0 before 18.0.2.

Three other denial of service vulnerabilities are listed, although they carry lower risk ratings.

CVE-2025-1516, if unpatched, allows a successful attacker to deny access to legitimate users of the targeted system by generating tokens with sufficiently large names, CVE-2025-1478 allows an attacker to deny access to legitimate users of the targeted system by crafting Board Names with sufficiently large sizes, and CVE-2025-5996 allows a denial of service by integrating a malicious third-party component into a GitLab project.

Another patched vulnerability, CVE-2024-9515, could have allowed a successful attacker to clone a legitimate user’s private repository by sending a timed clone request when a secondary node is out of sync. This hole has a CVSS score of 5.3.

Robert Beggs, CEO of Canadian incident response firm Digital Defence, said that CSOs have to remember that GitLab isn’t a passive folder where a user deposits and later retrieves data or source code. It’s a complex application that supports the entire DevOps lifecycle, from planning through to deployment and monitoring. To support this role, GitLab provides a large number of complex functions. This feature set increases the attack surface. In combination with the complexity of the application, any misconfigurations or vulnerabilities could have a significant impact for users.

“As with all applications, CSOs have to pay attention to vendor reports of vulnerabilities and any patches or upgrades to the application,” he said in an email. “They also have to be mindful of their own security hygiene and follow best practices for GitLab use.”

These include limiting access and access privileges to GitHub repositories — for example, ensuring that default visibility is set to Private — enabling multi-factor authentication for access and ensuring that passwords follow typical complexity rules, implementing role-based access controls and frequently reviewing access lists, implementing SSL and TLS certificates to secure communications, securing GitLab runners and pipeline variables, protecting the codebase by implementing branch protection rules and code signing, and more.