Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

Woodpecker: Privilege escalation via unrestricted serviceAccountName in the Kubernetes backendGHSA-qf34-295c-26v8

Fix: woodpecker-ci/woodpecker#6792

GHSA-qf34-295c-26v8 is a Improper Privilege Management vulnerability in go.woodpecker-ci.org/woodpecker/v3. A fix is available for go.woodpecker-ci.org/woodpecker/v3 — see the affected versions and patch details below.

Also known asCVE-2026-61549GO-2026-5992
Published
Updated
Affected
3 pkgs
Patched
1 / 3
Exploits
None indexed
Exploitation data as of Oct 23, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • A successful exploit gives an attacker total control of the affected component, not partial access.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-qf34-295c-26v8.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs19th percentile — riskier than 19% of all scored CVEsHighest risk
0.00%0.26%0.52%0.78%0.3%0.3%Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

3 pkgs affected
🐹go.woodpecker-ci.org/woodpecker/v3🐹github.com/woodpecker-ci/woodpecker🐹go.woodpecker-ci.org/woodpecker/v2

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

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)

Affected Packages

3 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogo.woodpecker-ci.org/woodpecker/v3all versions3.16.0go get go.woodpecker-ci.org/woodpecker/v3@v3.16.0
🐹Gogithub.com/woodpecker-ci/woodpecker≥ 1.0.0No fix
🐹Gogo.woodpecker-ci.org/woodpecker/v2all versionsNo fix

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for go.woodpecker-ci.org/woodpecker/v3, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update go.woodpecker-ci.org/woodpecker/v3 to 3.16.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-qf34-295c-26v8 is resolved across your whole dependency graph.

  3. Workarounds

    Close the privilege gap rather than the entry point: audit which accounts, roles and service identities can reach the affected operation, drop the component to the least privilege it actually needs, and review file and directory permissions created by earlier installs — a default left in place is what makes this reachable.

Frequently Asked Questions

### 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 (datab
O3 Security · Impact-Aware SCA

Is GHSA-qf34-295c-26v8 in your dependencies?

Find it across Go, including transitive dependencies.

Woodpecker: Privilege escalation via unrestricted…