CVE Alert: CVE-2026-50240 – Red Hat

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.

**Risk verdict:** Treat this as a high-priority namespace privilege-escalation risk; KEV, SSVC exploitation, PoC and EPSS data were not provided, so active-exploitation urgency cannot be confirmed.

**Why this matters:** An attacker with limited access in a CI/CD namespace could run their own pipeline with the pipeline ServiceAccount’s broader permissions. That can expose namespace secrets, alter workloads or inject changes into build and deployment processes, potentially compromising downstream software or credentials.

**Most likely attack path:** The attacker needs network access and low-level privileges to create and delete Repository and Secret resources, but no user interaction or complex conditions. PAC can then execute an attacker-controlled PipelineRun with the auto-provisioned ServiceAccount. Scope is unchanged, so direct impact is namespace-bound; stolen credentials or poisoned build outputs could enable further compromise.

**Who is most exposed:** OpenShift environments using Pipelines-as-Code and auto-provisioned pipeline ServiceAccounts are most at risk, especially shared clusters where namespace users can create Repository resources.

Correlate Repository creation with unexpected PipelineRun creation or execution.

Review audit events for PipelineRuns started by PAC and identify their initiators.

Check pipeline logs and namespace audit trails for unusual Secret reads or resource changes.

Mitigation and prioritisation:

Apply the vendor’s fixed update promptly; confirm the applicable release with the vendor.

As a workaround, set `legacyPipelineRbac` to `false`; assess pipeline permission dependencies first.

Do not rely on deleting the RoleBinding alone; operator reconciliation may restore it.

Restrict Repository and Secret creation permissions, and review existing namespace access.

Validate pipeline behaviour after changes, then review for prior secret access or workload modification.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.