Critical GitLab vulnerability allows unauthenticated deletion of public projects

The Hacker News reports that GitLab has released security updates to address a critical vulnerability, tracked as CVE-2026-19478, that could allow an unauthenticated attacker to remotely modify or delete public projects and user data under certain conditions. The flaw, which has been assigned a CVSS score of 9.4, affects both GitLab Community Edition and Enterprise Edition. The vulnerability exists in GitLab's GraphQL API and could be exploited without requiring authentication, meaning any attacker with network access to a vulnerable GitLab instance could potentially target public repositories. GitLab has released patches for affected versions and is urging organisations to apply the updates immediately.

Why this matters for UK organisations

For UK organisations using GitLab, whether self-hosted or cloud-based, this vulnerability represents a significant risk to code integrity, intellectual property and development continuity. Public repositories are often used for open-source projects, documentation, internal tools and shared libraries, and the ability for an unauthenticated attacker to modify or delete these projects could disrupt development pipelines, introduce malicious code, or cause permanent data loss. Even organisations that primarily use private repositories may have public projects for community engagement, API documentation or open-source contributions. The operational impact of such an attack could include loss of version history, disruption to CI/CD pipelines that depend on affected repositories, reputational damage if malicious code is introduced, and the need for time-consuming recovery efforts from backups. The flaw highlights the risks associated with API security in widely-used development platforms, where a single vulnerability can expose critical code repositories and development workflows to unauthorised access.

What to review

Organisations should review whether GitLab instances have been updated to the latest patched versions as released by GitLab in their security advisory. For self-hosted GitLab installations, this means checking that the patch has been applied and that the update process has been tested in a non-production environment first. It is also worth reviewing whether public repositories contain sensitive or business-critical code that should be moved to private repositories, whether backup and recovery processes for GitLab data are tested and reliable, and whether there is a clear process for restoring repositories in the event of data loss or tampering. Organisations should also check whether API access is being monitored for unusual activity, whether rate limiting and access controls are configured appropriately, and whether there are alerts in place for unexpected changes to repository content or permissions. Finally, it is worth ensuring that development teams understand the risks associated with public repositories and have clear guidance on what types of code, documentation and configuration should never be made public.

Source: The Hacker News