GHSA-6f2p-296r-cc28: Medium severity go/github.com/openshift-pipelines/pipelines-as-code vulnerability
Impact When Pipelines-as-Code is configured with a GitHub App installed across multiple repositories, the installation token issued during webhook processing is not scoped to the triggering repository by default. The token retains access to all repositories in the GitHub App installation.
This allows a user with push access to any repository in the installation to craft a PipelineRun with a remote task annotation pointing at a private repository in the same installation: pipelinesascode.tekton.dev/task: "https://github.com/org/private-repo/blob/main/.tekton/secret-task.yaml" Pipelines-as-Code resolves and inlines the remote task using the unscoped token, exposing the contents of the private repository's Tekton definitions. This is a read-only confidentiality breach, no write access is exposed.
Patches The fix extracts the repository ID from the webhook payload during initial parsing so that it is available for later use. It then adds a fallback in the client setup path so that when no explicit scoping configuration is present and ScopeTokenToListOfRepos returns empty, the token is re-issued scoped to the triggering repository's ID rather than retaining access to the entire installation. The initial token remains unscoped so that the extra-repos lookup can still discover and resolve additional repositories when configured.
The fix is available in v0.48.0. Supported backport releases will be added here after release tags are published.
Workarounds Limit the GitHub App installation to only the repositories that require Pipelines-as-Code. Avoid org-wide installations or mixed-trust installations where repositories with different access requirements share the same GitHub App. This restricts the blast radius of the unscoped token to only the repositories that are explicitly selected during App installation.
Credits Reported and fixed by the Pipelines-as-Code maintainers.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/openshift-pipelines/pipelines-as-codeto a version that resolves this vulnerability.Fixed in 0.48.0 - Upgrade
Upgrade
go/github.com/openshift-pipelines/pipelines-as-codeto a version that resolves this vulnerability.Fixed in 0.42.1 - Upgrade
Upgrade
go/github.com/openshift-pipelines/pipelines-as-codeto a version that resolves this vulnerability.Fixed in 0.39.6 - Upgrade
Upgrade
go/github.com/openshift-pipelines/pipelines-as-codeto a version that resolves this vulnerability.Fixed in 0.37.8 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in v0.48.0 - Compensating control
Avoid org-wide installations or mixed-trust installations where GitHub App repositories with different access requirements share the same GitHub App.
- Compensating control
Limit the GitHub App installation to only the repositories that require Pipelines-as-Code.
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments using Pipelines-as-Code with a GitHub App installation that spans multiple repositories are exposed when webhook processing uses an installation token that is not explicitly scoped to repositories. The token is unscoped by default in the affected behavior.
What does an attacker need to exploit this?
An attacker needs push access to any repository covered by the same GitHub App installation. They can submit a PipelineRun that references a remote task in another private repository within that installation.
What can be disclosed through exploitation?
The attacker can cause Pipelines-as-Code to resolve and inline a remote Tekton task using the installation token, exposing the contents of private repositories' Tekton definitions. The described impact is read-only confidentiality loss; it does not provide write access.
What changes in the fix?
The fix obtains the triggering repository ID from the webhook payload and reissues the token scoped to that repository when explicit scoping is absent and the configured repository list is empty. This prevents a webhook from one repository from using a token that retains access to every repository in the installation.