dbcve.org
CWE-829Weakness · CWE-829

CVE-2026-47174

CRITICAL · 9.5 CVSS v4.0 Published 2026-06-11
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
100/100
Remediation priority · Urgent
Remotely reachable No privileges Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
In Duck Site before version 1.0.1, the repository has a deploy workflow that runs after the build workflow completes. The build workflow runs on pull requests, while the deploy workflow runs with package-write permissions and deployment secrets. If an attacker can make a pull request build satisfy the deploy workflow’s main branch condition, the deploy job checks out the triggering workflow commit, builds it into a Docker image, pushes it as latest, and triggers Dokploy deployment. This can allow attacker-controlled pull request code to become the deployed production site image without being merged. This issue has been patched in version 1.0.1.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

A GitHub Actions CI/CD pipeline vulnerability in Duck Site allows an attacker to trigger the deploy workflow from an unmerged pull request by satisfying the main branch condition. The deploy job then checks out the PR commit, builds it into a Docker image, pushes as latest, and triggers production deployment using elevated package-write permissions and deployment secrets—allowing malicious code to become the production image without merging.

MitigationUpgrade to version 1.0.1 which patches the workflow logic. Additionally, configure the deploy workflow to only trigger on actual main branch commits (not PRs) and verify the commit source before deployment.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
Authentication
X
User interaction
None
Scope
X

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Locate the deploy workflow file
    Inspect the repository for GitHub Actions workflows in .github/workflows/ and identify the workflow responsible for production deployment
    Affected if A deploy workflow exists that handles production deployments
  2. Examine workflow trigger conditions
    Review the 'on' section of the deploy workflow to see which events trigger it (e.g., push, pull_request, workflow_dispatch)
    Affected if The workflow triggers on pull_request events or has conditions that can be satisfied by unmerged PRs
  3. Verify checkout behavior
    Check if the workflow uses actions/checkout to fetch code and inspect the ref/branch inputs - determine whether it checks out the PR branch instead of the main branch
    Affected if The workflow checks out PR commits rather than only main branch commits
  4. Identify Docker build/push from checked-out code
    Look for Docker build and push steps (e.g., docker build, docker push) that operate on the code checked out by the workflow
    Affected if Docker images are built and pushed from the checked-out (potentially PR) code as the 'latest' tag
  5. Confirm deployment triggers from workflow
    Examine whether the workflow triggers production deployment or uses elevated permissions (package-write, deployment secrets) after building the image
    Affected if The workflow uses elevated permissions or secrets to deploy the built image to production

A user is affected if their deploy workflow can be triggered by an unmerged pull request and proceeds to build/push that PR code to production using elevated permissions.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Upgrade to version 1.0.1 which patches the workflow logic. Additionally, configure the deploy workflow to only trigger on actual main branch commits (not PRs) and verify the commit source before deployment.

Recommended fix Moderate confidence

version 1.0.1

  1. Verify current version of Duck Site is earlier than 1.0.1 by checking package.json, git tags, or release notes
  2. Upgrade to version 1.0.1 or later which contains the patched workflow
  3. After upgrading, audit the GitHub Actions workflows to confirm the deploy workflow now properly validates the source branch/commit before deployment
  4. Ensure the deploy workflow requires explicit approval or checks for mergeability before deploying
  5. Review workflow run history to confirm no unauthorized deployments occurred prior to the patch

Generated from the published advisory — verify against the referenced sources before acting.

Have this fixed Scoped from the published advisory
  • Consultation3.0 h
  • Implementation4.0 h
  • Testing3.0 h
  • Review / QA2.0 h
12.0 hours of engineering $2,130
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,408.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-47174 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-47174 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data