CVE-2026-54168 in Pipelines-as-Code
Summary
by MITRE • 09/15/2026
Pipelines-as-Code is a CI/CD system that lets users define Tekton pipelines in source code repositories. Prior to 0.37.8, 0.39.6, 0.42.1, and 0.48.0, a GitHub App installation token created during webhook processing is not scoped to the repository that triggered the event when the App is installed across multiple repositories. A user with push access to one repository can submit a PipelineRun containing a pipelinesascode.tekton.dev/task remote task annotation that targets a private repository in the same installation. When ScopeTokenToListOfRepos returns no explicit scope, the missing triggering repository ID leaves the token able to access the entire installation. Pipelines-as-Code resolves and inlines the remote private task with that token, disclosing the repository's Tekton definitions. The demonstrated impact is read-only and does not provide write access. This issue is fixed in versions 0.37.8, 0.39.6, 0.42.1, and 0.48.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/15/2026
Pipelines-as-Code functions as a CI/CD framework that enables users to define Tekton pipelines directly within source code repositories using declarative configuration files. This system integrates with GitHub webhooks to automate the execution of these pipelines based on repository events such as pull requests or pushes. The security architecture relies heavily on scoped authentication tokens generated during webhook processing to ensure that automated processes operate only within the boundaries of the triggering repository. However, a critical flaw existed in versions prior to 0.37.8, 0.39.6, 0.42.1, and 0.48.0 regarding how these tokens were scoped when the GitHub App was installed across multiple repositories within an organization or account.
The core technical vulnerability stems from a failure in token scoping logic during webhook event handling. When a user with push access to one repository triggers a pipeline execution, the system is supposed to generate a temporary authentication token restricted specifically to that triggering repository. In vulnerable versions, if the GitHub App installation covers multiple repositories and no explicit scope is defined for the specific triggering repository ID, the resulting ScopeTokenToListOfRepos function fails to restrict permissions appropriately. Consequently, the generated token retains access rights across the entire installation rather than being limited to the single source of the event. This oversight allows any user with push privileges in one public or accessible repository to leverage this overly permissive token for operations targeting other private repositories within the same GitHub App installation scope.
The operational impact involves an unauthorized read-only disclosure of sensitive CI/CD configuration data from private repositories. An attacker can submit a PipelineRun that includes a remote task annotation pointing to a Tekton Task stored in a different, private repository under the same organization or account. Because the token used for this operation is not properly scoped, it successfully authenticates against the target private repository and retrieves its contents. This allows the attacker to read the internal pipeline definitions, which may contain sensitive information such as hardcoded credentials, API keys, infrastructure details, or proprietary build logic. While the vulnerability does not grant write access or allow direct code execution on the target repositories, the exposure of these technical artifacts can facilitate further reconnaissance and potentially aid in crafting more sophisticated attacks against the CI/CD pipeline itself.
This issue aligns with CWE-284 Improper Access Control, specifically reflecting a failure to enforce proper authorization boundaries between distinct resources within an application environment. From an ATT&CK perspective, this vulnerability facilitates Discovery techniques where adversaries gather information about the target organization's infrastructure and security controls by accessing sensitive configuration files that were intended to be private. The lack of strict scoping allows lateral movement in terms of data access across repository boundaries without requiring additional authentication steps or privilege escalation exploits.
To mitigate this risk, organizations must upgrade Pipelines-as-Code to version 0.37.8, 0.39.6, 0.42.1, or 0.48.0 and later, where the token scoping logic has been corrected to ensure that generated tokens are strictly limited to the repository that triggered the webhook event. Additionally, administrators should review GitHub App permissions and installation scopes to minimize the blast radius in case of future vulnerabilities. Implementing strict least-privilege principles for CI/CD service accounts and regularly auditing pipeline definitions for exposed secrets can further reduce the potential impact of such access control failures.