CVE-2026-50240: Pipelines-as-code: openshift-pipelines-operator-rh: pipelines-as-code: repository users can trigger namespace edit-equivalent execution via auto-provisioned pipeline serviceaccount
A flaw was found in OpenShift Pipelines-as-Code (PAC). PAC does not verify whether the creator of a Repository custom resource has permission to create PipelineRuns. A namespace user with only Repository and Secret create/delete permissions can cause PAC to execute attacker-controlled PipelineRuns as the auto-provisioned pipeline ServiceAccount, which carries ClusterRole/edit by default. This results in namespace-scoped privilege escalation, enabling Secret read, resource creation/modification/deletion, and potential supply chain injection in CI/CD namespaces.
Event History
Frequently Asked Questions
Who can exploit this issue?
A user in a namespace who can create and delete Repository and Secret custom resources can exploit it, even if they do not have permission to create PipelineRuns. The resulting access is limited to the affected namespace, but can include reading Secrets and creating, modifying, or deleting namespace resources.
Is the default PAC service account configuration affected?
Yes. The auto-provisioned pipeline ServiceAccount carries the ClusterRole/edit role by default, which provides the elevated namespace-level permissions used in this escalation.
What does an attacker need to do to trigger the elevated execution?
The attacker needs to create a Repository custom resource and provide attacker-controlled PipelineRun content. PAC can then execute that PipelineRun using the auto-provisioned pipeline ServiceAccount rather than enforcing the Repository creator's PipelineRun permissions.
What are the likely impacts in a CI/CD namespace?
An attacker can read Secrets and create, change, or delete namespace-scoped resources through the pipeline ServiceAccount. This can also enable supply-chain injection in CI/CD namespaces.