Which versions of Quest Bot are affected by CVE-2026-47172?

Quest Bot versions prior to 1.0.3 contain a critical vulnerability allowing remote attackers to inject malicious code directly into production deployment pipelines and compromise the latest Docker…. A patch is available.

How to fix or mitigate CVE-2026-47172?

Within 24 hours: Identify all Quest Bot deployments in use; implement mandatory code review approval for pull requests and apply least-privilege access controls to GitHub Actions workflows. Within 7 days: Monitor GHSA-9qf3-c86c-j346 for Quest Bot version 1.0.3 release; audit all deployments from the past 30 days for suspicious activity; implement separate approval authorization between build and deploy workflows. Within 30 days: Upgrade all instances to Quest Bot version 1.0.3 upon availability; validate container image integrity across all deployments; review and strengthen CI/CD security policies.

Quest Bot CVE-2026-47172

Q: What is the CVSS score of CVE-2026-47172?

CVE-2026-47172 has a CVSS 4.0 base score of 9.5 (Critical). CVSS vector: 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. EPSS exploitation probability: 0.0%.

EUVD-2026-36300 CRITICAL

Inclusion of Functionality from Untrusted Control Sphere (CWE-829)

2026-06-11 GitHub_M

Information Disclosure Docker Quest Bot Duck Organization

9.5

CVSS 4.0 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

9.5 CRITICAL

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

vuln.today AI

9.0 CRITICAL

Network-reachable via PR submission with no auth or UI, but AC:H reflects the required workflow_run+head_sha+branch-name-gate pattern; scope changes to the production bot and Discord guilds, all impacts High.

3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Patch available

Jun 11, 2026 - 20:01 EUVD

Analysis Generated

Jun 11, 2026 - 19:19 vuln.today

CVE Published

Jun 11, 2026 - 18:28 cve.org

CRITICAL 9.5

DescriptionCVE.org

Quest Bot is an opensource modern Discord Bot built for moderation, utilities and support. Prior to version 1.0.3, the repository has a privileged deploy workflow that runs after the unprivileged build workflow completes. The build workflow runs on pull requests, and the deploy workflow checks out the triggering workflow’s head_sha, builds that code into a Docker image, pushes it as latest, and triggers production deployment. If an attacker can open a pull request from a branch named main, the deploy workflow condition can treat the PR build as deployable and build the attacker-controlled commit in a privileged deployment context. This can result in malicious container deployment and production bot compromise. This issue has been patched in version 1.0.3.

Articles & Coverage 1

News Critical Workflow Injection in Docker via Quest Bot - CVE-2026-47172 Jun 11, 2026

AnalysisAI

Privileged GitHub Actions workflow injection in Quest Bot (Discord moderation bot) prior to version 1.0.3 allows remote attackers to deploy malicious container images to production by opening a pull request from a branch named 'main'. The unprivileged build workflow's head_sha is consumed by a downstream privileged deploy workflow, which then builds and publishes attacker-controlled code as the 'latest' Docker image and triggers production rollout. No public exploit identified at time of analysis, but the GitHub Security Advisory (GHSA-9qf3-c86c-j346) documents the chain end-to-end.

Technical ContextAI

The flaw lives in the repository's CI/CD pipeline rather than the bot's runtime code: a GitHub Actions deploy workflow triggers on workflow_run completion of an upstream build workflow that runs on pull_request events. The deploy job uses the triggering workflow's head_sha to checkout code, which on a PR points at the fork/branch's HEAD - attacker-controlled content. A naive branch-name check ('if branch == main') was used as the deploy gate, but workflow_run exposes the source branch name of the PR head, so a PR opened from a branch literally named 'main' satisfies the condition. This pattern matches CWE-829 (Inclusion of Functionality from Untrusted Control Sphere) and is the same class of pwn_request / workflow_run privilege escalation documented by GitHub Security Lab. Affected CPE is cpe:2.3:a:duck-organization:quest-bot before 1.0.3.

RemediationAI

Upgrade to Quest Bot 1.0.3 (Vendor-released patch: questbot-v1.0.3) by pulling the fixed workflow definitions from https://github.com/duck-organization/questbot/releases/tag/questbot-v1.0.3 and re-deploying; forks must merge the workflow changes, not just rebase application code. As compensating controls until upgrade: change the deploy workflow trigger from workflow_run to a push/tag event on the protected main branch (removes the PR-origin head_sha problem entirely, at the cost of losing PR-built artifacts); or gate the deploy job on github.event.workflow_run.head_repository.full_name github.repository AND github.event.workflow_run.event 'push' to reject PR-origin runs (side effect: blocks all PR-driven deploys, including legitimate ones); or move the privileged Docker push/registry credentials into a GitHub Environment with required reviewers so a human must approve each deploy (adds release friction). Refer to the GHSA-9qf3-c86c-j346 advisory for the maintainer's specific fix.