EUVD-2026-40358
GHSA-wpx4-jm4h-w8j6
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Remote and unauthenticated against Woodpecker (PR:N/UI:N), but AC:H because it needs the GitLab driver, a populated ApprovalAllowedUsers list, and a known allowlisted name; full C/I/A from RCE on the agent and secret theft.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
8DescriptionCVE.org
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.
Articles & Coverage 1
AnalysisAI
Approval-gate bypass in Woodpecker CI before 3.15.0 lets an attacker who can open a merge request from a fork against a GitLab-backed repository run unapproved, attacker-controlled pipelines. Because the GitLab forge driver populates pipeline.Author from the spoofable git commit author name (commit.author.name) rather than the GitLab-validated user identity, an attacker simply sets the commit author to a name listed in ApprovalAllowedUsers, making needsApproval return false. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Requires the target Woodpecker server to use the GitLab forge driver AND to have the fork-approval allowlist (ApprovalAllowedUsers) populated with at least one trusted entry; the attacker must be able to open a merge request from a fork (possible to anyone on public/open GitLab projects) and must know or guess one allowlisted author name to place in the spoofed commit.author.name. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | Signals are mixed but lean toward a genuine, high-impact issue for the affected deployment subset. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker forks a public GitLab project that is built by a Woodpecker instance using fork approvals, then crafts a commit whose author name (commit.author.name) matches a trusted entry in ApprovalAllowedUsers and opens a merge request. Woodpecker's needsApproval check returns false, so the attacker's pipeline runs automatically on an agent, executing arbitrary steps and reading any CI secrets exposed to the job. … |
| Remediation | Vendor-released patch: upgrade Woodpecker CI to v3.15.0 or later (https://github.com/woodpecker-ci/woodpecker/releases/tag/v3.15.0), which derives pipeline.Author from the GitLab-validated user (hook.User.Username) instead of the spoofable commit author name. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours: Identify all Woodpecker CI instances using GitLab integration and running versions before 3.15.0; assess whether approval gates are in use and what secrets are accessible to CI pipelines. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-exec
Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers r
Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any
Cross-repository information disclosure and cross-task tampering in Gitea's self-hosted Git server (fixed in v1.26.2) ar
Server-side request forgery in Gitea versions up to and including 1.26.2 lets authenticated users abuse incomplete allow
Gitea fails to validate repository ownership when linking attachments to releases, allowing users to attach files from o
Gitea fails to validate repository ownership when deleting Git LFS locks, allowing users with write access to one repo t
Gitea does not properly validate project ownership in organization operations, allowing users with project write access
Stored cross-site scripting in Gitea 1.25.x affects the built-in 3D file viewer (Online3DViewer integration) where a cra
Authorization bypass in Gitea versions up to and including 1.26.1 allows any authenticated user with mere read access to
Authorization bypass in Gitea versions 1.22.3 through 1.26.1 allows holders of `public-only` access tokens or OAuth gran
Authorization bypass in Gitea versions prior to 1.26.0 lets a read-only organization member create repositories in the o
Same weakness CWE-290 – Authentication Bypass by Spoofing
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today