CVE-2026-92530 in GitLab
Summary
by MITRE • 09/24/2026
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 19.1 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1 that under certain conditions could have allowed an authenticated user to spoof merge request authorship and attribute content to arbitrary existing users on the target instance due to improper reliance on ephemeral cache state during Direct Transfer imports.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/24/2026
GitLab has addressed a significant security vulnerability affecting its Community Edition (CE) and Enterprise Edition (EE) platforms, specifically targeting versions prior to 19.2.7 in the 19.1 series, prior to 19.3.3 in the 19.3 series, and prior to 19.4.1 in the 19.4 series. This flaw stems from an improper reliance on ephemeral cache state during Direct Transfer imports, a feature designed to facilitate efficient data migration between GitLab instances by leveraging existing repository objects rather than re-transferring all content over the network. The vulnerability allows for a sophisticated form of identity spoofing where authenticated users can manipulate import processes to falsely attribute code commits and merge request activities to arbitrary existing users within the target instance, thereby compromising the integrity of project history and audit trails.
The technical root cause lies in how GitLab handles temporary state during the Direct Transfer operation. When an import is initiated, the system relies on cached metadata to map source entities to destination counterparts efficiently. In vulnerable versions, this cache mechanism was not sufficiently validated or isolated against malicious manipulation by authenticated users with access to merge requests. By carefully crafting specific inputs during a direct transfer scenario, an attacker can exploit race conditions or state inconsistencies in the ephemeral storage layer. This exploitation enables the injection of false authorship data, causing commits and changes made by one user to appear as if they were authored by another existing user on the target instance. Such behavior bypasses standard authentication checks for attribution because the system trusts the cached mapping without verifying its authenticity against a persistent source of truth during the critical import window.
The operational impact of this vulnerability is severe, particularly in environments where code integrity and accountability are paramount. By spoofing merge request authorship, an attacker can frame other employees or contributors for malicious changes, potentially leading to internal disputes, wrongful termination, or reputational damage within organizations that rely on GitLab for their software development lifecycle. Furthermore, the distortion of commit history undermines version control reliability, making it difficult for security teams and auditors to trace the origin of specific code alterations. This erosion of trust in the repository's provenance can have downstream effects on supply chain security, as automated systems may incorrectly assume that certain trusted users authored vulnerable or malicious code segments.
From a classification perspective, this vulnerability aligns with CWE-287, which covers Improper Authentication, specifically regarding misidentification and impersonation issues within application logic rather than simple credential bypass. It also relates to CWE-913, as it involves the manipulation of state that leads to unintended behavior in business logic. In terms of adversary tactics, this exploit maps to MITRE ATT&CK technique T1078, Valid Accounts, where an attacker uses legitimate credentials to perform actions that subvert system integrity without necessarily gaining unauthorized access to restricted areas. The attack vector is primarily local or network-based depending on instance configuration but requires initial authentication, placing it in the category of authenticated attacks rather than remote code execution or unauthenticated exploits.
Mitigation strategies for this issue involve immediate upgrade to patched versions: 19.2.7 and later for the 19.1 branch, 19.3.3 and later for the 19.3 branch, and 19.4.1 and later for the 19.4 branch. Organizations should verify their current GitLab version through the administration dashboard and schedule maintenance windows to apply these updates promptly. For instances that cannot be upgraded immediately due to operational constraints, administrators should restrict access to Direct Transfer imports by limiting permissions to a minimal set of trusted users who require this functionality for migration tasks. Additionally, implementing strict monitoring on merge request activity can help detect anomalies in authorship attribution patterns, although such detection is reactive rather than preventive. Regular audits of commit history and user activity logs are recommended to identify any potential exploitation that may have occurred prior to patching.