CVE-2026-7514 in GitLab
Summary
by MITRE • 09/16/2026
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 13.9 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that an authenticated user with developer-role permissions could substitute package file content and hide packages from their owners due to improper authorization checks in the Generic Package Registry.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified as CVE-2024-7568 represents a critical security flaw within GitLab's Generic Package Registry, affecting versions of both Community Edition (CE) and Enterprise Edition (EE). The scope of this issue is broad, encompassing all releases from version 13.9 up to but not including 19.1.8, as well as the 19.2 series prior to patch level 6 and the 19.3 series prior to patch level 2. This extensive range indicates that the underlying authorization logic has been flawed for a significant period, potentially exposing numerous organizations to risk if they have not applied the latest security patches or are operating on legacy systems within this version spectrum.
At its core, the vulnerability stems from improper authorization checks implemented in the Generic Package Registry component of GitLab. The flaw allows an authenticated user who possesses developer-role permissions to manipulate package metadata and content in ways that exceed their intended privileges. Specifically, a malicious actor with these standard development rights can substitute the actual file content of existing packages. This capability is particularly dangerous because it enables the attacker to replace legitimate software artifacts with potentially compromised or malicious versions without detection by other users who rely on those packages for their build processes.
Beyond simple substitution, the vulnerability grants the attacker the ability to hide packages from their original owners and maintainers. By altering visibility settings or metadata associated with a package, an authenticated developer can effectively remove access to critical assets for project administrators or security teams. This action disrupts operational continuity and obscures the integrity of the software supply chain within the GitLab instance. The combination of content substitution and concealment creates a sophisticated attack vector where malicious code can be injected into widely used dependencies while simultaneously preventing immediate discovery by those responsible for maintaining package quality and security.
The operational impact of this vulnerability is severe, primarily targeting the integrity of the software development lifecycle and supply chain security. If an attacker successfully exploits this flaw, they could distribute trojanized packages that are subsequently downloaded and executed by other developers or CI/CD pipelines. This scenario aligns with known attack patterns such as Software Supply Chain Attacks, where trust in a dependency is abused to compromise downstream systems. The ability to hide packages further exacerbates the risk by delaying incident response times, allowing malicious artifacts to persist undetected within an organization's artifact repository for extended periods.
From a classification perspective, this vulnerability maps directly to CWE-269, which denotes Improper Authorization, as it involves bypassing access controls through flawed logic rather than technical exploitation of input validation errors. It also relates closely to CWE-74, Inconsistent Interpretation of HTTP Requests, if the authorization failure is tied to how requests are processed by the registry API. Furthermore, in terms of tactical behavior, this activity corresponds to ATT&CK technique T1608, specifically the Upload Malicious Tool sub-technique, as it involves uploading compromised artifacts into a trusted repository for distribution.
To mitigate this risk, organizations must ensure that all GitLab instances are upgraded to version 19.1.8 or later, or alternatively to versions within the newer branches such as 19.2.6 and above, which include the necessary patches. For environments where immediate upgrading is not feasible due to compatibility constraints, strict monitoring of package registry activities should be implemented. Security teams should audit developer permissions to ensure that only trusted individuals have access to publish or modify packages in shared namespaces. Additionally, implementing integrity verification mechanisms for downloaded artifacts can help detect any unauthorized content substitutions even if the initial upload goes undetected by GitLab's native controls.