CVE-2026-61549
CriticalCVSS 9.0Summary
Woodpecker, a CI/CD engine, from 1.0.0 until 3.16.0 allows any user with Push permission on a connected repository to run pipeline pods under an arbitrary ServiceAccount in the pipeline namespace without administrator authorization. This enables inheriting that account's RBAC permissions and potentially taking over the cluster. The issue is fixed in version 3.16.0.
Risk Assessment
An attacker could exfiltrate secrets such as database credentials, API keys, and TLS certificates, and may take over the entire Kubernetes cluster. The risk is high in CI/CD environments with connected repositories.
Recommendation
Upgrade Woodpecker to version 3.16.0 or later. Restrict Push permissions on repositories and apply least privilege to ServiceAccounts in the cluster.
Other vulnerabilities in Woodpecker
See all- CVE-2026-58370High
A vulnerability in Woodpecker before version 3.15.0 allows bypassing the ApprovalAllowedUsers list by manipulating the pipeline.Author field. For the GitLab forge driver, pipeline.Author is populated from the git commit author name (commit.author.name) in the webhook payload, which is attacker-controlled and not verified by GitLab. A user opening a merge request from a fork can set the commit author name to match an entry in ApprovalAllowedUsers, causing needsApproval to return false and the pipeline to run without required approval.
- CVE-2026-58369Medium
Woodpecker before version 3.15.0 exposes the /api/orgs/lookup/*org_full_name endpoint without authentication middleware, and the LookupOrg handler unconditionally dereferences the session user (user.ForgeID via ForgeFromUser) when selecting the forge to query. For an unauthenticated request, session.User returns nil, causing a NULL pointer dereference and panic. The panic is recovered by gin recovery middleware and the server continues serving (returning HTTP 500), but each request writes a multi-line panic stack trace to the error log.
Original NVD description (English source)
Woodpecker is a CI/CD engine. From 1.0.0 until 3.16.0, pipeline/backend/kubernetes/backend_options.go defines backend_options.kubernetes.serviceAccountName, and the Kubernetes backend in pipeline/backend/kubernetes/pod.go copies that pipeline-step value directly into the pod specification without administrator authorization. Any user with Push permission on a connected repository can therefore run pipeline pods under an arbitrary ServiceAccount in the pipeline namespace and inherit that account's RBAC permissions. When a privileged ServiceAccount is reachable, the attacker can exfiltrate secrets such as database credentials, API keys, and TLS certificates and may take over the cluster. This issue is fixed in version 3.16.0.