CVE-2020-13349
Description
An issue has been discovered in GitLab EE affecting all versions starting from 8.12. A regular expression related to a file path resulted in the Advanced Search feature susceptible to catastrophic backtracking. Affected versions are >=8.12, <13.3.9,>=13.4, <13.4.5,>=13.5, <13.5.2.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab EE Advanced Search is vulnerable to ReDoS via a crafted file name causing catastrophic backtracking.
Vulnerability
GitLab EE versions 8.12 through 13.3.8, 13.4.0 through 13.4.4, and 13.5.0 through 13.5.1 contain a regular expression denial-of-service (ReDoS) vulnerability in the Advanced Search (Elasticsearch) feature [1]. The issue exists in ee/lib/gitlab/elastic/search_results.rb where the method parse_search_result constructs a regular expression to strip the file extension from a search result's path: basename = path.sub(/#{extname}$/, ''). Since the file name is user-controlled via repository content, an attacker can craft a file with a name containing a pattern that causes catastrophic backtracking when the regex engine processes the substitution [1].
Exploitation
An attacker must have the ability to create files in a GitLab project that is indexed by Elasticsearch. The Elasticsearch integration must be enabled for the instance or group [1]. The attacker creates a file with a name designed to trigger catastrophic backtracking, such as aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab.(a+)+$ and containing a searchable keyword (e.g., SEARCH_ME_REGEX_DOS_ISSUE) [1]. When a user (or the attacker) performs a search for that keyword, the Advanced Search returns the file as a result, and the regex substitution processes the malicious file name, consuming excessive CPU time and causing the request to time out or crash [1].
Impact
Successful exploitation results in a denial-of-service condition. The GitLab process handling the search request may consume 100% CPU, causing timeouts and potential cascading failures across other requests [1]. Repeated exploitation could degrade overall instance availability. The vulnerability does not allow data access, modification, or privilege escalation; the impact is limited to service disruption.
Mitigation
The vulnerability is fixed in GitLab EE versions 13.3.9, 13.4.5, and 13.5.2 [1]. Users should upgrade to one of these patched versions or later. There is no known workaround; disabling Elasticsearch would prevent exploitation but also disable Advanced Search functionality. The issue is not listed on CISA's KEV as of the publication date [1].
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: >=8.12, <13.3.9, >=13.4, <13.4.5, >=13.5, <13.5.2
- Range: >=8.12
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"User-controlled file path data is interpolated into a regular expression without escaping, enabling catastrophic backtracking."
Attack vector
An attacker must have access to a GitLab instance with Elasticsearch integration enabled. The attacker creates a file whose name contains a crafted extension designed to cause catastrophic backtracking, such as `aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab.(a+)+$`. When a search query matches the file's content, GitLab's `parse_search_result` method constructs a regex from the file's extension and applies it to the full path. The regex engine enters catastrophic backtracking, consuming 100% CPU and causing the request to time out with a 500 error [ref_id=1]. Repeated requests can degrade or deny service.
Affected code
The vulnerable code is in `ee/lib/gitlab/elastic/search_results.rb` at the `parse_search_result` method (line 121 of the referenced commit). The method constructs a regular expression from user-controlled file path data: `path.sub(/#{extname}$/, '')`, where `extname` is derived from `File.extname(path)` and the path originates from Elasticsearch search results [ref_id=1].
What the fix does
The patch replaces the regex-based extension stripping with safe file-path operations: `File.join(File.dirname(path), File.basename(path, File.extname(path)))`. This avoids constructing any regular expression from user-controlled input, eliminating the possibility of catastrophic backtracking. The advisory also notes that if a regex approach were required, `Regexp.escape(extname)` should be used to escape the extension string before interpolation [ref_id=1].
Preconditions
- configElasticsearch integration must be enabled on the GitLab instance
- inputAttacker must be able to create files in a project with a crafted filename
- inputAttacker must be able to perform a search that matches the crafted file's content
Reproduction
1. Enable Elasticsearch integration on the GitLab instance. 2. Create a project. 3. Create a file named `aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab.(a+)+$` with content `SEARCH_ME_REGEX_DOS_ISSUE`. 4. Search for `SEARCH_ME_REGEX_DOS_ISSUE`. 5. The request times out and fails with a 500 error, and the process uses 100% CPU [ref_id=1].
Generated on May 25, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2- gitlab.com/gitlab-org/cves/-/blob/master/2020/CVE-2020-13349.jsonmitrex_refsource_CONFIRM
- gitlab.com/gitlab-org/gitlab/-/issues/257497mitrex_refsource_MISC
News mentions
0No linked articles in our index yet.