CVE-2022-2884
Description
A vulnerability in GitLab CE/EE affecting all versions from 11.3.4 prior to 15.1.5, 15.2 to 15.2.3, 15.3 to 15.3 to 15.3.1 allows an an authenticated user to achieve remote code execution via the Import from GitHub API endpoint
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Authenticated user can achieve remote code execution via crafted GitHub import using Sawyer resource injection in GitLab CE/EE versions 11.3.4 to 15.3.1.
Vulnerability
The vulnerability resides in GitLab's Import from GitHub API endpoint, specifically in the use of the Octokit library and Sawyer::Resource to represent GitHub API responses. Sawyer::Resource converts hash keys into methods, allowing an attacker to control the id field of the returned object. In affected versions (all 11.3.4 to 15.1.5, 15.2 to 15.2.3, 15.3 to 15.3.1), GitLab passes this id directly into a Redis cache set operation without sanitization, enabling injection of arbitrary Redis commands via a crafted id hash containing to_s and bytesize keys [1].
Exploitation
An authenticated attacker must initiate a GitHub import and control the API response from GitHub. This can be achieved by hosting a malicious repository on GitHub or using a proxy that manipulates the JSON response. The attacker crafts the repository's id field as a hash, e.g., {"to_s": {"bytesize": 2, "to_s": "1234REDIS_COMMANDS"}}. When GitLab processes this response, the bytesize value restricts the length of previous Redis commands, allowing the injection of additional Redis commands. This can be used to write arbitrary data to Redis, leading to remote code execution on the GitLab server [1].
Impact
Successful exploitation results in remote code execution as the GitLab application user. The attacker can fully compromise the GitLab instance, potentially gaining access to sensitive data, modifying repositories, or pivoting to other systems. The impact is high, with CVSS score 8.8 for this vulnerability.
Mitigation
GitLab released fixes in versions 15.1.5, 15.2.3, and 15.3.1, published on 2022-10-17. Users running affected versions should upgrade immediately. No workarounds have been provided, and the vulnerability is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog as of this writing [1].
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: >=11.3.4, <15.1.5, >=15.2, <15.2.3, >=15.3, <15.3.1
- Range: >=11.3.4, <15.1.5
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"The GitHub import endpoint uses Octokit/Sawyer::Resource, which converts arbitrary JSON hash keys into Ruby object methods, allowing an attacker to inject malicious Redis commands via a crafted GitHub API response."
Attack vector
An authenticated attacker calls the POST /api/v4/import/github endpoint [ref_id=1], supplying a malicious github_hostname pointing to a server they control. That server returns a crafted GitHub API response where the id field is a hash containing to_s and bytesize keys. GitLab's parallel_scheduling.rb passes this object to Redis command construction, where bytesize truncates the prior Redis command and injects arbitrary Redis commands [ref_id=1]. The attacker can then use Redis gadgets (e.g., lpush to Sidekiq queues) to achieve remote code execution on the GitLab server [ref_id=1].
Affected code
The vulnerability lies in lib/gitlab/github_import/parallel_scheduling.rb, specifically the already_imported? method which calls id_for_already_imported_cache(object) and passes the result to Redis caching [ref_id=1]. The id value originates from a Sawyer::Resource object that dynamically creates methods from JSON hash keys, allowing an attacker-controlled hash to inject Redis commands via the bytesize key [ref_id=1].
What the fix does
No patch is included in the bundle. The advisory [ref_id=1] describes the vulnerability but does not provide a diff. The remediation would require sanitizing the Sawyer::Resource response to ensure id and other fields are plain scalar types (e.g., integers or strings) rather than hashes, preventing Redis command injection via bytesize manipulation. GitLab addressed this in versions 15.1.5, 15.2.3, and 15.3.1.
Preconditions
- authAttacker must have a valid GitLab personal access token with api scope
- networkAttacker must control a server reachable from the GitLab instance to serve a crafted GitHub API response
- configGitLab instance must be running a version between 11.3.4 and 15.1.5, 15.2 to 15.2.3, or 15.3 to 15.3.1
Reproduction
1. Set up a dummy server (e.g., Node.js) on a machine reachable from the GitLab instance, serving a crafted GitHub API response that returns a malicious id hash (e.g., {"to_s": {"bytesize": 2, "to_s": "1234REDIS_COMMANDS"}}). 2. Create a GitLab personal access token with the api scope. 3. Send a POST request to /api/v4/import/github with the attacker's server as github_hostname, a valid personal_access_token, repo_id, and target_namespace. 4. The injected Redis commands execute, e.g., lpush resque:gitlab:queue:system_hook_push with a serialized Sidekiq job payload to achieve RCE [ref_id=1].
Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
4News mentions
0No linked articles in our index yet.