Quest Bot CVE-2026-47172

Requires the target repository to use the pre-1.0.3 workflow layout where an unprivileged build workflow runs on pull_request and a privileged deploy workflow triggers on its workflow_run completion, checks out github.event.workflow_run.head_sha, and gates on the head branch name being 'main'. The attacker must be able to open a pull request from a branch literally named 'main' (trivial from any fork) targeting the upstream repo, and the upstream must accept PRs from forks for the build workflow to run. Limiting factors: only repositories that copied this specific workflow pattern are exploitable (not a runtime bug in the bot itself), the deploy registry/credentials must still be wired to a production environment, and any branch-protection or required-reviewer environment gate on the deploy job blocks the chain. No user interaction beyond opening the PR is needed.

CVSS 4.0 base of 9.5 (AV:N/AC:L/AT:P/PR:N/UI:N with VC/VI/VA/SC/SI/SA all High) is plausible because successful exploitation yields full compromise of the production bot container and downstream Discord servers it operates in - a subsequent-system impact justifying the SC/SI/SA:H. AT:P (Present attack requirements) correctly reflects that the target repo must use this specific workflow_run + head_sha + branch-name-gated pattern, which is a real but non-default precondition. No EPSS, no CISA KEV entry, and no public PoC are referenced, so this is best treated as a targeted supply-chain risk against the duck-organization/questbot repository and any fork that copied the workflow rather than a broadly exploitable issue. The 'Information Disclosure' tag in the source feed understates impact - this is code execution and supply-chain compromise, not just disclosure.

An attacker forks duck-organization/questbot, creates a branch literally named 'main' in their fork, commits a backdoored bot image build (e.g., a token exfiltrator or reverse shell in the Dockerfile), and opens a pull request from that 'main' branch into the upstream repository. The upstream build workflow runs on the PR and completes; the deploy workflow then fires on workflow_run, checks out the PR's head_sha, builds the attacker's Dockerfile, pushes it as the 'latest' tag to the registry, and triggers production rollout - at which point the malicious container runs with the production bot token and compromises every Discord guild it is installed in. No public exploit identified at time of analysis, though the advisory describes the chain in enough detail to reproduce.