GitLab Zero-Click Exploit Under Active Attack: How to Stop the Leak

Active exploitation campaigns are targeting self-hosted GitLab instances globally, allowing unauthenticated threat actors to exfiltrate private repository data, steal CI/CD credentials, and compromise software supply chains. Security teams must act immediately to audit their self-hosted environments and apply vendor patches.

The campaign leverages a critical flaw in GitLab's authentication and authorization workflows. By bypassing access controls, attackers can query sensitive API endpoints without providing valid credentials, effectively gaining read access to proprietary codebases, configuration files, and hardcoded environment variables.

For security teams managing on-premise or cloud-hosted GitLab deployments, understanding the mechanics of this threat is essential for detecting compromise and securing the development pipeline. Our team at Zero Hour Tech tracks these developments closely through our cybersecurity threat advisories.

The Anatomy of the Authentication Bypass

The vulnerability stems from an validation failure within GitLab's handling of user sessions and federated authentication providers, such as SAML. In affected versions, the application fails to adequately validate XML signatures or token signatures under specific conditions. This allows an attacker to forge authentication responses and masquerade as an administrator or high-privileged user without knowing their password.

Once administrative or developer-level access is achieved, the attacker can leverage GitLab's GraphQL and REST APIs to systematically harvest data. Because the exploit can be executed programmatically, threat actors are using automated scanners to discover exposed GitLab instances and pull down repository contents within minutes of discovery.

Exploitation of the GraphQL API

Attackers are focusing heavily on GitLab's GraphQL endpoint (/api/graphql). This endpoint is highly attractive to threat actors because it allows them to batch requests and retrieve massive datasets with minimal network noise.

For example, an attacker can craft a single GraphQL query to retrieve a list of all projects, their associated runner registration tokens, and CI/CD variables:

query {
  projects(first: 100) {
    nodes {
      id
      name
      httpUrlToRepo
      runners {
        nodes {
          token
        }
      }
    }
  }
}

If the instance is vulnerable, this query bypasses standard authorization checks, returning sensitive repository paths and runner tokens that can be used to execute arbitrary code within the organization's build pipelines.

Identifying Vulnerable Deployments

According to the GitLab Security Advisory, this issue affects both GitLab Community Edition (CE) and Enterprise Edition (EE). Organizations running self-managed instances must verify their version numbers immediately.

Because of the severity of this active campaign, the CISA Known Exploited Vulnerabilities Catalog has been updated to include this vulnerability, mandating federal agencies to patch their systems immediately.

Threat Hunting: How to Detect Compromise

If you are running an affected version of GitLab, patching alone is not enough. You must conduct a thorough forensic audit to ensure threat actors have not already gained a foothold in your network.

1. Analyze your Web Server Logs

Search your api_json.log and production_json.log files for anomalous requests to the GraphQL or SAML endpoints. Look for high volumes of requests originating from unfamiliar IP addresses, particularly those targeting project export or repository archive endpoints.

grep -E '"path":"/api/v4/projects/[0-9]+/export"' /var/log/gitlab/gitlab-rails/api_json.log

An unexpected spike in project export requests is a strong indicator that an attacker has successfully bypassed authentication and is actively packaging your source code for exfiltration.

2. Inspect SAML Assertions

If your organization uses SAML for Single Sign-On (SSO), review your identity provider (IdP) logs. Cross-reference the logins recorded on your IdP with the active sessions on your GitLab instance. If you find successful GitLab sessions without matching authentication events in your IdP logs, your instance has likely been compromised via signature forgery.

3. Check for Rogue CI/CD Runners

Attackers who gain administrative access often register rogue CI/CD runners to intercept build jobs or execute malicious code within your infrastructure. Run the following command via the GitLab Rails console to list all registered runners and verify their legitimacy:

Project.find_each do |project|
  project.runners.each do |runner|
    puts "Project: #{project.name} | Runner ID: #{runner.id} | Description: #{runner.description}"
  end
end

Immediate Remediation and Hardening

If your self-hosted GitLab instance is exposed to the public internet, isolate it immediately or restrict access to trusted source IPs via firewall rules. Implement the following remediation steps:

1. Upgrade GitLab immediately: Apply the latest security release for your specific branch using your system's package manager. For example, on Ubuntu/Debian:

   sudo apt-get update && sudo apt-get --only-upgrade install gitlab-ee
   

2. Rotate Secrets: If you find any evidence of unauthorized access, assume all repository secrets, CI/CD variables, API tokens, and SSH keys have been compromised. Revoke and rotate them immediately.
3. Enforce IP Whitelisting: Restrict access to your GitLab instance to corporate VPN ranges and trusted developer IPs to prevent external attackers from probing your endpoints.
4. Enable Multi-Factor Authentication (MFA): Ensure MFA is enforced globally across all accounts, and regularly audit administrative user accounts for unauthorized additions.

To ensure your security posture remains resilient against emerging threats, review our verified editorial standards for trusted, practitioner-focused technical analysis.