Cloudanix VulnDB

CVE-2024-8177

High · 7.5

CVSS

7.5

EPSS

0.6%

Published

Nov 26, 2024

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in GitLab can let someone crash or slow down the service by connecting it to a specially made registry, causing outages until fixed.

Exploitation
Remote Authenticated
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
Application
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The flaw allows an attacker to trigger a denial of service condition in GitLab by configuring integration with a malicious Harbor container registry, causing resource exhaustion or service unavailability.

Why it matters to the business

Organizations using affected GitLab instances may experience unplanned downtime and loss of access to source code management and CI/CD pipelines until the instance is recovered or patched.

How an attack unfolds

An attacker prepares a malicious Harbor registry instance designed to respond in a way that exhausts GitLab resources, then configures the integration within a GitLab instance; once integrated, GitLab processes the responses leading to denial of service.

How to fix it

Upgrade GitLab CE/EE to version 17.4.5 or later, 17.5.3 or later, or 17.6.1 or later depending on the current branch. Disable Harbor registry integrations until patches are applied if immediate upgrade is not possible.

How to confirm the fix worked

Confirm the running GitLab version matches or exceeds the fixed releases listed in the advisory; review registry integration settings and test connectivity to known-good registries to verify normal operation.

Typical attack path

  1. Identify a target GitLab instance with Harbor registry integration enabled
  2. Deploy or compromise a Harbor registry that returns malicious responses
  3. Configure the malicious registry as an integrated container registry in GitLab
  4. Trigger registry synchronization or related operations to induce resource exhaustion

How to detect it

Review GitLab logs for errors or high resource usage during registry integration or synchronization events; inspect audit logs for recent changes to container registry settings from unexpected users or IPs.

What your security team should do

  • Prioritize upgrade of all GitLab instances to the specified fixed versions within the next maintenance window
  • Audit existing Harbor registry integrations for unauthorized or suspicious entries
  • Monitor EPSS and threat intelligence feeds for any increase in exploitation activity

The record

An issue was discovered in GitLab CE/EE affecting all versions starting from 15.6 prior to 17.4.5, starting from 17.5 prior to 17.5.3, starting from 17.6 prior to 17.6.1 which could cause Denial of Service via integrating a malicious harbor registry.

Affected packages

Ecosystem Package Introduced Fixed
Bitnami gitlab 15.6.0 17.4.5
Chainguard gitlab-docker-machine-17.6 0 17.6.1-r0
Chainguard gitlab-docker-machine-fips-17.6 0 17.6.1-r0
Chainguard gitlab-runner-17.6 0 17.6.1-r0
Chainguard gitlab-runner-fips-17.6 0 17.6.1-r0
Chainguard gitlab-runner-helper-17.6 0 17.6.1-r0
Chainguard gitlab-runner-helper-compat-17.6 0 17.6.1-r0
Chainguard gitlab-runner-helper-fips-17.6 0 17.6.1-r0
Chainguard gitlab-runner-helper-oci-entrypoint-17.6 0 17.6.1-r0
Chainguard gitlab-runner-oci-entrypoint-17.6 0 17.6.1-r0
Ubuntu:16.04:LTS gitlab 0 No fix
Ubuntu:Pro:16.04:LTS gitlab 0 No fix

Related vulnerabilities