In June 2022, a dangerous vulnerability—CVE-2022-2992—was discovered in GitLab CE/EE. This issue affected all versions from 11.10 up to 15.1.6, as well as 15.2 to 15.2.4 and 15.3 to 15.3.2. What made this bug alarming is that it allowed any authenticated user (even those with basic permissions) to achieve remote code execution (RCE) on the server—just by using the “Import from GitHub” API.

Let’s break down how this vulnerability worked, examine the code, and see how an attacker could exploit it.

What Happened: Quick Summary

GitLab has an “Import Project from GitHub” feature, which lets users pull in their GitHub projects easily. But in the affected versions, GitLab didn’t sanitize some of the user-supplied data correctly in this import process. This security mistake enabled attackers to pass in dangerous commands via the API and get them executed (with the privileges of the web service user) on the GitLab server.

Vulnerability introduction: Affected versions from 11.10

- Vulnerability reported/fixed: June 2022
- GitLab Advisory: Critical Security Release: 15.3.2, 15.2.4, 15.1.6
- CVE Details: NVD - CVE-2022-2992

Vulnerable Code Walkthrough

While the official patch doesn’t reveal the exact lines for security reasons, the root issue was found in the GitHub import controller (app/services/import/github_service.rb). The API endpoint accepted a JSON payload about the project to import. Among its fields, certain values (like project names, descriptions, etc.) were not correctly sanitized before being used in shell commands during the import.

A simplified scenario might look like this

# Pseudocode
def import_from_github
  project_name = params[:name]
  system("git clone https://github.com/#{project_name}.git";)
end


If project_name contains shell metacharacters, like "my-repo; evil-command;", the system call would execute evil-command on the server.

Exploit Example

Assuming the API accepts JSON via the endpoint /import/github, let’s exploit it.

- Payload: Use the API to “import a repository” but slip in a malicious value

curl -s -X POST \
  -H "PRIVATE-TOKEN: <your-token>" \
  -H "Content-Type: application/json" \
  --data '{"personal_access_token":"<github-token>","repo_id":"testrepo; touch /tmp/pwned; #"}' \
  https://gitlab.example.com/api/v4/import/github

Here, repo_id contains “testrepo; touch /tmp/pwned; #” instead of a simple repository name.

- Result: If vulnerable, the GitLab server creates an empty file /tmp/pwned, proving remote command execution.

Anyone with an account could exploit it—no admin rights needed.

- Full control of the server: Attackers could install malware, open backdoors, or steal source code.
- Widespread deployment: Many companies use GitLab CI/CD for private code. If an attacker got in, all your code secrets were at risk.

Restricting what values could be passed to the import commands.

Patch commit (for reference):  
Visit GitLab's source with the fix (not direct source for security, but for context).

Am I Affected? What Should I Do?

- If you run GitLab CE/EE: Any version from 11.10 up to (but not including) 15.1.6, 15.2.4, or 15.3.2.

Conclusion

CVE-2022-2992 is a classic example of how insecure input handling—even in trusted features—can put your server at risk. This bug in GitLab’s “Import from GitHub” API allowed regular users to run commands on your server, turning a helpful feature into a security disaster. The fix is simple: update your GitLab, and always treat user input as hostile.

References  
- GitLab Critical Security Advisory
- NVD Details for CVE-2022-2992  
- Patch Commit

Timeline

Published on: 10/17/2022 16:15:00 UTC
Last modified on: 10/28/2022 20:09:00 UTC