Summary
A GitHub Actions Pwn Request vulnerability in Conda can allow attacker-controlled pull request content to reach a privileged template-rendering workflow. When an authorized issue comment triggers the affected path, malicious templates may execute code in the workflow context and potentially access its token or other sensitive resources.
A GitHub Actions Pwn Request vulnerability in Conda can allow attacker-controlled pull request content to reach a privileged template-rendering workflow. When an authorized issue comment triggers the affected path, malicious templates may execute code in the workflow context and potentially access its token or other sensitive resources.
Affected context
The issue occurs in the update.yml GitHub Actions workflow when an issue comment invokes the @conda-bot render or @conda-bot recreate commands. In the vulnerable render path, pull request repository and branch data can direct the workflow to check out PR-controlled content before running a template-rendering action with access to SYNC_TOKEN. Risk is increased when the action loads configuration and templates from the checked-out working directory and renders them without sandboxing.
The issue occurs in the update.yml GitHub Actions workflow when an issue comment invokes the @conda-bot render or @conda-bot recreate commands. In the vulnerable render path, pull request repository and branch data can direct the workflow to check out PR-controlled content before running a template-rendering action with access to SYNC_TOKEN. Risk is increased when the action loads configuration and templates from the checked-out working directory and renders them without sandboxing.
Exploit preconditions
- Attack surface: GitHub issue comments that trigger the repository workflow
- Required access: Ability to submit or influence a pull request and post a triggering comment, subject to repository permissions and workflow controls
- Trigger point: The
renderorrecreatecommand path in.github/workflows/update.yml - Required workflow condition: The workflow must check out attacker-influenced repository content and execute the template-rendering action in a privileged context
- Why exploitation is possible: Untrusted template content is evaluated by an unsandboxed Jinja2 environment while workflow credentials may be available
- Attack surface: GitHub issue comments that trigger the repository workflow
- Required access: Ability to submit or influence a pull request and post a triggering comment, subject to repository permissions and workflow controls
- Trigger point: The
renderorrecreatecommand path in.github/workflows/update.yml - Required workflow condition: The workflow must check out attacker-influenced repository content and execute the template-rendering action in a privileged context
- Why exploitation is possible: Untrusted template content is evaluated by an unsandboxed Jinja2 environment while workflow credentials may be available
Why this happens
The underlying bug is a trust-boundary failure in CI workflow design. The workflow treats pull request-controlled repository and branch values as safe checkout targets, then executes an action that reads templates and configuration from that untrusted workspace. Because the Jinja2 environment is unsandboxed, template expressions can perform operations beyond simple data formatting, mapping to CWE-94: Improper Control of Generation of Code ('Code Injection').
The underlying bug is a trust-boundary failure in CI workflow design. The workflow treats pull request-controlled repository and branch values as safe checkout targets, then executes an action that reads templates and configuration from that untrusted workspace. Because the Jinja2 environment is unsandboxed, template expressions can perform operations beyond simple data formatting, mapping to CWE-94: Improper Control of Generation of Code ('Code Injection').
Potential impact
- Arbitrary code execution on a GitHub Actions runner
- Exposure or misuse of workflow tokens and other accessible secrets
- Modification of repository or generated infrastructure content
- CI/CD pipeline compromise and supply-chain tampering
- Potential access to connected services permitted by the runner identity
- Arbitrary code execution on a GitHub Actions runner
- Exposure or misuse of workflow tokens and other accessible secrets
- Modification of repository or generated infrastructure content
- CI/CD pipeline compromise and supply-chain tampering
- Potential access to connected services permitted by the runner identity
General mitigation guidance
Mitigation generally focuses on separating untrusted pull request execution from privileged workflow operations.
Defensive patterns include:
- Avoiding secret-bearing workflows for code or templates controlled by untrusted pull requests
- Using isolated, least-privileged jobs for untrusted content and withholding credentials from those jobs
- Restricting checkout targets to trusted repositories, refs, and reviewed revisions
- Treating issue-comment inputs as untrusted and enforcing explicit authorization and validation
- Replacing unsandboxed template evaluation with constrained rendering or inert data substitution
- Pinning and reviewing third-party actions, while limiting their workspace and token permissions
- Applying minimal
GITHUB_TOKENpermissions and short-lived, narrowly scoped credentials
Mitigation generally focuses on separating untrusted pull request execution from privileged workflow operations.
Defensive patterns include:
- Avoiding secret-bearing workflows for code or templates controlled by untrusted pull requests
- Using isolated, least-privileged jobs for untrusted content and withholding credentials from those jobs
- Restricting checkout targets to trusted repositories, refs, and reviewed revisions
- Treating issue-comment inputs as untrusted and enforcing explicit authorization and validation
- Replacing unsandboxed template evaluation with constrained rendering or inert data substitution
- Pinning and reviewing third-party actions, while limiting their workspace and token permissions
- Applying minimal
GITHUB_TOKENpermissions and short-lived, narrowly scoped credentials
How teams detect issues like this
Detection can combine workflow analysis, repository review, and runtime policy controls:
- Search workflows for
pull_requestorissue_commentpaths that check out PR-controlled refs and then access secrets - Flag expressions that derive repository, branch, or ref values from pull request metadata without trust validation
- Review template engines for sandbox configuration and for evaluation of workspace-controlled files
- Use static analysis and automated code review rules to identify privileged actions following untrusted checkout operations
- Enforce organization policies that restrict token permissions, secret exposure, and execution of untrusted fork content
- Monitor workflow logs for unexpected repository checkouts, template evaluation failures, credential access, or outbound activity
Detection can combine workflow analysis, repository review, and runtime policy controls:
- Search workflows for
pull_requestorissue_commentpaths that check out PR-controlled refs and then access secrets - Flag expressions that derive repository, branch, or ref values from pull request metadata without trust validation
- Review template engines for sandbox configuration and for evaluation of workspace-controlled files
- Use static analysis and automated code review rules to identify privileged actions following untrusted checkout operations
- Enforce organization policies that restrict token permissions, secret exposure, and execution of untrusted fork content
- Monitor workflow logs for unexpected repository checkouts, template evaluation failures, credential access, or outbound activity
