CVE-2025-0290 Overview
CVE-2025-0290 is a denial of service vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE). The flaw affects all versions starting from 15.0 prior to 17.5.5, from 17.6 prior to 17.6.3, and from 17.7 prior to 17.7.1. Processing of Continuous Integration (CI) artifacts metadata can cause background jobs to become unresponsive under certain conditions. The issue is tracked as [CWE-835] (Loop with Unreachable Exit Condition). An authenticated attacker with low privileges can trigger the condition over the network to degrade GitLab background job processing.
Critical Impact
Authenticated users can render GitLab background jobs unresponsive by supplying crafted CI artifacts metadata, disrupting pipeline processing and dependent workflows.
Affected Products
- GitLab Community Edition versions 15.0 through 17.5.4
- GitLab Enterprise Edition versions 17.6.0 through 17.6.2
- GitLab Community and Enterprise Edition version 17.7.0
Discovery Timeline
- 2025-01-28 - CVE-2025-0290 published to the National Vulnerability Database (NVD)
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-0290
Vulnerability Analysis
The vulnerability resides in GitLab's handling of CI artifacts metadata. When GitLab parses artifacts metadata for a job, specific input conditions cause the background worker to enter a state it cannot exit. This aligns with [CWE-835], which describes a loop with an unreachable exit condition. Background jobs stop making progress and consume worker capacity. As Sidekiq workers stall, subsequent CI jobs, notifications, and asynchronous tasks queue up or fail to complete. The attacker needs authenticated access with low privileges but does not require user interaction. Exploitation impacts availability only. Confidentiality and integrity are not directly affected. The referenced GitLab Issue #372134 documents the underlying tracking discussion.
Root Cause
The root cause is improper termination logic in the artifacts metadata processing path. Crafted metadata structures cause parsing routines to loop without reaching a completion state. The background job worker, typically Sidekiq, remains occupied indefinitely on the affected task.
Attack Vector
An authenticated user uploads or triggers processing of malformed CI artifacts metadata. The attack is remote over the network and does not require elevated privileges beyond a standard project role capable of running CI jobs. No end-user interaction is required to complete exploitation.
No verified public exploit code exists for CVE-2025-0290. Technical specifics remain restricted to the vendor's advisory and internal tracking issue.
Detection Methods for CVE-2025-0290
Indicators of Compromise
- Sidekiq background jobs that remain in a running state for abnormally long durations without completing.
- Sudden growth of pending CI pipeline jobs and unprocessed artifacts uploads.
- Elevated CPU usage on GitLab background job workers tied to artifact metadata processing.
Detection Strategies
- Monitor Sidekiq queue latency and job execution time using GitLab's built-in Prometheus metrics.
- Alert on repeated timeouts or restarts of ExpireBuildArtifactsWorker and related artifact workers.
- Correlate authenticated CI job submissions with subsequent worker unresponsiveness in audit logs.
Monitoring Recommendations
- Track the sidekiq_running_jobs and sidekiq_queue_size metrics for anomalies aligned with artifact uploads.
- Enable GitLab audit event streaming for CI job execution and artifact upload activity.
- Review web server access logs for repeated POST requests to /api/v4/jobs/*/artifacts from single accounts.
How to Mitigate CVE-2025-0290
Immediate Actions Required
- Upgrade GitLab CE/EE to version 17.5.5, 17.6.3, 17.7.1, or later.
- Restrict CI job execution privileges to trusted project members while patching is in progress.
- Review Sidekiq worker health and restart stalled workers to restore background job throughput.
Patch Information
GitLab released fixed versions 17.5.5, 17.6.3, and 17.7.1 that address the artifact metadata processing loop. Self-managed administrators should upgrade using the standard GitLab upgrade path. GitLab.com is maintained by GitLab and does not require customer action. Refer to GitLab Issue #372134 for tracking context.
Workarounds
- Limit CI job submission to trusted maintainers until the upgrade is applied.
- Configure Sidekiq job timeouts so stalled workers are terminated and recycled automatically.
- Monitor artifact upload volume and rate-limit API calls to /api/v4/jobs/*/artifacts at the reverse proxy layer.
# Example: verify installed GitLab version before and after upgrade
sudo gitlab-rake gitlab:env:info | grep "GitLab information" -A 5
# Debian/Ubuntu upgrade example to a fixed release
sudo apt-get update
sudo apt-get install gitlab-ee=17.7.1-ee.0
# Restart Sidekiq to clear any stalled background jobs
sudo gitlab-ctl restart sidekiq
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
