Woodpecker CI EUVD-2026-78774

Requires the Woodpecker Kubernetes backend to be in use, an attacker holding Push permission on a repository connected to that instance (authenticated, PR:L), and - for meaningful impact - a privileged ServiceAccount that exists and is reachable in the namespace where pipeline pods run (the AT:P attack requirement). Exploitation is via the pipeline option backend_options.kubernetes.serviceAccountName in step backend options. It is limited by: only affected when the Kubernetes backend is configured (Docker/local backends are not vulnerable); the attacker must already have write/Push access; and the payoff is bounded by the RBAC actually granted to ServiceAccounts in that namespace - a namespace with only a minimally-privileged default ServiceAccount yields little escalation. No end-user interaction is needed beyond triggering the pipeline.

The vendor CVSS 4.0 base is 9.0 (AV:N/AC:L/AT:P/PR:L/UI:N with VC/VI/VA:H and subsequent-system SC/SI/SA:H), reflecting a network-reachable, low-privilege-authenticated attacker whose success additionally depends on a precondition (AT:P) - namely that a privileged ServiceAccount actually exists and is reachable in the pipeline namespace. That AT:P plus the SC/SI/SA:H subsequent-system impact is what pushes the score into the critical range, and it is a fair model: the vulnerability is real and the impact (cluster takeover) is severe, but exploitation value is entirely contingent on namespace RBAC posture. No EPSS score, KEV entry, or SSVC decision was supplied; there is no public exploit identified and no evidence of active exploitation, so this is a genuine-but-conditional priority rather than an internet-wide worm risk. Two limiting factors keep real-world risk below the raw number: the attacker must already hold Push (write) access on a connected repo, and a suitably privileged ServiceAccount must be present in the namespace - in a well-segmented single-tenant namespace with a minimal default ServiceAccount, exploitation yields little. Priority is highest for multi-tenant Woodpecker deployments that share a namespace with privileged workloads.

An attacker with Push access to a repo connected to a Kubernetes-backed Woodpecker instance commits a pipeline YAML that sets backend_options.kubernetes.serviceAccountName to a privileged ServiceAccount in the pipeline namespace (for example one bound to a broad ClusterRole). The pipeline pod launches under that identity, and the attacker's step uses the mounted token to read Kubernetes Secrets and call the API server, exfiltrating database credentials and API keys or creating further privileged workloads toward cluster takeover. No public exploit code is required - the attack is a few lines of pipeline configuration.