Which versions of Kubernetes are affected by CVE-2026-61549?

Woodpecker CI deployments on Kubernetes (versions 1.0.0-3.15.0) face a critical control bypass where ordinary developers can escalate to privileged service accounts, potentially exposing production…. A patch is available.

How to fix or mitigate CVE-2026-61549?

Within 24 hours: audit deployments to identify all Woodpecker CI instances running v1.0.0 through v3.15.0 with the Kubernetes backend and catalog their access permissions. Within 7 days: upgrade all affected instances to v3.16.0 (which gates the serviceAccountName option by default) and verify the fix is active. Within 30 days: review repository contributor permissions to align with principle of least privilege, and audit ServiceAccount RBAC policies to ensure pipeline pods have minimal required permissions.

Kubernetes CVE-2026-61549

HIGH

Improper Privilege Management (CWE-269)

2026-07-14 https://github.com/woodpecker-ci/woodpecker

GHSA-qf34-295c-26v8

Privilege Escalation Kubernetes Suse

Severity by source

SUSE

8.2 MEDIUM

qualitative

Lifecycle Timeline

Source Code Evidence Fetched

Jul 14, 2026 - 21:15 vuln.today

Analysis Generated

Jul 14, 2026 - 21:15 vuln.today

CVE Published

Jul 14, 2026 - 20:29 cve.org

HIGH

DescriptionCVE.org

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)

Articles & Coverage 1

News 5 New Kubernetes Vulnerabilities - 5 High Severity Jul 15, 2026

AnalysisAI

Privilege escalation in Woodpecker CI (v1.0.0 through v3.15.0) running the Kubernetes backend lets any user with Push permission on a connected repository set the pipeline pod's serviceAccountName to an arbitrary ServiceAccount in the pipeline namespace, inheriting its RBAC rights. Because the option was passed straight to the pod spec with no admin gating, a low-privilege contributor can pivot to a privileged ServiceAccount and exfiltrate secrets (DB credentials, API keys, TLS certs) or take over the cluster. No public exploit identified at time of analysis, and it is not listed in CISA KEV; the fix is available in v3.16.0 via a default-off gating flag.