Allocation of Resources Without Limits or Throttling in GitLab
Description
A denial of service issue was discovered in GitLab CE/EE affecting all versions starting from 13.2.4 before 15.10.8, all versions starting from 15.11 before 15.11.7, all versions starting from 16.0 before 16.0.2 which allows an attacker to cause high resource consumption using malicious test report artifacts.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A crafted gzip bomb uploaded as a JUnit test report artifact causes high resource consumption and denial of service in GitLab CE/EE.
Vulnerability
A denial of service vulnerability exists in GitLab CE/EE versions 13.2.4 through 15.10.8, 15.11 before 15.11.7, and 16.0 before 16.0.2 [1]. The bug allows an attacker to upload a malicious gzip file (a zip bomb) as a JUnit test report artifact in a CI job. When GitLab processes the artifact, it decompresses the file, causing excessive memory consumption on both the Sidekiq background job processor and the Puma web server [1].
Exploitation
An authenticated attacker with the ability to create a CI job and attach a JUnit test report can upload a compressed file that expands to a very large size (e.g., 12 GiB) [1]. After the artifact is processed, Sidekiq memory is exhausted, causing a crash. Additionally, unauthenticated users can trigger the same resource exhaustion on Puma by making simple API requests against the public project, sustaining the denial of service with as few as a couple of requests per second [1]. Rate limits are ineffective because the initial upload is a single small file and the ongoing API requests are low-volume [1].
Impact
Successful exploitation leads to high resource consumption (memory and CPU) causing Sidekiq and/or Puma processes to be killed by the OOM killer, resulting in a denial of service for the GitLab instance [1]. In smaller deployments, the instance may become unresponsive or respond very slowly [1]. The vulnerability impacts availability (CIA triad), but does not affect confidentiality or integrity. An unauthenticated attacker can sustain the denial of service on public projects [1].
Mitigation
GitLab released fixed versions: 15.10.8, 15.11.7, and 16.0.2 [1]. All users running affected versions should upgrade immediately. No workaround is available. The issue is not listed on the CISA KEV catalog as of the publication date.
AI Insight generated on May 25, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >=13.2.4 <15.10.8, >=15.11 <15.11.7, >=16.0 <16.0.2
- Range: >=13.2.4, <15.10.8
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing size limit in GzipStream adapter allows unbounded decompression of gzip artifacts, leading to memory exhaustion."
Attack vector
An attacker uploads a crafted gzip file (a "zip bomb") as a JUnit test report artifact to a CI job [ref_id=1]. The gzip file is small on disk but decompresses to a very large size (e.g., 12 GiB) [ref_id=1]. When Sidekiq processes the artifact (e.g., via `Ci::BuildFinishedWorker`), it calls `gz.read` with no length limit, causing excessive memory consumption and an OOM kill [ref_id=1]. After the artifact is stored, unauthenticated users can trigger the same decompression by making API requests to the test report endpoint, causing Puma workers to also exhaust memory and crash [ref_id=1]. The attack requires only that the project is public (or the attacker has pipeline creation privileges) and can be sustained with a low request rate [ref_id=1].
Affected code
The vulnerability is in the `Gitlab::Ci::Build::Artifacts::Adapters::GzipStream` class, which is used to unpack test report artifacts (JUnit reports, coverage reports, etc.) [ref_id=1]. This class is invoked from Sidekiq background jobs (e.g., `Ci::BuildFinishedWorker`) and directly from API endpoints such as the test report API (`/api/v4/projects/
What the fix does
The advisory does not include a published patch diff, but the expected correct behavior is that the amount of data read from `GzipStream` should be limited [ref_id=1]. The fix should impose a maximum decompressed size on the `gz.read` call so that multi-gigabyte files are rejected rather than fully buffered in memory [ref_id=1]. Without such a limit, both Sidekiq and Puma remain vulnerable to resource exhaustion via any artifact type that uses `GzipStream` [ref_id=1].
Preconditions
- authThe attacker must be able to create a CI pipeline and upload a test report artifact (requires at least Developer role on a project, or the project must be public and allow sign-ups)
- configThe project must be publicly accessible for unauthenticated users to trigger the Puma DoS via the test report API
- networkThe attacker must have network access to the GitLab instance's API endpoint
- inputThe attacker uploads a crafted gzip file that decompresses to a very large size (e.g., 12 GiB)
Reproduction
1. Create a payload: `touch report.json && fallocate -l 12GiB report.json && gzip report.json` [ref_id=1]. 2. Import the attached sample project as a public project in a GitLab instance [ref_id=1]. 3. Configure a Docker-based GitLab runner for the project [ref_id=1]. 4. Run a pipeline on the main branch; the CI job uploads the payload gzip file [ref_id=1]. 5. Sidekiq will crash with an OOM kill when it tries to read the decompressed file [ref_id=1]. 6. For the Puma DoS, find the project ID and pipeline ID, then run: `while true; do sleep 0.5 ; curl -m 0.1 'http://
Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3News mentions
1- GitLab Security Release: 16.0.2, 15.11.7, and 15.10.8GitLab Security Releases · Jun 5, 2023