CVE-2022-3067
Description
An issue has been discovered in the Import functionality of GitLab CE/EE affecting all versions starting from 14.4 before 15.2.5, all versions starting from 15.3 before 15.3.4, all versions starting from 15.4 before 15.4.1. It was possible for an authenticated user to read arbitrary projects' content given the project's ID.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Authenticated GitLab users could read arbitrary projects' content via BulkImports by supplying a file:// URL to access local repositories.
Vulnerability
The Import functionality in GitLab CE/EE, specifically the BulkImports repository pipeline, used the httpUrlToRepo field from the client without properly restricting URL schemes. The Gitlab::UrlBlocker.validate! call allowed the file:// scheme, enabling an attacker to specify a local file path as the repository URL. This affects GitLab versions starting from 14.4 before 15.2.5, 15.3 before 15.3.4, and 15.4 before 15.4.1 [1].
Exploitation
An authenticated attacker can initiate a project import and manipulate the httpUrlToRepo response to point to a local repository path on the server (e.g., file:///var/opt/gitlab/git-data/repositories/...). The attacker must know the exact storage path of the target repository, which is based on a configurable storage path and hashed directory structure. No additional privileges beyond authentication are required [1].
Impact
Successful exploitation allows the attacker to read the contents of any project repository stored on the GitLab server by importing it into a project they control. This leads to unauthorized information disclosure of potentially sensitive project data [1].
Mitigation
GitLab has released fixed versions: 15.2.5, 15.3.4, and 15.4.1. Users should upgrade to these or later versions immediately. As a workaround, administrators can disable local requests in the GitLab configuration by setting allow_local_requests_from_web_hooks_and_services to false, which restricts the file scheme in URL validation. However, upgrading is the recommended mitigation [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: >=14.4, <15.2.5; >=15.3, <15.3.4; >=15.4, <15.4.1
- Range: >=15.4, <15.4.1
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing URL scheme restriction in `Gitlab::UrlBlocker.validate!` allows the `file://` protocol to be used in Bulk Import repository fetching, enabling local file access."
Attack vector
An authenticated attacker sets up a malicious Bulk Import server that returns a crafted `httpUrlToRepo` value using the `file://` scheme pointing to a local Git repository path on the GitLab server (e.g., `file://aw.rs/var/opt/gitlab/git-data/repositories/@hashed/...`). The attacker can calculate the hashed storage path for any project ID using `Digest::SHA2.hexdigest(project_id)`. When the victim initiates a Bulk Import from the attacker's server, GitLab's `RepositoryPipeline` fetches the URL, causing it to clone the local repository at that path [ref_id=1].
Affected code
The vulnerability resides in `lib/bulk_imports/projects/pipelines/repository_pipeline.rb`, specifically in the `load` method. The method takes the `httpUrlToRepo` field from the client-supplied data and passes it to `Gitlab::UrlBlocker.validate!` without restricting allowed URL schemes, then uses the URL directly in `project.repository.fetch_as_mirror(url)` [ref_id=1].
What the fix does
The advisory does not include a patch diff, but the expected correct behavior is to restrict allowed URL schemes to only `https`, `git`, and `ssh` when validating the URL in `Gitlab::UrlBlocker.validate!` [ref_id=1]. The fix should add a `schemes` parameter to the validation call to block dangerous protocols like `file://` that allow local file access.
Preconditions
- authAttacker must be an authenticated GitLab user
- networkAttacker must control a Bulk Import server endpoint that returns a malicious httpUrlToRepo
- inputAttacker must know the target project's ID to calculate its hashed storage path
Reproduction
1. Create a private project with User A and note its project ID. 2. Download the `fake_server.py` attachment and edit line 99 to replace the hash path with the SHA2 hash of the target project ID (format: `sha2[0:2]/sha2[2:4]/sha2`). 3. Run the fake server with `FLASK_APP=fake_server.py FLASK_ENV=development flask run`. 4. Start ngrok with `ngrok http 500`. 5. As User B, visit https://gitlab.com/groups/new#import-group-pane, enter the ngrok URL and any token, then click connect. 6. In the browser console, replace `"destination_namespace":"vakzz"` with your username and execute the provided `fetch` call to `/import/bulk_imports.json`. 7. After a few minutes, a new project appears; if it shows "No repository" or "The repository for this project is empty", repeat the fetch call until the victim repository is cloned [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.