Woodpecker

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.

Published: 2026-09-15T14:53:57.382Z
Updated: 2026-09-16T03:56:27.876Z

Woodpecker before 3.15.0 matches the ApprovalAllowedUsers bypass list against pipeline.Author. For the GitLab forge driver, pipeline.Author is populated from the git commit author name (commit.author.name) carried in the webhook payload, which is attacker-controlled and not verified by GitLab. A user who can open a merge request from a fork can set the commit author name to match an entry in ApprovalAllowedUsers, causing needsApproval to return false so the pipeline runs without the required approval. This defeats the fork-approval security boundary and allows execution of attacker-controlled pipeline steps on a Woodpecker agent and exfiltration of CI secrets exposed to the run. Other built-in forge drivers (Gitea, Forgejo, GitHub, Bitbucket) derive pipeline.Author from the forge-validated sender/actor identity and are not affected.

Published: 2026-06-30T15:57:09.624Z
Updated: 2026-11-08T14:06:56.124Z

Woodpecker before 3.15.0 registers 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, so any unauthenticated HTTP request triggers a NULL pointer dereference in the handler. 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. A low-bandwidth unauthenticated attacker can repeatedly probe the endpoint to flood the logs (about 37 lines per request), inflating disk usage and downstream log-ingestion cost and burying legitimate log events.

Published: 2026-06-30T15:56:45.044Z
Updated: 2026-11-08T14:06:55.428Z

Woodpecker is a CI/CD engine. Starting in version 3.0.0 and prior to version 3.14.1, a vulnerability in Woodpecker CI's gRPC layer allowed any authenticated agent to impersonate any other agent on the same server by injecting a forged `agent_id` value into outgoing gRPC metadata. The server correctly verified the JWT token but then discarded the verified agent identity in favor of the client-supplied value. Version 3.14.1 patches the issue. As a workaround, disable org agents (`WOODPECKER_DISABLE_USER_AGENT_REGISTRATION=true`) and delete existing ones.

Published: 2026-06-18T14:13:38.065Z
Updated: 2026-06-18T16:10:41.914Z

Woodpecker is a simple yet powerful CI/CD engine with great extensibility. The server allow to create any user who can trigger a pipeline run malicious workflows: 1. Those workflows can either lead to a host takeover that runs the agent executing the workflow. 2. Or allow to extract the secrets who would be normally provided to the plugins who's entrypoint are overwritten. This issue has been addressed in release version 2.7.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Published: 2024-07-19T19:58:41.180Z
Updated: 2024-08-02T04:46:52.559Z