CVE-2026-8937 in GitLab
Summary
by MITRE • 09/29/2026
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 19.0 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 read private child issue contents, including titles and descriptions, from projects they had no access to, due to missing authorization checks on linked work items within visible epics.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/29/2026
GitLab has addressed a critical security vulnerability affecting its Community Edition (CE) and Enterprise Edition (EE) platforms across multiple version branches, specifically versions prior to 19.2.7 for the 19.0 series, prior to 19.3.3 for the 19.3 series, and prior to 19.4.1 for the 19.4 series. This flaw represents a significant breach in access control mechanisms within the issue tracking system, allowing authenticated users to bypass project-level permissions under specific conditions involving linked work items. The vulnerability stems from insufficient authorization checks when processing relationships between epics and their child issues, creating an avenue for unauthorized data exposure that compromises the confidentiality of sensitive project information.
The technical root cause lies in how GitLab handles associations between parent epics and child issues within its backend logic. When a user accesses a visible epic to which they have been granted permission, the system fails to adequately validate whether the authenticated user possesses explicit access rights to any linked private child issues associated with that epic. Consequently, if an issue is privately scoped but logically connected to an accessible public or shared epic through internal linking mechanisms such as merge request references or direct issue links, the application erroneously exposes metadata and content of those private items. This includes sensitive details like titles, descriptions, labels, and potentially other contextual data embedded within the issue body, effectively circumventing the intended isolation boundaries established by project administrators.
From an operational impact perspective, this vulnerability enables authenticated attackers to perform unauthorized information disclosure against resources they should not be able to view. In enterprise environments where projects often contain proprietary code snippets, confidential business requirements, or sensitive customer data, such exposure can lead to significant intellectual property theft and compliance violations. The attack vector requires the adversary to possess valid credentials for any user account within the GitLab instance, which lowers the barrier to entry compared to unauthenticated attacks but remains a serious threat in multi-tenant deployments where trust boundaries between teams are strictly enforced. Attackers could systematically enumerate accessible epics and extract data from linked private issues without triggering standard access denial logs associated with direct unauthorized resource requests, making detection more challenging for security monitoring systems that rely on explicit permission rejection events.
This vulnerability aligns closely with CWE-284 Improper Access Control, specifically reflecting failures in enforcing user authorization restrictions where the application does not properly verify permissions before granting access to sensitive data objects. Furthermore, it maps to MITRE ATT&CK technique T1530 Data from Information Repositories, as the attacker leverages legitimate authentication credentials and trusted system relationships to exfiltrate stored information that is otherwise protected by role-based or project-level security policies. The exploitation relies on the logical relationship between entities rather than a direct injection or buffer overflow flaw, highlighting the importance of rigorous authorization logic in complex relational data models common in modern collaboration software.
To mitigate this risk, organizations running affected versions must immediately upgrade to GitLab 19.2.7, 19.3.3, or 19.4.1 depending on their current release track. These patched releases include corrected authorization checks that ensure child issues are validated against the requesting user's permissions independently of the parent epic's accessibility status. Until upgrades can be performed, administrators should review project access logs for unusual patterns involving issue linking and consider restricting visibility settings to minimize exposure surfaces. Additionally, implementing strict role-based access controls and auditing linked resource relationships can help identify potential misuse while patching efforts are underway. Regular security updates remain essential as GitLab continues to refine its permission model to address edge cases in complex hierarchical data structures.