A pull_request_target trigger let any forked PR run code in DuckDuckGo's CI with secrets in reach

The two pull request triggers differ in whose context the job runs. The pull_request trigger runs in the fork's context with no access to the base repository's secrets ^[9]. The pull_request_target trigger runs in the base repository's context and does get them, because it exists for jobs such as posting comments or applying labels ^[10]. GitHub's documented rule, as dev.to author Faizan Akhtar relays it, is to never check out and execute untrusted code under that trigger ^[11].

semver-label.yml, which lives at .github/workflows/semver-label.yml in duckduckgo/content-scope-scripts ^[5], broke that rule at the checkout step. Its job was to auto-apply semantic-version labels to pull requests ^[7]. It checked out the PR's merge ref, meaning the attacker's fork code merged with the base, instead of the trusted base branch. It then ran dependency installation and a build in that directory ^[12]. npm executes lifecycle scripts from the checked-out code during installation ^[13]. Akhtar wrote: "Whoever controls package.json controls the machine." ^[17]

The privilege bar was low. According to Akhtar, nothing beyond a free GitHub account was required ^[18]. He reconstructs the chain from the disclosed report:

1. The attacker forks the repository and adds a lifecycle script to package.json. That is one file and one commit ^[1]. 2. The attacker opens a pull request with any trivial change. The trigger fires automatically, and the runner checks out the merge ref and runs the install step, so npm executes the planted script ^[2]. 3. The script reads secrets from the environment and sends them to attacker-controlled infrastructure ^[3].

The text we reviewed ends there. It breaks off mid-word in step 5, after announcing two prizes and starting the first, the Anthropic API key ^[3]. Akhtar's framing is "a straight path from a forked pull request to a poisoned release shipped inside every DuckDuckGo browser on the planet" ^[19]. The only token permission the text lists is pull-requests: write ^[14]. The part of the writeup that would connect that token to a release is not in the text we have, and it does not say whether DuckDuckGo changed the workflow or whether anyone used the hole.

In our view the audit is two questions per file. Does the workflow run on pull_request_target? If so, does it check out the PR's ref and run an install or a build? A yes to both is the shape the report describes. A yes to the first alone is still worth a look, because the secrets are in scope the moment the trigger is.