Allocation of Resources Without Limits or Throttling in GitLab
Description
An issue has been discovered in GitLab EE affecting all versions from 13.3.0 prior to 16.6.7, 16.7 prior to 16.7.5, and 16.8 prior to 16.8.2 which allows an attacker to do a resource exhaustion using GraphQL vulnerabilitiesCountByDay
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A resource exhaustion vulnerability in GitLab EE's GraphQL `vulnerabilitiesCountByDay` allows attackers to cause denial of service by requesting large date ranges.
Vulnerability
An issue in GitLab EE affects all versions from 13.3.0 prior to 16.6.7, 16.7 prior to 16.7.5, and 16.8 prior to 16.8.2. The VulnerabilitiesCountPerDayResolver used in the security dashboard's GraphQL API does not enforce a limit on the date range supplied via startDate and endDate parameters. This allows an attacker to request counts for an arbitrarily large span of dates, triggering excessive database queries and resource consumption [1].
Exploitation
An attacker with network access to the GitLab instance and valid authentication (e.g., a user with access to a project) can craft a GraphQL query such as projectVulnerabilitiesCount with a very wide date range (e.g., spanning years). The resolver then iterates over every date in the range, generating a large number of database queries and consuming server resources [1].
Impact
Successful exploitation leads to resource exhaustion, causing denial of service for other users and potentially degrading or crashing the GitLab instance. The attack does not require special privileges beyond a standard authenticated user account [1].
Mitigation
GitLab has released fixed versions: 16.6.7, 16.7.5, and 16.8.2. Users should upgrade to these versions or later. No workaround is documented in the available references [1].
AI Insight generated on May 24, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >=13.3.0 <16.6.7, >=16.7.0 <16.7.5, >=16.8.0 <16.8.2
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing input validation on date range bounds in `VulnerabilitiesCountPerDayResolver` allows an attacker to trigger an infinite-size array allocation in memory."
Attack vector
An authenticated attacker sends a crafted GraphQL query to the `vulnerabilitiesCountByDay` field with an extremely wide date range (e.g. `startDate: "0001-01-01"` and `endDate: "5874897-01-01"`) [ref_id=1]. The resolver attempts to materialize an array of every date in that range in memory before any pagination is applied, causing the Ruby process to consume gigabytes of memory (7.4 GB observed in testing) and eventually exhaust all available resources [ref_id=1]. No special privileges beyond a valid GitLab account are required, and the attack is carried out over the network via the GraphQL API.
Affected code
The vulnerability resides in `VulnerabilitiesCountPerDayResolver` (`ee/app/graphql/resolvers/vulnerabilities_count_per_day_resolver.rb`). The resolver accepts arbitrary `startDate` and `endDate` parameters and iterates through every date in the range with `(start_date..end_date).to_a` before pagination is applied [ref_id=1]. There are no upper or lower bounds on the date range, and Ruby's `Date` class supports astronomically large year values (e.g. ±999999999999) [ref_id=1].
What the fix does
The issue report recommends three possible fixes: truncating date ranges outside a certain size, applying pagination before backfilling counts, or imposing sensible limits on what years can be in a date [ref_id=1]. The proposed implementation plan is to compute `end_date.year - start_date.year` and error out if the result exceeds 1 (year) [ref_id=1]. No official patch is included in the bundle, so the fix has not been published here.
Preconditions
- authAttacker must have a valid GitLab account (authenticated session)
- networkAttacker must be able to send GraphQL queries to the GitLab instance
- configThe GitLab instance must be EE edition (all versions 13.3.0 to 16.6.7, 16.7.0 to 16.7.5, or 16.8.0 to 16.8.2)
- inputAttacker provides an extremely wide date range (e.g. startDate and endDate spanning millions of years)
Reproduction
1. Log in to a GitLab EE instance (GDK or production). 2. Send the following GraphQL query: ```graphql query projectVulnerabilitiesCount { project(fullPath: "gitlab-org/gitlab-test") { id vulnerabilitiesCountByDay(startDate: "0001-01-01", endDate: "5874897-01-01") { nodes { date critical high info low medium unknown } } } } ``` 3. Observe that the request hangs for minutes, the Ruby process memory grows to multiple GB (7.4 GB observed), and memory is not freed after timeout [ref_id=1].
Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
1- gitlab.com/gitlab-org/gitlab/-/issues/420341mitreissue-trackingpermissions-required
News mentions
1- GitLab Security Release: 16.8.2, 16.7.5, 16.6.7GitLab Security Releases · Feb 7, 2024