Maximum Severity GitLab Vulnerability Puts Supply Chains at Risk

GitLab has disclosed a critical path traversal vulnerability, CVE-2026-85706, with a maximum CVSS score of 10.0. The flaw affects both GitLab Community Edition and Enterprise Edition instances, and could allow an attacker to traverse file paths and access sensitive data or execute code. The vulnerability impacts the software supply chain, as GitLab is widely used for source code management, CI/CD pipelines and DevOps workflows across enterprises. GitLab has released patches, and organisations are being urged to update immediately. The severity rating reflects the potential for widespread impact if exploited, particularly given GitLab's role in managing code repositories and deployment pipelines.

Why this matters for UK organisations

GitLab is a core component of many UK organisations' software development and deployment processes. A vulnerability of this severity in a platform that manages source code, credentials, CI/CD pipelines and deployment secrets represents a significant supply chain risk. An attacker who successfully exploits this flaw could gain access to proprietary code, inject malicious changes into software builds, steal API keys and deployment credentials, or compromise downstream systems that rely on code and artefacts managed through GitLab. The maximum severity score reflects the fact that exploitation could lead to full system compromise without requiring authentication or user interaction, depending on configuration. For organisations that develop software internally or manage third-party code through GitLab, this vulnerability could provide attackers with a route to compromise not just the GitLab instance itself, but every system and application that depends on it.

What to review

For organisations using GitLab, this is a prompt to prioritise patching and review access controls, monitoring and audit logging around your GitLab instances. Consider whether your current visibility into GitLab activity would detect unauthorised access or suspicious changes to repositories and pipelines. Review who has administrative access to GitLab, whether multi-factor authentication is enforced for all users, and whether you have processes in place to detect and respond to unauthorised code changes or credential theft. Consider whether your current vulnerability management process treats supply chain components like GitLab with the same urgency as internet-facing systems. Ensure that responsibility for securing development infrastructure is clearly assigned and that security and development teams have a shared understanding of the risks associated with compromised source code management platforms.

Source: Dark Reading