Improve actions/ql/src/Security/CWE-829/UntrustedCheckoutX queries#21715
Improve actions/ql/src/Security/CWE-829/UntrustedCheckoutX queries#21715knewbury01 wants to merge 6 commits intogithub:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates the GitHub Actions “Untrusted checkout” query family to improve sink detection (Python -m module execution and go run directory/package execution) and refines the associated query help text, naming, and alert location formatting to better align with related queries.
Changes:
- Expand poisonable-step regex patterns for Python module execution (
python -m ...) and broadergo run/generatetargets. - Update help file overview text and add an additional reference link.
- Adjust query naming and (per changenote) alert location behavior for the critical query.
Show a summary per file
| File | Description |
|---|---|
| actions/ql/src/change-notes/2026-04-15-untrusted-checkout-improvements.md | Adds a changenote describing detection + messaging updates. |
| actions/ql/src/Security/CWE-829/UntrustedCheckoutMedium.md | Refines the query help overview text and adds a reference. |
| actions/ql/src/Security/CWE-829/UntrustedCheckoutHigh.ql | Updates the query display name. |
| actions/ql/src/Security/CWE-829/UntrustedCheckoutHigh.md | Refines the query help overview text and adds a reference. |
| actions/ql/src/Security/CWE-829/UntrustedCheckoutCritical.ql | Adjusts select tuple ordering (alert location formatting). |
| actions/ql/src/Security/CWE-829/UntrustedCheckoutCritical.md | Refines the query help overview text and adds a reference. |
| actions/ql/src/Security/CWE-094/CodeInjectionMedium.ql | Modifies query metadata and replaces query body with temporary/test content. |
| actions/ql/lib/ext/config/poisonable_steps.yml | Updates poisonable local-script regex patterns for Python -m and go run/generate. |
Copilot's findings
Comments suppressed due to low confidence (1)
actions/ql/src/Security/CWE-094/CodeInjectionMedium.ql:25
- It looks like the actual query body has been commented out (lines 21-25). Leaving commented-out query logic in the source is likely accidental and will prevent this query from working as intended; please restore the real query and remove the temporary commented-out block.
// from CodeInjectionFlow::PathNode source, CodeInjectionFlow::PathNode sink
// where mediumSeverityCodeInjection(source, sink)
// select sink.getNode(), source, sink,
// "Potential code injection in $@, which may be controlled by an external user.", sink,
// sink.getNode().asExpr().(Expression).getRawExpression()
- Files reviewed: 8/8 changed files
- Comments generated: 9
| @@ -1,5 +1,5 @@ | |||
| /** | |||
| * @name Checkout of untrusted code in trusted context | |||
| * @name Checkout of untrusted code in privileged context without privileged context use | |||
There was a problem hiding this comment.
The query @name is hard to parse and reads self-contradictory ("privileged context without privileged context use"). Consider rephrasing to clearly describe the intended scenario (for example, privileged workflow + untrusted checkout, and what makes it "high").
| * @name Checkout of untrusted code in privileged context without privileged context use | |
| * @name Checkout of untrusted code in a privileged workflow |
| --- | ||
| category: majorAnalysis | ||
| --- | ||
| * Fixed help file descriptions for queries: `actions/untrusted-checkout/critical`, `actions/untrusted-checkout/high`, `actions/untrusted-checkout/medium`. Previously the messages were unclear as to why and how the vulnerabilities could occur. Additionally alter 2 patterns in the detection such that now extra sinks are detected in the following cases: scripts executed via python modules and `go run` in directories are detected as potential mechanisms of injection. This may lead to more results being detected by all 3 queries. |
There was a problem hiding this comment.
The changenote bullet is a run-on sentence and has unclear grammar (for example "Additionally alter 2 patterns"). Please rewrite for clarity (e.g., split into shorter sentences and use consistent tense) so the change is easy to understand in release notes.
| * Fixed help file descriptions for queries: `actions/untrusted-checkout/critical`, `actions/untrusted-checkout/high`, `actions/untrusted-checkout/medium`. Previously the messages were unclear as to why and how the vulnerabilities could occur. Additionally alter 2 patterns in the detection such that now extra sinks are detected in the following cases: scripts executed via python modules and `go run` in directories are detected as potential mechanisms of injection. This may lead to more results being detected by all 3 queries. | |
| * Fixed the help file descriptions for `actions/untrusted-checkout/critical`, `actions/untrusted-checkout/high`, and `actions/untrusted-checkout/medium`. Previously, the messages did not clearly explain why and how the vulnerabilities could occur. Also updated two detection patterns so that additional sinks are detected. In particular, scripts executed via Python modules and `go run` in directories are now detected as potential injection mechanisms. This may lead to more results from all three queries. |
| ## Overview | ||
|
|
||
| GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A potentially dangerous misuse of the triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted code (Pull Request HEAD) may lead to repository compromise if untrusted code gets executed (e.g., due to a modified build script) in a privileged job. | ||
| GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A dangerous misuse of event triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted input from the PR may lead to repository compromise if untrusted code gets executed in a privileged job. Untrusted code may get executed due to a modified build script, workflow injection, or registry hijacking. **Carefully review** whether least privileges is used and whether input is taken from untrusted sources. |
There was a problem hiding this comment.
The Overview text says "least privileges" but the standard phrasing is "least privilege" (singular). Consider also changing "whether least privileges is used" to something grammatically correct like "whether the principle of least privilege is followed".
| GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A dangerous misuse of event triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted input from the PR may lead to repository compromise if untrusted code gets executed in a privileged job. Untrusted code may get executed due to a modified build script, workflow injection, or registry hijacking. **Carefully review** whether least privileges is used and whether input is taken from untrusted sources. | |
| GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A dangerous misuse of event triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted input from the PR may lead to repository compromise if untrusted code gets executed in a privileged job. Untrusted code may get executed due to a modified build script, workflow injection, or registry hijacking. **Carefully review** whether the principle of least privilege is followed and whether input is taken from untrusted sources. |
| ## Overview | ||
|
|
||
| GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A potentially dangerous misuse of the triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted code (Pull Request HEAD) may lead to repository compromise if untrusted code gets executed (e.g., due to a modified build script) in a privileged job. | ||
| GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A dangerous misuse of event triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted input from the PR may lead to repository compromise if untrusted code gets executed in a privileged job. Untrusted code may get executed due to a modified build script, workflow injection, or registry hijacking. **Carefully review** whether least privileges is used and whether input is taken from untrusted sources. |
There was a problem hiding this comment.
The Overview text says "least privileges" but the standard phrasing is "least privilege" (singular). Consider also changing "whether least privileges is used" to something grammatically correct like "whether the principle of least privilege is followed".
| GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A dangerous misuse of event triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted input from the PR may lead to repository compromise if untrusted code gets executed in a privileged job. Untrusted code may get executed due to a modified build script, workflow injection, or registry hijacking. **Carefully review** whether least privileges is used and whether input is taken from untrusted sources. | |
| GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A dangerous misuse of event triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted input from the PR may lead to repository compromise if untrusted code gets executed in a privileged job. Untrusted code may get executed due to a modified build script, workflow injection, or registry hijacking. **Carefully review** whether the principle of least privilege is followed and whether input is taken from untrusted sources. |
| ## Overview | ||
|
|
||
| GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A potentially dangerous misuse of the triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted code (Pull Request HEAD) may lead to repository compromise if untrusted code gets executed (e.g., due to a modified build script) in a privileged job. | ||
| GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A dangerous misuse of event triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted input from the PR may lead to repository compromise if untrusted code gets executed in a privileged job. Untrusted code may get executed due to a modified build script, workflow injection, or registry hijacking. **Carefully review** whether least privileges is used and whether input is taken from untrusted sources. |
There was a problem hiding this comment.
The Overview text says "least privileges" but the standard phrasing is "least privilege" (singular). Consider also changing "whether least privileges is used" to something grammatically correct like "whether the principle of least privilege is followed".
| GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A dangerous misuse of event triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted input from the PR may lead to repository compromise if untrusted code gets executed in a privileged job. Untrusted code may get executed due to a modified build script, workflow injection, or registry hijacking. **Carefully review** whether least privileges is used and whether input is taken from untrusted sources. | |
| GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A dangerous misuse of event triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted input from the PR may lead to repository compromise if untrusted code gets executed in a privileged job. Untrusted code may get executed due to a modified build script, workflow injection, or registry hijacking. **Carefully review** whether the principle of least privilege is followed and whether input is taken from untrusted sources. |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
this is WIP do not merge yet
several changes: