Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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: execGit invokes exec.CommandContext("git", ...) — no shell is used, so shell metacharacters cannot be injected. However, git itself parses flags…
Recommended action: Upgrade to 1.11.1, 1.9.3, 1.6.2 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: makeHttpClient sets http.Client{Timeout: timeout} where timeout defaults to 1 minute and is configurable via fetch-timeout in the http-resolver-config ConfigMap.…
Recommended action: Upgrade to 1.11.1, 1.9.3, 1.6.2 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/containervalidation.go checks mount paths using strings.HasPrefix without normalizing the path first: 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/taskvalidation.go. Impact An authenticated user with Task or TaskRun creation permissions can mount volumes over…
Recommended action: Upgrade to 1.11.1, 1.9.3, 1.6.2 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.11.1, 1.9.3, 1.6.2 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
hey guys, triage contract this is a first-screen summary; deterministic proof is in the proof bundle (canonical.log/control.log/witness.txt). summary trusted resources verification policies match a resource source string (refSource.URI) against spec.resources[].pattern using regexp.MatchString. in go, regexp.MatchString reports a match if the pattern matches anywhere in the string, so common unanchored patterns (including examples in tekton documentation) can be bypassed by attacker-controlled source strings that contain the trusted pattern as a substring. this can cause an unintended policy match and change which verification mode/keys apply. pins - repo: https://github.com/tektoncd/pipeline - commit: 0133513db03dadb3cb08801d6b0330badcb63830 - callsite: pkg/trustedresources/verify.go:118-137 (getMatchedPolicies) severity MEDIUM (provisional CVSS 5.3–6.5) (signing request tampering) repro (canonical) - command: unzip -q -o poc.zip -d poc && cd poc/poc-F-TEKTON-REGEX-001 && make…
Recommended action: Upgrade to 1.11.1, 1.9.3, 1.6.2 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Tekton Pipelines git resolver is vulnerable to path traversal via the pathInRepo parameter. A tenant with permission to create ResolutionRequests (e.g. by creating TaskRuns or PipelineRuns that use the git resolver) can read arbitrary files from the resolver pod's filesystem, including ServiceAccount tokens. The file contents are returned base64-encoded in resolutionrequest.status.data. Details The git resolver's getFileContent() function in pkg/resolution/resolver/git/repository.go constructs a file path by joining the repository clone directory with the user-supplied pathInRepo parameter: The pathInRepo parameter is not validated for path traversal sequences. An attacker can supply values like ../../../../etc/passwd to escape the cloned repository directory and read arbitrary files from the resolver pod's filesystem. The vulnerability was introduced in commit 318006c4e3a5 which switched the git resolver from the go-git library (using an in-memory filesystem that cannot…
Recommended action: Upgrade to 1.10.2, 1.9.2, 1.6.1 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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…
Recommended action: Upgrade to 1.10.2, 1.9.2, 1.6.1 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.