CVE-2026-58370: Woodpecker GitLab Fork Approval Bypass – Code Execution via Author Spoofing

Technical summary

The vulnerability stems from insecure principal validation in Woodpecker's approval workflow. The ApprovalAllowedUsers bypass list is matched against pipeline.Author, which is derived differently depending on the forge driver. For GitLab, pipeline.Author is populated from commit.author.name in the webhook payload—a field the attacker controls and GitLab does not cryptographically sign or verify before transmission. An attacker with fork-merge capability can set commit.author.name to an arbitrary value, including one that matches an entry in ApprovalAllowedUsers. The needsApproval function then returns false, bypassing the approval requirement. Other forge drivers (GitHub, Gitea, Forgejo, Bitbucket) derive pipeline.Author from the authenticated sender or actor identity returned by the forge API after verification, preventing spoofing. The fix requires Woodpecker to validate the author identity against GitLab's authenticated user context rather than trusting the commit author field.

Business impact

This vulnerability breaks the fork-approval security model, a critical control for organizations using public or untrusted repositories. Teams relying on Woodpecker to enforce code review and approval gates on external contributions are exposed to code injection and secret theft. Attackers can execute arbitrary pipeline steps—including credential theft, code modification, or lateral movement—without human oversight. Organizations leveraging Woodpecker in multi-tenant or open-source environments face elevated risk of CI/CD compromise and downstream supply-chain attacks.

Affected systems

Woodpecker versions prior to 3.15.0 are affected when using the GitLab forge driver. GitLab is the only built-in forge driver impacted; Gitea, Forgejo, GitHub, and Bitbucket are unaffected due to their use of authenticated identity data. The vulnerability requires the attacker to have the ability to open a merge request from a fork, a capability typically granted to external contributors. Self-hosted Woodpecker instances using GitLab are at highest risk, as are SaaS deployments if fork-merge permissions are enabled for untrusted users.

Exploitability

Exploitability is straightforward for any user with fork-merge access to a GitLab repository linked to Woodpecker. No special tools or reverse engineering are required; the attacker simply creates a forked commit with commit.author.name set to an approved user's name and opens a merge request. The pipeline will execute without approval. The CVSS score of 8.1 reflects the high impact (code execution, secret exposure) and moderate attack complexity (fork-merge access required, but not unusual). Exploitation does not require authentication to Woodpecker itself, only to GitLab. No known public exploits have been confirmed, but the attack is trivial to execute once the vulnerability is understood.

Remediation

Upgrade Woodpecker to version 3.15.0 or later immediately. The fix changes how GitLab author identity is resolved, moving away from untrusted commit metadata to authenticated user information. After patching, verify that approval policies are re-enforced by testing a merge request from a fork without an approved author. Organizations unable to patch immediately should disable fork-merge access for external contributors or disable the Woodpecker integration on public repositories until the update is applied.

Patch guidance

Patches are available in Woodpecker 3.15.0 and later. Consult the official Woodpecker release notes and vendor advisory for version availability and deployment instructions for your deployment model (Docker, Kubernetes, or binary). Test the patch in a staging environment to confirm approval workflows function correctly before deploying to production. If your organization uses a custom forge driver, audit it to ensure author identity is derived from forge-authenticated data and not from user-controlled git metadata.

Detection guidance

Monitor GitLab webhook logs and Woodpecker pipeline execution logs for anomalies: pipelines that execute without approval from commits authored by non-whitelisted users, or pipelines where commit.author.name does not match the authenticated merge request creator identity. Implement alerts on pipeline runs that bypass approval and exfiltrate or access CI secrets. Audit existing pipelines to identify any runs that executed under suspicious author spoofing. Review GitLab repository permissions to identify users with fork-merge capability and assess their trustworthiness.

Why prioritize this

This vulnerability merits immediate attention because it directly defeats a core security boundary—approval gates on external code—and enables hands-on-keyboard code execution with secret access. The attack is trivial to execute and requires only fork-merge access, a capability commonly granted in open-source and collaborative environments. Even though it affects only the GitLab forge driver, organizations running Woodpecker with GitLab are at significant risk. The presence of CI/CD secrets in pipeline environments amplifies the impact beyond pipeline manipulation to credential theft and lateral movement.

Risk score, explained

The CVSS 3.1 score of 8.1 (HIGH) reflects high impact (confidentiality, integrity, and availability of the CI/CD system and its secrets are compromised) and network-accessible attack surface with high complexity (AC:H) due to the requirement for fork-merge permissions. The score does not require authentication to Woodpecker, and the scope is unchanged (the attacker gains control within the CI/CD system, not the underlying host). The score is appropriate for a bypass of a key security control with direct code and secret exposure.

Frequently asked questions