GPU VulnDB

Database/Control plane, storage & DevOps

Woodpecker CI: pipeline authors can pick any ServiceAccount for their build pods

CVSS 9.0CVE-2026-61549Control plane, storage & DevOpscurated

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

All Control plane, storage & DevOps entries

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.