Prevent path traversal in git resolver pathInRepo parameter
fix: prevent path traversal in git resolver pathInRepo parameter
Prevent path traversal in git resolver pathInRepo parameterb1fee6-fix-prevent-path-traversal-in-git-resolver-cve-2026-33211fixprevent path traversal git resolver pathinrepo
Committed by vdemeester
commit message
fix: prevent path traversal in git resolver pathInRepo parameter
The git resolver's pathInRepo parameter was not validated for path
traversal, allowing a tenant to read arbitrary files from the resolver
pod's filesystem by supplying paths like '../../../../etc/passwd' or
'../../../../var/run/secrets/kubernetes.io/serviceaccount/token'.
The resolved file contents were then written into
resolutionrequest.status.data (base64-encoded), creating an
exfiltration channel. Since the resolver pod's ServiceAccount typically
has broad RBAC permissions (including read access to secrets), this
could lead to full privilege escalation.
The fix adds two layers of defense:
1. Validate pathInRepo in PopulateDefaultParams() to reject paths
containing '..' components. Leading slashes are stripped for
backwards compatibility (filepath.Join already handles them safely).
2. Switch getFileContent() to use 'git show HEAD:<path>' to read files
from git's object store instead of os.ReadFile from the filesystem.
Symlinks are resolved via filepath.EvalSymlinks before computing the
relative path for git show, so in-repo symlinks work correctly while
escape symlinks produce paths that git show rejects.
Unit and e2e regression tests are added for traversal patterns,
symlink escapes, and valid leading-slash paths.
The vulnerability was introduced in commit 318006c4e3a5 when the git
resolver switched from go-git's in-memory filesystem (memfs) to
shelling out to git and reading files with os.ReadFile(). All releases
from v1.0.0 through v1.10.0 are affected.
Fixes: GHSA-j5q5-j9gm-2w5cEditor assessment
This commit patches CVE-2026-33211. What distinguishes this message is that it does not merely say the parameter is now validated; it explains why the previous code was exploitable and what a reader should check. Tenant-supplied paths with repeated parent-directory segments could read arbitrary resolver-pod files, and because the contents were base64-written into resolutionrequest status, the read became an exfiltration channel under a service account with broad RBAC. The two-layer fix is justified, including compatibility handling for leading slashes and symlink resolution for in-repo links. Tests, the introducing commit 318006c4e3a5, the affected releases and a proper Fixes footer are all present.