Tekton Pipelines project provides k8s-style resources for declaring CI/CD-style pipelines. From 1.0.0 to before 1.11.0, 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. This vulnerability is fixed in 1.11.1.

A flaw was found in the OpenShift Pipelines operator (tektoncd/operator). The operator ships a ClusterRoleBinding (tekton-scheduler-rolebinding) that binds ClusterRole/tekton-scheduler-role to the system:authenticated group, granting all authenticated users cluster-wide create/update/patch/delete permissions on kueue.x-k8s.io resources (ResourceFlavor, Workload, WorkloadPriorityClass) and create/update permissions on cert-manager.io resources (Certificate, Issuer). When Kueue CRDs are present (e.g., via RHOAI), any authenticated user can disrupt cross-tenant workload scheduling by deleting ResourceFlavors, destroy other tenants' Workload objects, or tamper with scheduling priority. When cert-manager is installed, any authenticated user can create Certificate objects targeting arbitrary Secrets, including the default ingress controller's TLS Secret (openshift-ingress/router-certs-default), causing cert-manager to overwrite it with an attacker-influenced certificate. This confused deputy attack crosses authorization boundaries — the attacker cannot write Secrets directly but leverages cert-manager's ServiceAccount to do so. The RBAC objects are installed unconditionally even when the Tekton Scheduler feature is disabled.

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

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)

Tekton Pipelines project provides k8s-style resources for declaring CI/CD-style pipelines. Starting in version 1.0.0 and prior to versions 1.0.1, 1.3.3, 1.6.1, 1.9.2, and 1.10.2, 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. Versions 1.0.1, 1.3.3, 1.6.1, 1.9.2, and 1.10.2 contain a patch.