Duck Site CVE-2026-47174

Exploitation requires (1) the target to be running a vulnerable Duck Site repository (pre-1.0.1) whose deploy workflow uses the workflow_run trigger paired with a main-branch condition that can be satisfied by a PR-originated run, (2) the attacker to be able to open a pull request that triggers the build workflow - trivial on a public repo, gated by collaborator/fork-PR-approval settings on a private one, and (3) the PR build to successfully complete so the deploy workflow_run fires. Limiting factors are GitHub's default 'Require approval for first-time contributors' Actions setting (which blocks unapproved external PR runs), any branch protection or environment protection rules that require manual approval before Dokploy deployment, and the fact that the deploy workflow must still be present and unpatched. The CVSS 4.0 vector lists AT:P precisely because of this required PR-to-deploy-gate-satisfaction step rather than fully unconditional exploitability.

The CVSS 4.0 base score of 9.5 is driven by network attack vector, low complexity, no privileges, no user interaction, and full high impact on both the vulnerable system (the CI/CD pipeline / GHCR registry) and a subsequent system (the deployed production site via Dokploy) - credible given the workflow design. AT:P (Attack Requirements: Present) acknowledges the attacker still has to craft a PR run that satisfies the deploy workflow's branch condition, which is the meaningful real-world gating factor. EPSS and CISA KEV data were not supplied, so widespread exploitation cannot be asserted; no public exploit code was identified in the references either, so this should be treated as a high-severity supply-chain risk that is theoretically internet-reachable (anyone with PR rights to the public repo) but not yet shown to be mass-exploited. Anyone running an unpatched fork of Duck Site that accepts external PRs should treat this as a priority fix, while private/internal-only deployments where PRs come only from trusted committers carry materially lower realistic risk.

An attacker forks the public Duck Site repository, modifies the application source to inject a backdoor or credential-stealing payload, and opens a pull request that causes the build workflow to run. Because the deploy workflow fires on the build workflow's completion and its main-branch guard can be satisfied from the PR-originated run, it then checks out the attacker's PR commit, builds it, pushes it to GHCR as :latest, and instructs Dokploy to roll the production site to that image - all without the PR ever being reviewed or merged. No public exploit code is identified at time of analysis, but the workflow_run / pwn-request class of bug is well documented and trivially adapted by an experienced attacker.