### Impact A privilege escalation vulnerability affects Woodpecker instances using the **Kubernetes backend**. The pipeline option `backend_options.kubernetes.serviceAccountName` was passed directly to the pod spec without any admin gating. **Who is impacted:** any operator running the Kubernetes backend. Any user with **Push** permission on a connected repository can run pipeline pods under an arbitrary ServiceAccount in the pipeline namespace, gaining that account's RBAC permissions. If a privileged ServiceAccount is reachable in that namespace, this can lead to secret exfiltration (database credentials, API keys, TLS certs) and full cluster takeover. ### Patches https://github.com/woodpecker-ci/woodpecker/pull/6792 ### Workarounds Operators who cannot upgrade immediately can mitigate by any of: - **Restrict Push access** on repositories connected to the Kubernetes-backed instance to trusted users only. - **Harden the pipeline namespace**: ensure no privileged ServiceAccount exists or is bound in the namespace where pipeline pods run; keep the `default` ServiceAccount minimally privileged. - **Disable ServiceAccount token automounting** for ServiceAccounts that should not be used by pipelines. - **Enforce an admission policy** (e.g. OPA/Gatekeeper, Kyverno, or a ValidatingAdmissionPolicy) that rejects pipeline pods setting an unexpected `serviceAccountName`. - **Use a dedicated, isolated namespace** per org/instance with no sensitive RBAC bindings. ### Resources - Vulnerable option introduced in commit `609ba481b5e912f59aaae8ca7bc22b44523c5e37` - Affected versions: `v1.0.0` through `v3.15.0` - Source: `pipeline/backend/kubernetes/backend_options.go` (field `ServiceAccountName`), `pipeline/backend/kubernetes/pod.go` (assigned to pod spec with no gating)
### Impact A privilege escalation vulnerability affects Woodpecker instances using the **Kubernetes backend**. The pipeline option `backend_options.kubernetes.serviceAccountName` was passed directly to the pod spec without any admin gating. **Who is impacted:** any operator running the Kubernetes backend. Any user with **Push** permission on a connected repository can run pipeline pods under an arbitrary ServiceAccount in the pipeline namespace, gaining that account's RBAC permissions. If a privileged ServiceAccount is reachable in that namespace, this can lead to secret exfiltration (database credentials, API keys, TLS certs) and full cluster takeover. ### Patches https://github.com/woodpecker-ci/woodpecker/pull/6792 ### Workarounds Operators who cannot upgrade immediately can mitigate by any of: - **Restrict Push access** on repositories connected to the Kubernetes-backed instance to trusted users only. - **Harden the pipeline namespace**: ensure no privileged ServiceAccount exists or is bound in the namespace where pipeline pods run; keep the `default` ServiceAccount minimally privileged. - **Disable ServiceAccount token automounting** for ServiceAccounts that should not be used by pipelines. - **Enforce an admission policy** (e.g. OPA/Gatekeeper, Kyverno, or a ValidatingAdmissionPolicy) that rejects pipeline pods setting an unexpected `serviceAccountName`. - **Use a dedicated, isolated namespace** per org/instance with no sensitive RBAC bindings. ### Resources - Vulnerable option introduced in commit `609ba481b5e912f59aaae8ca7bc22b44523c5e37` - Affected versions: `v1.0.0` through `v3.15.0` - Source: `pipeline/backend/kubernetes/backend_options.go` (field `ServiceAccountName`), `pipeline/backend/kubernetes/pod.go` (assigned to pod spec with no gating)
Update go.woodpecker-ci.org/woodpecker/v3 to 3.16.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanWoodpecker: Privilege escalation via unrestricted serviceAccountName in the Kubernetes backend affects github.com/woodpecker-ci/woodpecker (go), go.woodpecker-ci.org/woodpecker/v2 (go), go.woodpecker-ci.org/woodpecker/v3 (go). Severity is high. ### Impact A privilege escalation vulnerability affects Woodpecker instances using the **Kubernetes backend**. The pipeline option `backend_options.kubernetes.serviceAccountName` was passed directly to the pod spec without any admin gating. **Who is impacted:** any operator running the Kubernetes backend. Any user with **Push** permission on a connected repository can run pipeline pods under an arbitrary ServiceAccount in the pipeline namespace, gaining that account's RBAC permissions. If a privileged ServiceAccount is reachable in that namespace, this can lead to secret exfiltration (database credentials, API keys, TLS certs) and full cluster takeover. ### Patches https://github.com/woodpecker-ci/woodpecker/pull/6792 ### Workarounds Operators who cannot upgrade immediately can mitigate by any of: - **Restrict Push access** on repositories connected to the Kubernetes-backed instance to trusted users only. - **Harden the pipeline namespace**: ensure no privileged ServiceAccount exists or is bound in the namespace where pipeline pods run; keep the `default` ServiceAccount minimally privileged. - **Disable ServiceAccount token automounting** for ServiceAccounts that should not be used by pipelines. - **Enforce an admission policy** (e.g. OPA/Gatekeeper, Kyverno, or a ValidatingAdmissionPolicy) that rejects pipeline pods setting an unexpected `serviceAccountName`. - **Use a dedicated, isolated namespace** per org/instance with no sensitive RBAC bindings. ### Resources - Vulnerable option introduced in commit `609ba481b5e912f59aaae8ca7bc22b44523c5e37` - Affected versions: `v1.0.0` through `v3.15.0` - Source: `pipeline/backend/kubernetes/backend_options.go` (field `ServiceAccountName`), `pipeline/backend/kubernetes/pod.go` (assigned to pod spec with no gating)
AI coding agents often install or upgrade packages automatically in go. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/woodpecker-ci/woodpeckergo | >=1.0.0,<=1.0.4 | Not reported |
| go.woodpecker-ci.org/woodpecker/v2go | <=2.8.3 | Not reported |
| go.woodpecker-ci.org/woodpecker/v3go | <3.16.0 | 3.16.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate go.woodpecker-ci.org/woodpecker/v3 to 3.16.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanWoodpecker: Privilege escalation via unrestricted serviceAccountName in the Kubernetes backend affects github.com/woodpecker-ci/woodpecker (go), go.woodpecker-ci.org/woodpecker/v2 (go), go.woodpecker-ci.org/woodpecker/v3 (go). Severity is high. ### Impact A privilege escalation vulnerability affects Woodpecker instances using the **Kubernetes backend**. The pipeline option `backend_options.kubernetes.serviceAccountName` was passed directly to the pod spec without any admin gating. **Who is impacted:** any operator running the Kubernetes backend. Any user with **Push** permission on a connected repository can run pipeline pods under an arbitrary ServiceAccount in the pipeline namespace, gaining that account's RBAC permissions. If a privileged ServiceAccount is reachable in that namespace, this can lead to secret exfiltration (database credentials, API keys, TLS certs) and full cluster takeover. ### Patches https://github.com/woodpecker-ci/woodpecker/pull/6792 ### Workarounds Operators who cannot upgrade immediately can mitigate by any of: - **Restrict Push access** on repositories connected to the Kubernetes-backed instance to trusted users only. - **Harden the pipeline namespace**: ensure no privileged ServiceAccount exists or is bound in the namespace where pipeline pods run; keep the `default` ServiceAccount minimally privileged. - **Disable ServiceAccount token automounting** for ServiceAccounts that should not be used by pipelines. - **Enforce an admission policy** (e.g. OPA/Gatekeeper, Kyverno, or a ValidatingAdmissionPolicy) that rejects pipeline pods setting an unexpected `serviceAccountName`. - **Use a dedicated, isolated namespace** per org/instance with no sensitive RBAC bindings. ### Resources - Vulnerable option introduced in commit `609ba481b5e912f59aaae8ca7bc22b44523c5e37` - Affected versions: `v1.0.0` through `v3.15.0` - Source: `pipeline/backend/kubernetes/backend_options.go` (field `ServiceAccountName`), `pipeline/backend/kubernetes/pod.go` (assigned to pod spec with no gating)
AI coding agents often install or upgrade packages automatically in go. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/woodpecker-ci/woodpeckergo | >=1.0.0,<=1.0.4 | Not reported |
| go.woodpecker-ci.org/woodpecker/v2go | <=2.8.3 | Not reported |
| go.woodpecker-ci.org/woodpecker/v3go | <3.16.0 | 3.16.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard