CVE-2026-8472: GitLab EE Work Item Metadata Disclosure via Missing Authorization Checks

Technical summary

This vulnerability is a broken access control issue (CWE-862) affecting GitLab EE across multiple version branches. When users with limited privileges attempt to access work items, the application does not adequately validate authorization constraints before returning metadata. The flaw exists in versions 18.9 through 18.11.6, 19.0 through 19.0.3, and 19.1 through 19.1.1. The vulnerability is triggered under specific conditions, suggesting the exposure is not universal across all work item interactions but rather tied to particular API endpoints or request patterns. No elevated privileges or user interaction is required; a straightforward authenticated request is sufficient to trigger the disclosure.

Business impact

Information disclosure of work item metadata from private projects can expose sensitive internal planning, roadmap details, bug reports, and task assignments that organizations intend to keep confidential. For development teams, this could reveal competitive product plans or engineering decisions. For security-focused organizations, leaked work item data might disclose vulnerability details, incident response timelines, or internal security assessments. The impact is amplified in multi-tenant or collaborative environments where team members from different projects or departments should not cross-pollinate access. While the CVSS score is moderate (4.3), the reputational and compliance implications depend heavily on what metadata is exposed and the regulatory context of the data (GDPR, HIPAA, SOC 2, etc.).

Affected systems

All GitLab Enterprise Edition installations are affected if running version 18.9 or later up to the specified patch levels. Specifically: versions 18.9 to 18.11.6 (patch to 18.11.7 or later), versions 19.0.0 to 19.0.3 (patch to 19.0.4 or later), and versions 19.1.0 to 19.1.1 (patch to 19.1.2 or later). GitLab Community Edition is not listed as affected. Self-hosted instances, cloud-hosted on gitlab.com, and third-party hosted GitLab deployments are all potentially vulnerable if they have not applied the relevant patches. Organizations running versions prior to 18.9 or at or above the patched versions are not impacted by this specific vulnerability.

Exploitability

Exploitation is straightforward once an attacker possesses valid GitLab credentials. No special tools, zero-day chaining, or sophisticated techniques are required; the vulnerability can be triggered via standard API calls or web interface interactions. The attack is repeatable and does not require timing windows or race conditions. However, the attacker must first obtain a valid account with at least minimal permissions—they cannot exploit this as an unauthenticated user. This limits the attack surface to insiders, compromised accounts, or users with inadvertently granted access. The vulnerability is not currently tracked in the CISA Known Exploited Vulnerabilities (KEV) catalog, though this does not guarantee exploit code is unavailable or the flaw is not being targeted.

Remediation

Apply patches immediately according to your version branch: upgrade to GitLab EE 18.11.7 or later if on the 18.9–18.11.x line, 19.0.4 or later if on the 19.0.x line, or 19.1.2 or later if on the 19.1.x line. Verify patch applicability against GitLab's official security advisory. If immediate patching is not feasible, restrict API access to work items via network segmentation or authentication policies, and audit existing access logs to identify unauthorized metadata reads. Consider temporarily disabling work item API endpoints if they are not critical to operations, though this may disrupt integrations or automation. Monitor user accounts with recent privilege changes or unusual access patterns post-compromise.

Patch guidance

Consult GitLab's official security advisory for exact patch version numbers and deployment procedures specific to your installation type (self-hosted, Helm, Docker, etc.). Test patches in a staging environment before production rollout to ensure compatibility with your customizations or third-party integrations. Plan maintenance windows if your deployment requires downtime; some upgrade paths may support zero-downtime deployments depending on your setup. After patching, verify that work item metadata access controls are functioning as expected by testing from a low-privilege test account to confirm that private project data is no longer readable. Review any automation or integration that accesses work item APIs to ensure it continues to function post-patch.

Detection guidance

Audit GitLab API access logs and application logs for unusual patterns of work item metadata queries originating from low-privilege accounts, particularly those accessing projects the account has no explicit membership in. Look for repeated 200 OK responses to work item endpoints from accounts that should not have visibility. If your GitLab instance sends logs to a SIEM, create detection rules for high-volume or anomalous work item API calls from user accounts. Enable GitLab's native audit logging if not already active, and review permission assignments to ensure principle of least privilege is enforced. Investigate any alerts correlating with the affected version ranges and recent account activity changes.

Why prioritize this

Although the CVSS score is moderate (4.3), this vulnerability warrants prompt prioritization because it affects a widely-used DevOps platform that often houses sensitive business and technical information. The combination of low barrier to exploitation (valid credentials), broad scope (all EE installations on affected versions), and high informational value of work item metadata makes this a credible insider-risk and supply-chain intelligence concern. Organizations in regulated industries or handling competitive intellectual property should treat this as high-priority. The straightforward remediation path (standard patching) reduces operational friction, enabling faster deployment cycles.

Risk score, explained

The CVSS 3.1 score of 4.3 reflects a low attack complexity, network-based attack vector, and requirement for low privileges, but the impact is limited to confidentiality (information disclosure only; no integrity or availability loss). The score accurately captures that this is not a critical vulnerability, but it underweights the business context: leaked work item metadata can carry significant strategic or compliance implications depending on content. Use this score as a baseline, not a ceiling; your organizational risk appetite, data sensitivity, and regulatory requirements should elevate the priority above the numerical rating.

Frequently asked questions