Two critical privilege flaws in OpsTree BuildPiper, a platform that builds and deploys applications to Kubernetes, let ordinary authenticated users take control of the clusters it manages. CVE-2026-127073 lets a project user submit unrestricted Kubernetes manifests through the Additional Manifest feature. The pipeline then applies them with cluster-wide credentials, so the user can grant themselves cluster-admin. CVE-2026-127080 lets a deploy user define a hostPath volume that mounts a worker node’s root filesystem read-write, which breaks container isolation.
Both flaws affect BuildPiper versions before 2.7.0 and both are rated 9.9 out of 10 on CVSS v3.1. Neither appears in CISA’s Known Exploited Vulnerabilities catalog as of 13 November 2026, the date the records were retrieved.
What’s affected
Both records list OpsTree Solutions BuildPiper versions before 2.7.0 as affected:
- CVE-2026-127073: privilege escalation through the Additional Manifest feature (CWE-269, improper privilege management). The description says an attacker can deploy a ClusterRoleBinding that binds a service account to cluster-admin. Because BuildPiper applies the manifest with cluster-wide credentials, this gives control over all workloads and secrets in the cluster.
- CVE-2026-127080: improper authorization in the Define HostPath Volume configuration (CWE-269). BuildPiper does not check hostPath volumes against an allow-list or policy. Setting the host path to
/mounts the node’s root filesystem read-write, which can lead to compromise of the node and the cluster.
The affected ranges imply that 2.7.0 is the first unaffected release. However, the advisory data does not yet include a vendor statement confirming a fixed version.
How serious is it
Both CVEs score 9.9 (Critical) with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. In plain terms:
- Network attack, low complexity (AV:N/AC:L): the flaws can be used remotely through normal product features, with no special conditions.
- Low privileges, no user interaction (PR:L/UI:N): the attacker needs only an ordinary BuildPiper account with project or deploy rights. No administrator has to click anything.
- Scope changed (S:C): the impact reaches beyond BuildPiper itself to the Kubernetes clusters and nodes it deploys to.
- High confidentiality, integrity and availability impact (C:H/I:H/A:H): an attacker could read cluster secrets, change or deploy workloads, and disrupt services.
In practice, any insider, contractor or compromised account with basic deploy access could become a full cluster administrator.
Is it being exploited?
Neither CVE is listed in CISA’s Known Exploited Vulnerabilities catalog as of 13 November 2026. The records contain no reports of exploitation in the wild. Researcher write-ups describing both issues are publicly linked from the NVD entries, so administrators should not treat the lack of a KEV listing as a reason to delay.
What to do
- Upgrade: move BuildPiper to version 2.7.0 or later. The records list all earlier versions as affected. Check OpsTree’s own release information to confirm the fix before you roll it out.
- Review who has project and deploy access: until you have upgraded, limit BuildPiper accounts to trusted users and remove unused ones.
- Limit the pipeline’s Kubernetes credentials: where possible, avoid giving BuildPiper cluster-wide or cluster-admin credentials. Scope its service accounts to the namespaces it actually needs.
- Enforce cluster-side policy: use Kubernetes admission controls, such as Pod Security Admission or a policy engine, to block privileged hostPath mounts and to restrict who can create ClusterRoleBindings.
- Hunt for signs of abuse: audit existing ClusterRoleBindings for unexpected cluster-admin grants. Review workloads for hostPath volumes that mount
/or other sensitive host paths. If you find anything suspicious, rotate cluster secrets.
