Database/Control plane, storage & DevOps
Woodpecker CI: pipeline authors can pick any ServiceAccount for their build pods
Impact
The Kubernetes backend copies the per-step serviceAccountName from the pipeline file straight into the pod spec with no administrator-side allowlist. Anyone with Push rights on a connected repository can therefore run build pods as any ServiceAccount in the pipeline namespace and inherit its RBAC. Where a privileged ServiceAccount exists - and on GPU clusters the CI namespace often holds one for node labelling, image publishing or Helm deploys - that is a path to reading cluster secrets (registry credentials, database passwords, TLS keys) and potentially to cluster takeover. Build pods on a GPU cluster usually land on the same nodes as tenant workloads, so the escalation starts from a position that already has scheduling access.
Who can reach it
Any user with Push permission on a repository connected to the Woodpecker server; they need no access to the cluster itself, only the ability to commit a pipeline file that a runner picks up.
What to do
Upgrade the Woodpecker server and agents to 3.16.0, which gates the option behind administrator authorization, and restart the services. No node drain is required. Before upgrading, treat any ServiceAccount reachable from the pipeline namespace as potentially used: review RBAC there, rotate secrets that a privileged ServiceAccount could have read, and drop the pipeline namespace's ServiceAccounts to least privilege.
References
Related entries
- Jenkins Remoting: JEP-200 deserialization filter bypassed via fallback class resolution on the controllerCVE-2026-70426 · Jenkins Remoting (JEP-200 deserialization class filter, fallback resolution path)Critical
- Crossplane package manager (cosign signature verification via ImageConfig): SUPPLY CHAIN, TIME-OF-CHECK TO TIME-OF-USENCVD-2026-055-crossplane-package-manager-cosig · Crossplane package manager (cosign signature verification via ImageConfig)Critical
- Ceph CephX: malleable, unauthenticated tickets let a low-privilege key be forged into Manager, MDS or OSD accessCVE-2025-30156 · Ceph CephX authentication protocol (unauthenticated AES-128-CBC ticket encryption)High
- Ceph CephX (authentication protocol): A tenant holding one low-privilege CephX client key ends up with cluster-wideNCVD-2025-016-ceph-cephx-authentication-protoc · Ceph CephX (authentication protocol)High
- GlusterFS (brick, server-rpc-fops.c): Multiple stack buffer overflows from fixed-size alloca() allocations in the brickCVE-2018-10907 · GlusterFS (brick, server-rpc-fops.c)High
- GlusterFS (brick, gfs3_symlink_req): Symlink creation is not confined to the volume, so a client plants a link pointingCVE-2018-10928 · GlusterFS (brick, gfs3_symlink_req)High
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.