CI: Patch critical security issue in linter.yml

[sethta]

Type of change

• Bugfix

• Feature

• New bidder adapter

• Updated bidder adapter

• Code style update (formatting, local variables)

• Refactoring (no functional changes, no api changes)

• Build related changes

• CI related changes

• Does this change affect user-facing APIs or examples documented on http://prebid.org?

• Other

Description of change

pull_request_target is a critical security issue because it authorizes full write access to the repo in a privileged context. When combined with npm ci, malicious package.json scripts from untrusted PRs can execute with repository write permissions and access to secrets. This could allow attackers to modify the codebase or retrieve credentials.

Full write access is not required to post a comment, so we can just use pull_request instead of pull_request_target.

Other information

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d5809a1e93

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Restore write-capable event for PR comment step

Switching this workflow to pull_request means that for forked PRs the GITHUB_TOKEN is read‑only, so the github.rest.issues.createComment step later in this file will fail (403) and the job will error instead of posting the lint delta. This regression shows up whenever the PR comes from a fork, which is the common external contribution path for Prebid.js.

Useful? React with 👍 / 👎.

[Copilot]

Pull request overview

This PR addresses a critical security vulnerability in the linter workflow by changing the trigger from pull_request_target to pull_request. The pull_request_target event runs with write access to the repository and can execute untrusted code from malicious PRs through npm ci scripts, creating a significant security risk. The change to pull_request runs the workflow in a restricted context without write access to the repository.

• Changes the GitHub Actions workflow trigger from pull_request_target to pull_request to prevent malicious code execution with elevated privileges

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The PR title contains a spelling error: "secuirt" should be "security".

[Copilot]

When changing from pull_request_target to pull_request, you need to add explicit permissions for the workflow to post comments. Without explicit permissions, pull_request events have read-only access by default. Add a permissions block at the job or workflow level with pull-requests: write to allow the workflow to create comments on the PR.

Suggested change

	permissions:
	pull-requests: write

[patmmccann]

context, raptie got a code scanning alert in our fork from github codeql

Code scanning alerts #3
Checkout of untrusted code in a privileged context
Fixed in raptive-main 5 days ago
Code snippet
.github/workflows/linter.yml:41
- name: Check out PR
run: git checkout ${{ github.event.pull_request.head.sha }}

  - name: Install dependencies
    run: npm ci

  - name: Run linter on PR

Potential execution of untrusted code on a privileged workflow (pull_request_target
)
CodeQL
run: npx eslint --no-inline-config --format json $(cat __changed_files.txt | xargs stat --printf '%n\n' 2> /dev/null) > __pr.json || true

  - name: Compare them and post comment if necessary

Rule
Tool
CodeQL
Rule ID
actions/untrusted-checkout/critical
Query
View source
Description
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.

Recommendation
Avoid using pull_request_target unless necessary.
Employ unprivileged pull_request workflows followed by workflow_run for privileged operations.
Use labels like safe to test to vet PRs and manage the execution context appropriately.
The best practice is to handle the potentially untrusted pull request via the pull_request trigger so that it is isolated in an unprivileged environment. The workflow processing the pull request should then store any results like code coverage or failed/passed tests in artifacts and exit. A second privileged workflow with the access to repository secrets, triggered by the completion of the first workflow using workflow_run trigger event, downloads the artifacts and make any necessary modifications to the repository or interact with third party services that require repository secrets (e.g. API tokens).

The artifacts downloaded from the first workflow should be considered untrusted and must be verified.

Example
Incorrect Usage
The following workflow checks-out untrusted code in a privileged context and runs user-controlled code (in this case package.json scripts) which will grant privileged access to the attacker:

on: pull_request_target

jobs:
build:
name: Build and test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
ref: ${{ github.event.pull_request.head.sha }}

  - uses: actions/setup-node@v1
  - run: |
      npm install # scripts in package.json from PR would be executed here
      npm build

  - uses: completely/fakeaction@v2
    with:
      arg1: ${{ secrets.supersecret }}

  - uses: fakerepo/comment-on-pr@v1
    with:
      message: |
        Thank you!

Correct Usage
An example shows how to use two workflows: one for processing the untrusted PR and the other for using the results in a safe context.

ReceivePR.yml (untrusted PR handling with artifact creation):

name: Receive PR
on:
pull_request:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Build
run: /bin/bash ./build.sh
- name: Save PR number
run: |
mkdir -p ./pr
echo ${{ github.event.number }} > ./pr/NR
- uses: actions/upload-artifact@v2
with:
name: pr
path: pr/
CommentPR.yml (processing artifacts with privileged access):

name: Comment on the pull request
on:
workflow_run:
workflows: ["Receive PR"]
types:
- completed
jobs:
upload:
runs-on: ubuntu-latest
if: >
github.event.workflow_run.event == 'pull_request' &&
github.event.workflow_run.conclusion == 'success'
steps:
- name: "Download artifact"
uses: actions/[email protected]
with:
script: |
var artifacts = await github.actions.listWorkflowRunArtifacts({
owner: context.repo.owner,
repo: context.repo.repo,
run_id: ${{github.event.workflow_run.id }},
});
var matchArtifact = artifacts.data.artifacts.filter((artifact) => {
return artifact.name == "pr";
})[0];
var download = await github.actions.downloadArtifact({
owner: context.repo.owner,
repo: context.repo.repo,
artifact_id: matchArtifact.id,
archive_format: 'zip',
});
var fs = require('fs');
fs.writeFileSync('${{github.workspace}}/pr.zip', Buffer.from(download.data));
- run: |
mkdir -p tmp
unzip -d tmp/ pr.zip
- name: "Comment on PR"
uses: actions/github-script@v3
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
script: |
var fs = require('fs');
var issue_number = Number(fs.readFileSync('./tmp/NR'));
// Verify that the file contains a numeric value
const contains_numeric = /\d/.test(issue_number);
if (contains_numeric) {
await github.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: issue_number,
body: 'Everything is OK. Thank you for the PR!'
});
}
References
GitHub Security Lab Research: Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests.

[dgirardi]

see https://github.com/prebid/Prebid.js/pull/14330/files/1314edff69ba01ccf652e2b249ebfaeb8e50f5f6#r2690999520 (a very similar PR) - from my testing this breaks the workflow on PRs from forks, I'm going to try using workflow_run but am interested in any other ideas you might have.

[dgirardi]

Closing this in favor of #14339