CVE-2026-47172
Description
Privileged deploy workflow in Quest Bot builds and deploys attacker-controlled code from PRs whose source branch is named main, leading to container compromise.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Privileged deploy workflow in Quest Bot builds and deploys attacker-controlled code from PRs whose source branch is named main, leading to container compromise.
Vulnerability
In Quest Bot versions prior to 1.0.3, the repository contains a privileged deployment workflow (.github/workflows/deploy.yaml) that runs after an unprivileged build workflow (.github/workflows/build.yaml) completes. The build workflow runs on pull requests, and the deploy workflow checks out github.event.workflow_run.head_sha and builds that code into a Docker image, pushing it as latest and triggering production deployment via a webhook. The deploy workflow only verifies that github.event.workflow_run.head_branch == 'main'. If an attacker opens a pull request from a branch named main, this condition can match attacker-controlled PR code, allowing untrusted commits to be built and deployed [1].
Exploitation
An attacker needs only the ability to open a pull request against the repository from a branch named main. The build workflow runs automatically on the PR, and when it completes, the deploy workflow triggers, checks out the commit at head_sha, builds the Dockerfile from the attacker-controlled repository files, pushes the resulting image to GHCR, and calls the Dokploy deployment webhook with a write token [1]. No additional authentication or user interaction is required.
Impact
Successful exploitation results in the attacker gaining the ability to deploy a malicious Docker container to production, fully compromising the Quest Bot instance. The attacker can execute arbitrary code in the privileged deployment context, potentially exfiltrating secrets, modifying bot behavior, or disrupting services [1].
Mitigation
The vulnerability is patched in Quest Bot version 1.0.3, released on 2026-06-11 [2]. Users should update their deployment to this version immediately. No workaround is documented; the advisory recommends reviewing GitHub’s warnings about workflow_run workflows and access tokens. The CVE is not listed on CISA’s KEV as of the publication date.
AI Insight generated on Jun 11, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2(expand)+ 1 more
- (no CPE)
- (no CPE)range: <1.0.3
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"The deploy workflow's condition `github.event.workflow_run.head_branch == 'main'` does not distinguish between a push to the default branch and a pull request whose source branch is named `main`, allowing attacker-controlled PR code to be built and deployed."
Attack vector
An attacker forks the repository, creates a branch named exactly `main`, modifies the application or Dockerfile with malicious code, and opens a pull request from `attacker-fork:main` into `upstream:main`. The build workflow completes successfully, and the deploy workflow's condition (`head_branch == 'main'`) matches the attacker-controlled PR branch, causing it to check out the PR commit, build the attacker-controlled Docker image, push it as `latest` to GHCR, and trigger production deployment via the Dokploy webhook [ref_id=1].
Affected code
The vulnerable chain involves `.github/workflows/build.yaml`, `.github/workflows/deploy.yaml`, and `Dockerfile`. The build workflow runs on pull requests; the deploy workflow uses `workflow_run` to check out the triggering run's `head_sha` and builds that code into a Docker image when `head_branch == 'main'` — a condition that can be satisfied by a PR source branch named `main` [ref_id=1].
What the fix does
The advisory does not include a patch diff, but version 1.0.3 is listed as the fix. The remediation likely involves either restricting the deploy workflow to only run on `push` to the default branch (not on `workflow_run` triggered by PRs), or adding an explicit check that the triggering workflow's head commit is already merged into the default branch, preventing attacker-controlled PR code from being treated as deployable [ref_id=1].
Preconditions
- configRepository accepts pull requests from forks
- configGitHub Actions are enabled on pull requests
- configDeploy workflow is present on the default branch
- configDOKPLOY_DEPLOY_WEBHOOK secret is configured
- configDeploy workflow has permissions to push packages and trigger deployment
- inputAttacker can create a branch named 'main' in their fork
Reproduction
## Reproduction
1. Fork the repository. 2. In the fork, create a branch named exactly `main`. 3. Modify the application or Dockerfile with a harmless proof marker (e.g., change the bot startup log or add a visible marker file during image build). 4. Open a pull request from `attacker-fork:main` into `upstream:main`. 5. Wait for Build Test to complete successfully. 6. Observe the Deploy workflow triggered by `workflow_run`. 7. Confirm that the deployed image contains the harmless marker or modified startup log from the PR branch, even though the PR was not merged [ref_id=1].
Generated on Jun 11, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2News mentions
0No linked articles in our index yet.