CVE-2026-61549
Fix: woodpecker-ci/woodpecker#6792CVE-2026-61549 is a security vulnerability in go.woodpecker-ci.org/woodpecker/v3. O3 Security confirms whether CVE-2026-61549 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Woodpecker: Privilege escalation via unrestricted serviceAccountName in the Kubernetes backend
Real-World Exposure
go.woodpecker-ci.org/woodpecker/v3🐹github.com/woodpecker-ci/woodpecker🐹go.woodpecker-ci.org/woodpecker/v2Real-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
defaultServiceAccount 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.0throughv3.15.0 - Source:
pipeline/backend/kubernetes/backend_options.go(fieldServiceAccountName),pipeline/backend/kubernetes/pod.go(assigned to pod spec with no gating)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | go.woodpecker-ci.org/woodpecker/v3 | all versions | 3.16.0 |
| 🐹Go | github.com/woodpecker-ci/woodpecker | ≥ 1.0.0 | No fix |
| 🐹Go | go.woodpecker-ci.org/woodpecker/v2 | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for go.woodpecker-ci.org/woodpecker/v3. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 CVE-2026-61549 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether CVE-2026-61549 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to CVE-2026-61549. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-61549 in your dependencies?
O3 detects CVE-2026-61549 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.