CVE-2022-1954
Description
A Regular Expression Denial of Service vulnerability in GitLab CE/EE affecting all versions from 1.0.2 prior to 14.10.5, 15.0 prior to 15.0.4, and 15.1 prior to 15.1.1 allows an attacker to make a GitLab instance inaccessible via specially crafted web server response headers
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A ReDoS vulnerability in GitLab CE/EE allows an attacker to cause CPU exhaustion via crafted webhook response headers.
Vulnerability
A Regular Expression Denial of Service (ReDoS) vulnerability exists in GitLab CE/EE affecting all versions from 1.0.2 prior to 14.10.5, 15.0 prior to 15.0.4, and 15.1 prior to 15.1.1 [1]. The bug resides in Ruby's net/http library used when processing webhook responses; specifically, the sub(\s+\z, '') operation on header lines has quadratic complexity when the header contains many spaces but does not end with a space [1]. An attacker-controlled webhook receiver can respond with a specially crafted long header to trigger this behavior [1].
Exploitation
An attacker must control a webhook receiver endpoint that a GitLab instance will send webhooks to (e.g., for project events) [1]. The attacker then responds with an HTTP header line containing many spaces (e.g., 950,000 spaces) followed by a non-space character and a newline [1]. The GitLab Sidekiq job processing the webhook will become stuck at 100% CPU for an extended period (weeks) while the regular expression processes the header [1]. A timeout added earlier (in 14.9.2) is bypassed because the timeout check only occurs after the regex completes [1].
Impact
Successful exploitation causes a denial of service: the web_hook Sidekiq job consumes 100% CPU, rendering the GitLab instance inaccessible or severely degraded for weeks [1]. The long header is also kept in memory, and the connection remains open, potentially leading to memory and connection exhaustion [1]. No data confidentiality or integrity is compromised.
Mitigation
Fixed versions: GitLab 14.10.5, 15.0.4, and 15.1.1 [1]. Users should upgrade to these patched versions immediately. No workaround is available for unpatched instances [1]. The vulnerability is not listed in CISA KEV as of the publication date.
AI Insight generated on May 27, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: <14.10.5, <15.0.4, <15.1.1
- Range: >=1.0.2, <14.10.5
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing input validation and use of a quadratic-complexity regex (`/\s+\z/`) in Ruby's net/http header parsing causes ReDoS when processing maliciously crafted HTTP response headers."
Attack vector
An attacker sets up a malicious webhook receiver that responds with an HTTP header line containing many consecutive spaces (e.g., 950,000 spaces) that does not end in a space. When GitLab's webhook or system hook makes an HTTP request to this receiver, Ruby's `net/http` processes the header with the regex `/\s+\z/`, which exhibits quadratic backtracking on such input. This causes the Sidekiq worker to spin at 100% CPU for an extremely long time (over a year for 9.5 million spaces), effectively denying service. The attack requires the attacker to control a webhook endpoint that GitLab contacts, and if the endpoint is on a local network, the admin must have enabled "Allow requests to the local network from web hooks and services".
Affected code
The vulnerability is in Ruby's `net/http/response.rb` at line 57, where the regex `/\s+\z/` is used in a `sub` call to strip trailing whitespace from header lines. In GitLab, this code is reached through the HTTP call chain: `lib/gitlab/http.rb:57` (`perform_request`) and `app/services/web_hook_service.rb:125` (`make_request`).
What the fix does
The advisory does not include a patch diff, but the recommended fix is to replace the regex-based `sub(/\s+\z/, '')` with a linear-time alternative such as `rstrip`. The issue was addressed in GitLab versions 14.10.5, 15.0.4, and 15.1.1. The advisory also suggests potentially dropping responses with very long header lines as an additional mitigation.
Preconditions
- networkAttacker must control a webhook receiver endpoint that GitLab will contact
- configIf the malicious server is on a local network, the GitLab admin must have enabled 'Allow requests to the local network from web hooks and services'
- configA webhook or system hook must be configured to point at the attacker's endpoint
Reproduction
1. Run the attached malicious Node.js server on port 3000: `node ./net-http-response.js`. 2. Create a project and add webhooks for issue events pointing to `http://maliciousserver:3000/xyz`. 3. If the malicious server is on a local network, enable "Allow requests to the local network from web hooks and services" in `/admin/application_settings/network`. 4. Create, close, or reopen an issue to trigger the webhook. 5. The malicious server responds with `HTTP/1.1 200 OK` and a header line containing 9,500,000 consecutive spaces. 6. The `web_hook` Sidekiq job becomes stuck at 100% CPU and will not complete for over a year.
Generated on May 24, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3- gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-1954.jsonmitrex_refsource_CONFIRM
- gitlab.com/gitlab-org/gitlab/-/issues/358160mitrex_refsource_MISC
- hackerone.com/reports/1531958mitrex_refsource_MISC
News mentions
0No linked articles in our index yet.