GHSA-WJXP-XRPV-XPFF
Vulnerability from github – Published: 2026-04-21 18:52 – Updated: 2026-05-21 21:18Summary
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:
-
getSCMTypeAndServerURL()readsserverURLdirectly from user params (params[ServerURLParam]) with no validation against the system-configured URL. -
secretRefis set tonilbecause the user did not provide a token parameter. -
getAPIToken(ctx, nil, APISecretNameKey)is called. It detectsapiSecret == nil, creates a newsecretCacheKey, and populates it from the system-configured secret (conf.APISecretName/conf.APISecretNamespace/SYSTEM_NAMESPACE). -
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 anAuthorizationheader on the HTTP client. -
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
Fixed in:
- v1.0.2 (release-v1.0.x branch)
- v1.3.4 (release-v1.3.x branch)
- v1.6.2 (release-v1.6.x branch)
- v1.9.3 (release-v1.9.x branch)
- v1.11.1 (release-v1.11.x branch)
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
tokenparameter. - Restrict TaskRun creation — limit which users or ServiceAccounts can create TaskRuns and PipelineRuns that use the git resolver.
- Network egress policies — apply
NetworkPolicyto thetekton-pipelines-resolversnamespace 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)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/tektoncd/pipeline"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/tektoncd/pipeline"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0"
},
{
"fixed": "1.3.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/tektoncd/pipeline"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.0"
},
{
"fixed": "1.6.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/tektoncd/pipeline"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0"
},
{
"fixed": "1.9.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/tektoncd/pipeline"
},
"ranges": [
{
"events": [
{
"introduced": "1.10.0"
},
{
"fixed": "1.11.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40161"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-21T18:52:18Z",
"nvd_published_at": "2026-04-21T17:16:53Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe 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.\n\n### Details\n\nThe git resolver\u0027s `ResolveAPIGit()` function in `pkg/resolution/resolver/git/resolver.go` constructs an SCM client using the user-supplied `serverURL` and a token obtained via `getAPIToken()`.\n\nWhen the user provides `serverURL` but omits the `token` parameter:\n\n1. `getSCMTypeAndServerURL()` reads `serverURL` directly from user params (`params[ServerURLParam]`) with no validation against the system-configured URL.\n\n2. `secretRef` is set to `nil` because the user did not provide a token parameter.\n\n3. `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`).\n\n4. `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.\n\n5. All subsequent API calls (`Contents.Find`, `Git.FindCommit`) carry the system token to the attacker URL.\n\n### Impact\n\nThe 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.\n\nThis 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\u0027s ServiceAccount token via path traversal. This finding involves redirecting the system Git API token via `serverURL`.\n\n### Patches\n\nFixed in:\n\n- v1.0.2 (release-v1.0.x branch)\n- v1.3.4 (release-v1.3.x branch)\n- v1.6.2 (release-v1.6.x branch)\n- v1.9.3 (release-v1.9.x branch)\n- v1.11.1 (release-v1.11.x branch)\n\nThe 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.\n\n### Workarounds\n\n- **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.\n- **Restrict TaskRun creation** \u2014 limit which users or ServiceAccounts can create TaskRuns and PipelineRuns that use the git resolver.\n- **Network egress policies** \u2014 apply `NetworkPolicy` to the `tekton-pipelines-resolvers` namespace to restrict outbound traffic to known-good Git servers only.\n\n### Affected Versions\n\nAll 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.\n\nReleases prior to v1.0.0 are not affected because the git resolver either did not exist or did not have API mode.\n\n### Acknowledgments\n\nThis vulnerability was reported by Koda Reef (@kodareef5), who provided a detailed analysis and proof-of-concept. Thank you!\n\n### References\n\n- Prior advisory: [GHSA-j5q5-j9gm-2w5c](https://github.com/tektoncd/pipeline/security/advisories/GHSA-j5q5-j9gm-2w5c)\n- Related: #9608 (deprecate `api-token-secret-namespace`)\n- Related: #9609 (SubjectAccessReview for resolver secrets)",
"id": "GHSA-wjxp-xrpv-xpff",
"modified": "2026-05-21T21:18:57Z",
"published": "2026-04-21T18:52:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tektoncd/pipeline/security/advisories/GHSA-wjxp-xrpv-xpff"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40161"
},
{
"type": "WEB",
"url": "https://github.com/tektoncd/pipeline/issues/9608"
},
{
"type": "WEB",
"url": "https://github.com/tektoncd/pipeline/issues/9609"
},
{
"type": "PACKAGE",
"url": "https://github.com/tektoncd/pipeline"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Tekton Pipelines: Git resolver API mode leaks system-configured API token to user-controlled serverURL"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.