CVE-2022-2908
Description
A potential DoS vulnerability was discovered in Gitlab CE/EE versions starting from 10.7 before 15.1.5, all versions starting from 15.2 before 15.2.3, all versions starting from 15.3 before 15.3.1 allowed an attacker to trigger high CPU usage via a special crafted input added in the Commit message field.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab CE/EE 10.7–15.3.0 vulnerable to ReDoS via crafted commit message, causing high CPU usage.
Vulnerability
A regular expression denial-of-service (ReDoS) vulnerability exists in commit_trailers_filter.rb in GitLab Community Edition and Enterprise Edition starting from version 10.7 before 15.1.5, all versions from 15.2 before 15.2.3, and all versions from 15.3 before 15.3.1. The bug allows an attacker to trigger excessive CPU consumption by submitting a specially crafted commit message containing a backtracking regex pattern.
Exploitation
An attacker must have an authenticated GitLab account and write access to a project (or create a new public project) to commit a file. The attacker adds a file with any content and sets the commit message to the ReDoS payload. The target branch name must be set to redos (or any branch that will later be visited). The malicious commit message is stored server-side. When any user—including the attacker—navigates to the project's commit list page for that branch (e.g., GET /[PROJECT_NAMESPACE]/-/commits/[BRANCH]), the server processes the commit trailers and triggers the regex backtracking, causing one CPU core to reach 100% usage for up to 60 seconds [1]. The stored nature allows the attacker to craft a CSRF to a GET endpoint, forcing other users to trigger the DoS.
Impact
An attacker can cause sustained high CPU usage on the GitLab server, exhausting one CPU core per request and potentially degrading service availability (denial of service). No data compromise or privilege escalation is achieved; the impact is limited to availability.
Mitigation
The vulnerability is fixed in GitLab versions 15.1.5, 15.2.3, and 15.3.1 [1]. Users should upgrade to one of these patched versions. No workaround is available; the fix addresses the regex in commit_trailers_filter.rb to eliminate catastrophic backtracking. The issue is not listed in CISA KEV.
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: >=10.7 <15.1.5, >=15.2 <15.2.3, >=15.3 <15.3.1
- Range: >=10.7, <15.1.5
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Catastrophic backtracking in the regex FILTER_REGEXP within commit_trailers_filter.rb causes excessive CPU consumption when processing a crafted commit message."
Attack vector
An attacker with commit access to a public project creates a commit whose message contains a specially crafted string that triggers catastrophic backtracking in the FILTER_REGEXP defined in `commit_trailers_filter.rb` [ref_id=1]. When any user (including unauthenticated users) sends a GET request to the project's commits page for the branch containing that commit, the server-side regex engine enters exponential backtracking, consuming 100% of one CPU core per request for up to 60 seconds [ref_id=1]. The attacker can further weaponize this as a stored ReDoS by embedding an `<img>` tag pointing to the vulnerable URL in any markdown field (e.g., an Issue description), causing victims who view that markdown to trigger the DoS via CSRF [ref_id=1].
Affected code
The vulnerable code is in `lib/banzai/filter/commit_trailers_filter.rb` at lines 20–27 (as of v15.0.0-ee) [ref_id=1]. The FILTER_REGEXP combines TRAILER_REGEXP, AUTHOR_REGEXP (`(?<author_name>.+)`), and MAIL_REGEXP in a pattern that causes catastrophic backtracking when matching crafted commit messages [ref_id=1].
What the fix does
The advisory does not include a patch diff, but the expected fix is to rewrite the FILTER_REGEXP so that it no longer permits catastrophic backtracking [ref_id=1]. The dangerous portion is the combination of AUTHOR_REGEXP (`(?<author_name>.+)`) with surrounding `\s*` and `\s+` quantifiers, which allows the regex engine to try an exponential number of ways to match whitespace and characters against crafted input [ref_id=1]. The remediation should anchor or atomic-group the sub-expressions to eliminate the backtracking explosion.
Preconditions
- authAttacker must have commit access to a public project on the GitLab instance
- inputThe crafted commit message must be committed to a branch
- networkA victim (or the attacker) must send a GET request to the project's commits page for that branch
Reproduction
1. Sign in to the GitLab instance and create a new public project. 2. Create a new file with a commit message containing the ReDoS payload from `commit_trailers_ReDoS_payload.txt` and target branch `redos`. 3. Commit the file and observe CPU usage spike to 100% on the server. 4. Navigate to the project's Repository > Commits page and select the `redos` branch to confirm the stored ReDoS triggers on GET requests. 5. Optionally, embed `<img src="[STORED_REDOS_URL]">` in any markdown field (e.g., an Issue description) to create a CSRF-to-stored-ReDoS vector [ref_id=1].
Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3News mentions
0No linked articles in our index yet.